【问题标题】:Define a custom path where the user.config file should be saved?定义应保存 user.config 文件的自定义路径?
【发布时间】:2013-12-05 21:25:39
【问题描述】:

如果我将已编译的应用程序从 myapp.exe 重命名为 app.exe,那么当我运行重命名的可执行文件时,会在此路径中生成一个新的用户设置文件夹:

C:\Users\{User}\AppData\Local\{CompanyName}\{ExecutableName}_Url_{SystemGUID or something strange}

所以我放弃了所有保存的设置。

那么我如何解决这个问题,在VBNETWinForms 我自己的位置定义来存储user.config 文件,或者使用applicationsettings 基础结构的任何其他解决方案? (不保存注册表或其他东西上的设置)

PS:我读过这篇 SO 帖子,这是一个有点不同的问题,但无论如何我不明白所谓的解决方案 Can I control the location of .NET user settings to avoid losing settings on application upgrade?

【问题讨论】:

  • 请注意 Ian Boyd 在该链接中的评论。然后请注意,很少有严肃的应用程序(我的系统上没有)使用默认/My.Settings。默认提供了很多便利,但灵活性极小且没有保护。使用 CompName\Product 位置进行存储可以让您做任何您想做的事情(更改 EXE 名称、导入 TrialVer 设置或加密设置(如果包含过期日期)。自定义设置类还可以使用二进制序列化程序来保存或加载所有数据而无需大量分配 (me.thisval = My.Settings.ThisVal)。

标签: .net vb.net application-settings my.settings user-config


【解决方案1】:

我想您也可以使用ConfigurationManager.OpenExeConfiguration 方法从特定位置打开您的配置文件。

希望我能帮上忙!

【讨论】:

    【解决方案2】:

    来自回答您问题的链接的更多信息和花絮:

    您引用的“systemGUID 或其他内容”实际上是 2 个事物的哈希(参考 MSDN My.Settings):

    <eid> is the URL, StrongName, or Path, based on the evidence available to hash.  
    <hash> is a SHA1 hash of evidence gathered from the CurrentDomain, 
        in the following order of preference: 
        - StrongName 
        - URL If neither of these is available, use the .exe path.
    

    如果没有 StrongName,您的位置会因路径而异,这就是您所描述的问题。由于 eid 和 hash 都将使用 StrongName 作为 hash(es),即使他们将其移动到其他地方或安装新版本,完整路径也应该保持不变。使用 StrongName 时,凭据来自应用程序,并且哈希不会更改,并且永远不会使用最后的方法(exe 路径)。这回答了您的基本问题:使用强名称并且路径不会改变。

    新版本/版本将为设置的每个版本在该文件夹下创建一个子文件夹树。链接中提到的SettingsUpgrade 方法(显然)有助于从/a 以前的版本导入设置。但是,EXE 名称的更改将导致 AppDomain.FriendlyName(第三个元素)发生更改。


    隔离存储是另一种选择,它不像最初看起来那么难,但具有类似的行为。使用 Iso,您无需指定文件夹,因为它只是在 Users\&lt;User&gt;\Isolated Storage\zhxytg\dhfyres\ 等不知名的位置创建一个文件夹。如果您使用 ClickOnce(因此,这是另一个可行的解决方案),该位置对于所有版本的应用程序都可以保持相同,即使您重命名它。

    我认为您必须使用 ClickOnce (StrongName 作为替代品没有出现在 MSDN 中)来获得应用程序级别的证据。作为附带的好处,使用 ISO,即使在最高安全性下,非管理员用户也可以至少使用 W7 读取/写入ProgramData\AllUsers 中的共享文件(许可证或应用程序套件的共享设置可能是这种情况) .应用程序的哈希允许它写入该路径,因此它可以做一些我们通常不能做的事情。

    如果您不使用 ClickOnce,您仍然可以获得一个稳定的文件夹每次安装 并读取/写入 AllUsers。新安装(到不同的文件夹)将导致不同的哈希和文件位置;与更改文件名相同。即使您设法将旧位置存储在某处,新安装也可能无权访问旧文件(未尝试过)。

    ISO 删除了 EXEName 的变化,但它不使用 My.Settings。相反,您使用由IsolatedStorageFile 对象创建的IsolatedFileStreams。而且您必须接管组织和管理各种设置的值和名称。使用的隔离存储类型(应用程序/用户)取决于可用的凭据。

    隔离存储有它的位置,但对于设置来说似乎有点过头了。


    您提到您通常只将 MySettings 用于琐碎的应用程序。因此,一个 StrongName 只是为了稳定设置路径似乎是矫枉过正。 ISO 非常有趣,但有一些更简单的东西。这第三个选项属于您不想要的or other things,但非常灵活。

    围绕序列化构建您自己的设置类。对于简单的设置,这些可能不仅仅是一组名称-值对 {LastPath = "....."; FormLeft = x; FormTop = y ...}。将这些保存在 Dictionary(Of String, String)Dictionary(Of enumSettings, String) 中,然后序列化(保存)整个容器:

    Dim bf As New BinaryFormatter
    Using fs As New FileStream(myFile, FileMode.OpenOrCreate)
        bf.Serialize(fs, _UserOpts)   
    End Using
    

    取回值同样简单。对于需要保存许多类型的更复杂的项目,如 Integer、Date、Array、ArrayList、List(of T) 等,请为它们创建一个 UserOptions 类并序列化 that

    请注意,您将文件流传递给序列化程序,因此您可以完全控制名称和位置,例如 C:\Users\&lt;username&gt;\AppData\Local\&lt;Company&gt;\&lt;Product&gt;\Settings.bin 该位置不会因版本、文化、程序集等而改变。它将保持在您放置的位置。

    当您尝试对 Point、Size 和 Font 等类型进行序列化时,这确实会失去动力,因为无法直接序列化对象。特别是,使用 ProtoBuff 有多个选项可以将这些转换为动态或预先可序列化的东西。

    【讨论】:

    • 首先感谢您提供的信息。当我需要开发一个有很多“关键”选项的应用程序时,我总是管理一个 INI 文件来保存/加载所有设置,这就是我在评论中所引用的:(not saving the settings on the registry *or other things*),只是我想停止使用INI 文件或注册表或“其他东西”,因为微软给了我们一个功能来轻松管理设置,问题是如果应用程序有很多设置并且你重命名应用程序,那么所有设置都会丢失,
    • 我也认为这种方式不可能进行便携式安装(使用预定义的设置,我的意思是你可以在应用程序目录中使用 INI 文件)......至少在设置文件之前/dir 位置不能由开发者定义。
    • 很抱歉,我只理解了你所说的 50% 左右的解释,你能解释一下如何做到这一点吗?:if you go 'all in' on the Microsoft paradigm, you can stabilize the hash to a single, stable location. 你的意思是存在解决方案我的问题是使用 microsoft .NET 设置功能吗?强名与那句话有关吗?我有点失落,对不起!请原谅我的英语不好。如果你知道如何解决这个问题,如果我没有要求太多,你能用几行写一个新手的分步指南吗?
    • 我同意 INI 和注册表是坏的并且不会建议。一个自定义设置类来保存自己 - 甚至序列化自己 - 非常微不足道,仍然属于 other things 类别。我不同意 NET My.Settings 甚至接近理想除非您想从头到尾按照自己的方式进行操作。 #2:有一些方法可以保存到稳定的 AppData 或 ProgramData 位置,你不能使用 My.Settings 因为 MS/NET 控制文件位置。 #3 - 我会编辑
    猜你喜欢
    • 2011-01-16
    • 1970-01-01
    • 2011-10-11
    • 2023-04-09
    • 2017-06-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多