问题
Currentlly the user-settings of my application are stored in this default directory:
C:\Users\{User Name}\AppData\Roaming\{Company Name}\{Assembly Name}.vshos_Url_{Hash}\{Assembly Version}
I'm aware of the meaning of the default Microsoft naming rules, my question is: How can I change that defaut folder at execution time or by modifying the appconfig file?.
My intention is only be able to handle the directory on which the user-settings of my application will be saved, for example I would like to save the user-settings file in this directory:
C:\Users\{User Name}\AppData\Roaming\{Assembly Name}
I know this is possible to acchieve, because I've seen much .NET applications that can store its userconfig file in a custom Roaming folder that doesn't follows the Microsoft default rules with that unhandled hash and those other annonying naming rules.
回答1:
That naming convention exists so that NET can be sure the correct settings are be loaded. Since you have yielded control of managing settings to the NET Framework/VB Application Framework, it also takes on the responsibility of making sure that an app is loading the right set of settings. That being the case, the evidence hash is used to uniquely identify one WindowsApplication1 from another (among other things).
I know this is possible to acchieve, because I've seen much .NET applications that can store its userconfig file in a custom Roaming folder
It is possible, but I am not sure everything is quite the way you conclude. I very seriously doubt that many apps go thru the hassle to implement a custom provider when they could much more easily save an XML file to that location using a custom settings class.
The Simple Solution
Write your own user options class, and serialize it yourself. For instance a Shared/static method can be used to deserialize the class in very little code (this just happens to use JSON):
Friend Shared Function Load() As UserOptions
' create instance for default on new install
Dim u As New UserOptions
If File.Exists(filePath) Then
' filepath can be anywhere you have access to!
Dim jstr = File.ReadAllText(filePath)
If String.IsNullOrEmpty(jstr) = False Then
u = JsonConvert.DeserializeObject(Of UserOptions)(jstr)
End If
End If
Return u
End Function
The app implementing it:
UOpt = UserOptions.Load()
Among the Pros, you have total control over where the file is saved, and can use any serializer you like. Most of all, it is simple - much less code than presented below.
The Cons are that the code using it would have to manually Load and Save them (easily handled in Application events), and there is no fancy designer for it.
The Long and Winding Road: a Custom SettingsProvider
A custom SettingsProvider will allow you to change how settings are handled, saved and loaded, including changing the folder location.
This question is narrowly focused on changing the file location. The problem is that there is not a (clean, easy) way for your app to talk to your SettingsProvider in order to specify a folder. The provider needs to be able to work that out internally and of course be consistent.
Most people will want to do more than just change the folder name used. For instance, in playing around, in place of XML I used a SQLite database which mirrored a structure the code uses. This made it very easy to load local and the correct roaming values. Were that approach taken all the way, the code could be greatly simplified and quite possibly the whole Upgrade process. So this provider takes some of those wider needs into account.
There are 2 key considerations even though you just want to change the filename:
Local vs Roaming
Coding the provider to always store in AppData\Roaming but write unqualified local settings there would be irresponsible. Distinguishing between them is a capability that ought not be sacrificed in order to elide the evidence hash in the folder name.
Note: Each Setting can be set as a Roaming or Local value: with a Setting selected in the Settings Editor, open the Properties pane - change Roaming to True.
There seems to be a consensus in the (very) few questions here dealing with a custom SettingsProvider to save Local and Roaming to the same file but in different sections. That makes a great deal of sense - and is simpler than loading from 2 files - so the XML structure used is:
<configuration>
<CommonShared>
<setting name="FirstRun">True</setting>
<setting name="StartTime">15:32:18</setting>
...
</CommonShared>
<MACHINENAME_A>
<setting name="MainWdwLocation">98, 480</setting>
<setting name="myGuid">d62eb904-0bb9-4897-bb86-688d974db4a6</setting>
<setting name="LastSaveFolder">C:\Folder ABC</setting>
</MACHINENAME_A>
<MACHINENAME_B>
<setting name="MainWdwLocation">187, 360</setting>
<setting name="myGuid">a1f8d5a5-f7ec-4bf9-b7b8-712e80c69d93</setting>
<setting name="LastSaveFolder">C:\Folder XYZ</setting>
</MACHINENAME_B>
</configuration>
The roaming items are stored in sections named after the MachineName they are used on. There might be some value in retaining the <NameSpace>.My.MySettings node, but I am not sure what purpose it serves.
I removed the SerializeAs element since it is not used.
Versions
Nothing whatsoever will happen if you invoke My.Settings.Upgrade. Even though it is a Settings method, it is actually something in ApplicationSettingsBase, so your provider isn't involved.
As a result, using the full version string as part of the folder causes a problem if you auto increment the last element. Trivial rebuilds will create a new folder and lose and orphan the old settings. Perhaps you could look for and load the values for a previous version when there is no current file. Then perhaps delete that old file/folder, so there is always only one possible set of old settings. Feel free to add oodles and oodles of merge code.
For the primary purpose of just changing the data store folder, I removed the version folder segment. When using a global provider the code automatically accumulates settings. A settings which has been removed wont "leak" into the app because NET wont ask for a value for it. The only issue is that there will be a value for it in the XML.
I added code to purge these. This will prevent a problem should you later reuse a settings name with a different type. The old saved value for Foo as Decimal wont work with the new Foo as Size for instance. Things will still go badly if you radically change a type. Don't do that.
This answer Custom path of the user.config provides a very nice starting point for a custom provider. It has a few problems and is missing a few things but provides a quick start guide for some of the steps and boilerplate code typical of any provider. Since many people may need to further modify the provider here, it might be worth reading (and upvoting).
The code here borrows a few things from that answer and:
- Adds various refinements
- Provides for a custom path
- Detection for settings set as Roaming
- Local and Roaming section in the file
- Proper handling of complex types such as
PointorSize - Detect and prune removed settings
- is in VB
1. Setup
For the most part, you can't incrementally write/debug this - little will work until you are done.
- Add a reference to
System.Configuration - Add a new class to your project
Example:
Imports System.Configuration
Public Class CustomSettingsProvider
Inherits SettingsProvider
End Class
Next, go to the Settings designer and add some settings for testing. Tag some as Roaming for a complete test. Then click the <> View Code button shown here:
Everyone loves freehand circles!
There are apparently two ways to implement a custom provider. The code here will use yours in place of My.MySettings. You can also specify a custom provider on a per-Setting basis by typing the provider name in the Properties pane, and skip the rest of this step. I did not test this, but it is how it is supposed to work.
In order to use the new settings provider "you" write, it needs to be associated with MySettings using an attribute:
Imports System.Configuration
<SettingsProvider(GetType(ElectroZap.CustomSettingsProvider))>
Partial Friend NotInheritable Class MySettings
End Class
'ElektroZap' is your root NameSpace, and 'ElektroApp' is your app name, by the way. The code in the constructor can be changed to use the Product name or module name.
We are done with that file; save it and close it.
2. SettingsProvider
First, note that this CustomProvider is generic and should work with any app by just designating it as the SettingsProvider. But it really only does 2 things:
- Uses a custom path
- Merges local and roaming settings into one file
Typically one would have a longer ToDo list before resorting to a custom provider, so for many this may just provide the starting point for Other Things. Keep that in mind that some changes may make it specific to a project.
One of the things added is support for the more complex types such as Point or Size. These are serialized as invariant strings so that they can be parsed back. What that means is this:
Console.WriteLine(myPoint.ToString())
The result, {X=64, Y=22} cannot be directly converted back and Point lacks a Parse/TryParse method. Using the invariant string form 64,22 allows it to be converted back to the correct type. The original linked code simply used:
Convert.ChangeType(setting.DefaultValue, t);
This will work with simple types, but not Point, Font etc. I can't recall for sure, but I think this is a simple mistake of using SettingsPropertyValue.Value rather than .SerializedValue.
3. The Code
Public Class CustomSettingsProvider
Inherits SettingsProvider
' data we store for each item
Friend Class SettingsItem
Friend Name As String
'Friend SerializeAs As String ' not needed
Friend Value As String
Friend Roamer As Boolean
Friend Remove As Boolean ' mutable
'Friend VerString As String ' ToDo (?)
End Class
' used for node name
Private thisMachine As String
' loaded XML config
'Private xDoc As XDocument
Private UserConfigFilePath As String = ""
Private myCol As Dictionary(Of String, SettingsItem)
Public Sub New()
myCol = New Dictionary(Of String, SettingsItem)
Dim asm = Assembly.GetExecutingAssembly()
Dim verInfo = FileVersionInfo.GetVersionInfo(asm.Location)
Dim Company = verInfo.CompanyName
' product name may have no relation to file name...
Dim ProdName = verInfo.ProductName
' use this for assembly file name:
Dim modName = Path.GetFileNameWithoutExtension(asm.ManifestModule.Name)
' dont use FileVersionInfo;
' may want to omit the last element
'Dim ver = asm.GetName.Version
' uses `SpecialFolder.ApplicationData`
' since it will store Local and Roaming val;ues
UserConfigFilePath = Path.Combine(GetFolderPath(SpecialFolder.ApplicationData),
Company, modName,
"user.config")
' "CFG" prefix prevents illegal XML,
' the FOO suffix is to emulate a different machine
thisMachine = "CFG" & My.Computer.Name & "_FOO"
End Sub
' boilerplate
Public Overrides Property ApplicationName As String
Get
Return Assembly.GetExecutingAssembly().ManifestModule.Name
End Get
Set(value As String)
End Set
End Property
' boilerplate
Public Overrides Sub Initialize(name As String, config As Specialized.NameValueCollection)
MyBase.Initialize(ApplicationName, config)
End Sub
' conversion helper in place of a 'Select Case GetType(foo)'
Private Shared Conversion As Func(Of Object, Object)
Public Overrides Function GetPropertyValues(context As SettingsContext,
collection As SettingsPropertyCollection) As SettingsPropertyValueCollection
' basically, create a Dictionary entry for each setting,
' store the converted value to it
' Add an entry when something is added
'
' This is called the first time you get a setting value
If myCol.Count = 0 Then
LoadData()
End If
Dim theSettings = New SettingsPropertyValueCollection()
Dim tValue As String = ""
' SettingsPropertyCollection is like a Shopping list
' of props that VS/VB wants the value for
For Each setItem As SettingsProperty In collection
Dim value As New SettingsPropertyValue(setItem)
value.IsDirty = False
If myCol.ContainsKey(setItem.Name) Then
value.SerializedValue = myCol(setItem.Name)
tValue = myCol(setItem.Name).Value
Else
value.SerializedValue = setItem.DefaultValue
tValue = setItem.DefaultValue.ToString
End If
' ToDo: Enums will need an extra step
Conversion = Function(v) TypeDescriptor.
GetConverter(setItem.PropertyType).
ConvertFromInvariantString(v.ToString())
value.PropertyValue = Conversion(tValue)
theSettings.Add(value)
Next
Return theSettings
End Function
Public Overrides Sub SetPropertyValues(context As SettingsContext,
collection As SettingsPropertyValueCollection)
' this is not called when you set a new value
' rather, NET has one or more changed values that
' need to be saved, so be sure to save them to disk
Dim names As List(Of String) = myCol.Keys.ToList
Dim sItem As SettingsItem
For Each item As SettingsPropertyValue In collection
sItem = New SettingsItem() With {
.Name = item.Name,
.Value = item.SerializedValue.ToString(),
.Roamer = IsRoamer(item.Property)
}
'.SerializeAs = item.Property.SerializeAs.ToString(),
names.Remove(item.Name)
If myCol.ContainsKey(sItem.Name) Then
myCol(sItem.Name) = sItem
Else
myCol.Add(sItem.Name, sItem)
End If
Next
' flag any no longer used
' do not use when specifying a provider per-setting!
For Each s As String In names
myCol(s).Remove = True
Next
SaveData()
End Sub
' detect if a setting is tagged as Roaming
Private Function IsRoamer(prop As SettingsProperty) As Boolean
Dim r = prop.Attributes.
Cast(Of DictionaryEntry).
FirstOrDefault(Function(q) TypeOf q.Value Is SettingsManageabilityAttribute)
Return r.Key IsNot Nothing
End Function
Private Sub LoadData()
' load from disk
If File.Exists(UserConfigFilePath) = False Then
CreateNewConfig()
End If
Dim xDoc = XDocument.Load(UserConfigFilePath)
Dim items As IEnumerable(Of XElement)
Dim item As SettingsItem
items = xDoc.Element(CONFIG).
Element(COMMON).
Elements(SETTING)
' load the common settings
For Each xitem As XElement In items
item = New SettingsItem With {.Name = xitem.Attribute(ITEMNAME).Value,
.Roamer = False}
'.SerializeAs = xitem.Attribute(SERIALIZE_AS).Value,
item.Value = xitem.Value
myCol.Add(item.Name, item)
Next
' First check if there is a machine node
If xDoc.Element(CONFIG).Element(thisMachine) Is Nothing Then
' nope, add one
xDoc.Element(CONFIG).Add(New XElement(thisMachine))
End If
items = xDoc.Element(CONFIG).
Element(thisMachine).
Elements(SETTING)
For Each xitem As XElement In items
item = New SettingsItem With {.Name = xitem.Attribute(ITEMNAME).Value,
.Roamer = True}
'.SerializeAs = xitem.Attribute(SERIALIZE_AS).Value,
item.Value = xitem.Value
myCol.Add(item.Name, item)
Next
' we may have changed the XDOC, by adding a machine node
' save the file
xDoc.Save(UserConfigFilePath)
End Sub
Private Sub SaveData()
' write to disk
Dim xDoc = XDocument.Load(UserConfigFilePath)
Dim roamers = xDoc.Element(CONFIG).
Element(thisMachine)
Dim locals = xDoc.Element(CONFIG).
Element(COMMON)
Dim item As XElement
Dim section As XElement
For Each kvp As KeyValuePair(Of String, SettingsItem) In myCol
If kvp.Value.Roamer Then
section = roamers
Else
section = locals
End If
item = section.Elements().
FirstOrDefault(Function(q) q.Attribute(ITEMNAME).Value = kvp.Key)
If item Is Nothing Then
' found a new item
Dim newItem = New XElement(SETTING)
newItem.Add(New XAttribute(ITEMNAME, kvp.Value.Name))
'newItem.Add(New XAttribute(SERIALIZE_AS, kvp.Value.SerializeAs))
newItem.Value = If(String.IsNullOrEmpty(kvp.Value.Value), "", kvp.Value.Value)
section.Add(newItem)
Else
If kvp.Value.Remove Then
item.Remove()
Else
item.Value = If(String.IsNullOrEmpty(kvp.Value.Value), "", kvp.Value.Value)
End If
End If
Next
xDoc.Save(UserConfigFilePath)
End Sub
' used in the XML
Const CONFIG As String = "configuration"
Const SETTING As String = "setting"
Const COMMON As String = "CommonShared"
Const ITEMNAME As String = "name"
'Const SERIALIZE_AS As String = "serializeAs"
' https://stackoverflow.com/a/11398536
Private Sub CreateNewConfig()
Dim fpath = Path.GetDirectoryName(UserConfigFilePath)
Directory.CreateDirectory(fpath)
Dim xDoc = New XDocument
xDoc.Declaration = New XDeclaration("1.0", "utf-8", "true")
Dim cfg = New XElement(CONFIG)
cfg.Add(New XElement(COMMON))
cfg.Add(New XElement(thisMachine))
xDoc.Add(cfg)
xDoc.Save(UserConfigFilePath)
End Sub
End Class
That's a lot of code just to elide the evidence hash from the path, but it is what MS recommends. It is also likely the only way: the property in ConfigurationManager which gets the file is read only and it backed by code.
Results:
The actual XML is as shown earlier with local/common and machine specific sections. I used several different app names and such testing various things:
Ignore the version portion. As noted earlier that has been removed. Otherwise the folders are correct - as noted above you have some options when it comes to the AppName segment.
Important Notes
- The Load methods in your provider are not called unless and until the related app accesses a Settings property
- Once loaded, the Save method will be called when the app ends (using the VB Framework) whether or not the code changes anything
- NET seems to only save settings which are different from the default value. When using a custom provider, all the values are marked
IsDirtyas true andUsingDefaultValueas false. - If/when loaded, all the values are returned and NET simply gets values from that collection thru the life of the app
My main concern was the correct conversion of types and local/roaming support. I did not check every single possible Type. In particular, custom types and enums (I know enums will need extra handling).
It is worth noting that using a DataTable makes this much simpler. You do not need the SettingsItem class, the collection, no XDoc (use .WriteXML / .ReadXml). All the code to create and organize XElements also goes away.
The resulting XML file is different, but that is just form following function. About 60 lines of code in all can be removed, and it is just simpler.
Resources
- SettingsProvider Class
- MSDN blog entry about Settings
- Stackoverflow: Custom path of the user.config "Chuck" uses better named scratch variables
- Stackoverflow: MachineName problems in XML
- I didnt see this CodeProject article until I was done: Creating a Custom Settings Provider This appears to be a different approach using a custom provider on a per-setting basis.
回答2:
I've seen many issues around this, eg: https://stackoverflow.com/a/15726277/495455
To do anything special its much easier to use XDoc or LinqXML with your own config file(s).
This way you can save them where ever you like and you dont encounter other issues, eg: Custom Configuration Section can only be saved/modified while running as administrator?
来源：https://stackoverflow.com/questions/38429461/how-to-change-the-predefined-userconfig-directory-of-my-net-application