Client Settings FAQ
One of the cool new features in .NET 2.0/VS 2005 is an easy to use, extensible API to manage application/user settings, i.e., data that needs to be persisted across runs of a client application. You can find more information about this feature on MSDN or in my earlier blog posts on this topic.
While the feature is easy to use in general, we often get questions from users trying more advanced scenarios about why a certain aspect of the feature works in a particular way or how to customize some behavior. The answers to these questions are generally in the MSDN docs, but can sometimes be hard to find. I thought it would be useful to cover this information in a FAQ for easy future reference. I will be updating the FAQ as and when there are more questions to add.
Q: I notice there are two kinds of settings - application scoped and user scoped. Application scoped settings seem to be read-only and I cannot change them at runtime. Why is that?
A: There are two main types of settings that applications generally want to store: (1) certain data like connection strings and web references that don't change often, but should be possiblep for an admin to change and therefore cannot be hardcoded into the application and (2) user preferences and customization that can change any time. Application scoped settings are useful in scenario (1) and user scoped settings, in the latter. They are essentially read only from tche application's point of view and aren't meant to be changed by the user, but admins could go and edit the file if they want to. An additional reason for this has to do with how the default SettingsProvider stores settings - application scoped settings go in the exe configuration file and user scoped settings in user.config files located in the user data path. Generally, exe config files shouldn't be written to at runtime by the application, since the user may not have access to them (if the application is installed in c:\Program Files\..., only privileged users have access, for example). Even if they do, it is not usually a good idea for a user to control changing a file that affects every other user of the application.
Q: You said user.config files go in the user data path. How can I locate the file? Are there multiple files for an application or just one?
A: As mentioned before, the default SettingsProvider for client applications (called the LocalFileSettingsProvider) stores settings in the application configuration files. In .NET v1 and v1.1, there were two levels of config files - machine.config and app.exe.config (where 'app.exe' is the name of the application). In v2.0, we have added two more levels of configuration to store user specific data - one that goes in the roaming user profile path and another in the local user profile path. On XP, the profile directories would be something like 'c:\Documents and Settings\<username>\Application Data' and 'c:\Documents and Settings\<username>\Local Settings\Application Data' respectively. These directories are the recommended location (per Windows Logo requirements) for storing user specific information and most applications (like Outlook and Visual Studio) put user data somewhere under here.
The exact path of the user.config files looks something like this:
<Profile Directory>\<Company Name>\<App Name>_<Evidence Type>_<Evidence Hash>\<Version>\user.config
where
<Profile Directory> - is either the roaming profile directory or the local one. Settings are stored by default in the local user.config file. To store a setting in the roaming user.config file, you need to mark the setting with the SettingsManageabilityAttribute with SettingsManageability set to Roaming.
<Company Name> - is typically the string specified by the AssemblyCompanyAttribute (with the caveat that the string is escaped and truncated as necessary, and if not specified on the assembly, we have a fallback procedure).
<App Name> - is typically the string specified by the AssemblyProductAttribute (same caveats as for company name).
<Evidence Type> and <Evidence Hash> - information derived from the app domain evidence to provide proper app domain and assembly isolation.
<Version> - typically the version specified in the AssemblyVersionAttribute. This is required to isolate different versions of the app deployed side by side.
The file name is always simply 'user.config'.
If you want to get to the path programmatically, you can do it using the Configuration Management API (you need to add a reference to System.Configuration.dll). For example, here is how you can get the local user.config file path:
Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal);
Console.WriteLine("Local user config path: {0}", config.FilePath);
Q: Why is the path so obscure? Is there any way to change/customize it?
A: The path construction algorithm has to meet certain rigorous requirements in terms of security, isolation and robustness. While we tried to make the path as easily discoverable as possible by making use of friendly, application supplied strings, it is not possible to keep the path totally simple without running into issues like collisions with other apps, spoofing etc.
The LocalFileSettingsProvider does not provide a way to change the files in which settings are stored. Note that the provider itself doesn't determine the config file locations in the first place - it is the configuration system. If you need to store the settings in a different location for some reason, the recommended way is to write your own SettingsProvider. This is fairly simple to implement and you can find samples in the .NET 2.0 SDK that show how to do this. Keep in mind however that you may run into the same isolation issues mentioned above .
Q: I deployed my application using Clickonce and saved some settings, but can't find the user.config file.
A: The path algorithm mentioned above is not used in the Clickonce case. Instead, the local user.config file goes in the Clickonce Data directory (the <Version> part of the path will still be included). There is no roaming user.config file for Clickonce applications.
Q: How are my strongly typed properties serialized as settings? I couldn't get the <insert type here> class to serialize correctly.
A: There are two primary mechanisms that ApplicationSettingsBase uses to serialize settings - (1) If a TypeConverter exists that can convert to and from string, we use it. (2) If not, we fallback to the XmlSerializer. While most common types can be serialized in one of these ways, there are some types that may not. In such cases, you have a few different options:
- Implement a TypeConverter for the type that can convert to and from string. The implementation can use a suitable serialization mechanism like one of the formatters/serializers that ship in the Framework or any custom mechanism you wish. You can then specify this converter on the type itself or on the property in your settings class.
- Specify a particular SettingsSerializeAs enum value using a SettingsSerializeAsAttribute. For example, if you wish to serialize a setting in binary format, simply specify SettingsSerializeAs.Binary.
Q: My application has a few user scoped settings, but I notice Visual Studio puts them in app.config. I thought they go in user.config files?
A: The configuration system is hierarchical and has this ordering: machine -> application -> roaming user -> local user. When you query a configuration section at any level, you get a merged view of the sections declared in that level and those below it (with machine being the lowest level and local user the highest). The section handler defines how the merge happens and for settings, a setting value specified in, say, local user config trumps the one specified in application config.
So for user scoped settings, you can think of the values specified in app.config to be install time defaults. When the settings are saved into user.config, those values will override these defaults. This way admins have the option of changing the defaults. Note that the defaults can also be specified by means of a DefaultSettingValueAttribute. The provider will use this value if no value is specified for a setting in any level of config.
Q: Why is there a version number in the user.config path? If I deploy a new version of my application, won't the user lose all the settings saved by the previous version?
A: There are couple of reasons why the user.config path is version sensitive. (1) To support side-by-side deployment of different versions of an application (you can do this with Clickonce, for example). It is possible for different version of the application to have different settings saved out. (2) When you upgrade an application, the settings class may have been altered and may not be compatible with what's saved out, which can lead to problems.
However, we have made it easy to upgrade settings from a previous version of the application to the latest. Simply call ApplicationSettingsBase.Upgrade() and it will retrieve settings from the previous version that match the current version of the class and store them out in the current version's user.config file. You also have the option of overriding this behavior either in your settings class or in your provider implementation.
Q: Okay, but how do I know when to call Upgrade?
A: Good question. In Clickonce, when you install a new version of your application, ApplicationSettingsBase will detect it and automatically upgrade settings for you at the point settings are loaded. In non-Clickonce cases, there is no automatic upgrade - you have to call Upgrade yourself. Here is one idea for determining when to call Upgrade:
Have a boolean setting called CallUpgrade and give it a default value of true. When your app starts up, you can do something like:
if (Properties.Settings.Value.CallUpgrade) {
Properties.Settings.Value.Upgrade();
Properties.Settings.Value.CallUpgrade = false;
}
This will ensure that Upgrade() is called only the first time the application runs after a new version is deployed.
Update: 12/10/2005
Q: Is there a way to access settings from the configuration files if I don't have a reference to the settings class that owns them?
A: Yes, you might sometimes require to access certain settings, but you don't have access to the settings class itself. For example, the default settings class generated by the settings designer in VS 2005 is internal to the assembly it is defined in. What if you need to access some settings from a different assembly, let's say, a dll that is loaded by your application? The settings API provides a useful mechanism for this through the SettingsGroupNameAttribute. Usually, the settings provider uses the fully qualified name of your settings class as the key to isolate your settings from those belonging to other classes. This attribute allows you to access settings with a different key or 'group name'. So to access settings from the application's settings class, all the dll needs to do is define its own settings class with properties that match the other class, and apply a SettingsGroupNameAttribute, giving it the other class' name as the group name. A small caveat: if you want to do this in VS, make sure you apply the attribute to the user partial class you get to by clicking 'View Code', and not the designer owned partial class, since any changes to the latter can get overwritten by the settings designer.
Q: Wait, you might ask, this is a rather powerful capability. Is it a security hole? Someone might access my settings without my knowledge or permission!
A: Well, this isn't really a security hole for two reasons:
- From a security point of view, isolation is provided at the app domain level. The CLR recommended way of hosting untrusted code is to load it in a separate app domain. When you create an app domain, you can specify a unique friendly name for it and point it to an application configuration file of your choice. The unique friendly name ensures that the app domain gets separate user configuration files as well. Thus, the code cannot access your settings, since it doesn't have access to your configuration files. Conversely, any code that has access to your configuration files can access the settings without using the SettingsGroupNameAttribute anyway, since it can use the low level configuration APIs to do so (this requires ConfigurationPermission for read though, and much higher permissions for write).
- If you are really paranoid and don't want users of the application or anyone else, including code running in the same app domain as your settings class, to be able to read your settings outside of your class, you can choose to encrypt the settings before pushing them to the provider, and decrypt when you read them out. The settings API does not provide any specific way to do this, but you can use the crypto API in the .NET Framework. The configuration API also has the ability to encrypt configuration sections - see this article for more information.
Q: Does all this mean I cannot access settings in partial trust?
A: Not at all. We have done the work to ensure you can safely access your settings in partial trust. In fact, this should 'just work' for you in terms of reading and writing user scoped settings from your application. The only difference is that you cannot write out an unlimited amount of data, for obvious reasons. The number of bytes you can write through the settings API (specifically, the LocalFileSettingsProvider) in partial trust is restricted by an admin controlled quota, which is specified by the IsolatedStoragePermission class. This is just like how Isolated Storage itself works.
Q: You mentioned the configuration API a couple of times. What is this and how is it different from the settings API? I am a little confused.
A: There is a fundamental distinction between the settings API and the configuration API. The former provides an object model to manage application settings. This model uses a provider based storage scheme, so the storage aspect is abstracted away. Where the settings are stored is a provider specific detail - it could store them in raw files, in SQL server, in the registry or call a remote web service to retrieve them. The default settings provider we ship happens to use configuration to store settings, since that’s the most obvious store for settings in client applications. The configuration API is a little more low level and lets you create and update configuration sections in config files. So in some sense, the settings API sits on top of configuration.
So if what you want to do is store application settings and user preferences, then the settings API is the way to go. If you really need to implement configuration sections and/or access certain sections in config directly, use the configuration API.
Q: Is the settings functionality available only to Windows Forms applications?
A: The settings API itself has no restrictions at all - you can use it in any kind of application - client, web, VSTO, console, WPF etc. The default settings provider, LocalFileSettingsProvider, uses configuration to store settings, so it has certain limitations. For example, ASP.NET applications do not have user.config files, so you cannot write user scoped settings in web applications using this provider. Ofcourse, you can use the Profiles feature in ASP.NET 2.0 to very conveniently store user scoped settings. User.config files are also not supported for VSTO apps (in general, where the host application is native, like Outlook, Word or even IE). In these cases, you will need to write your own settings provider (which is quite easy to do, by the way, and there are good samples and docs in MSDN that describe how to do this) to be able to read/write user scoped settings. For the basic kinds of managed client applications like console, Windows Forms and WPF however, the LocalFileSettingsProvider is fully supported.
Comments
Anonymous
June 29, 2005
We have been getting lots of feedback on the new Whidbey Settings feature that I have blogged about in...Anonymous
July 05, 2005
Last night I was playing once more with the new application settings system in .NET 2.0.
For those not...Anonymous
July 05, 2005
Last night I was playing once more with the new application settings system in .NET 2.0.
For those not...Anonymous
August 07, 2005
Last night I was playing once more with the new application settings system in .NET 2.0.
For those not...Anonymous
August 15, 2005
I currently implementing a UserControl in Windows Forms. This control is using some settings (application and user scoped). Additionally, I implemented the IPersistComponentSettings. But if I using the control in a test application, the default values for user and application scoped settings didn't appear in the app.exe.config!
Or in other words, how should this feature work in detail?Anonymous
August 15, 2005
Ah, yes, I plan to write a whitepaper that explains the IPersistComponentSettings stuff since it isn't very obvious how it is to be used.
Meanwhile, here is what you need to do to get design time support (defaults going into app config etc).
Implement a constructor on your settings class that takes an IComponent, like so:
public class MySettings : ApplicationSettingsBase {
public MySettings(IComponent comp) : base(comp) {}
...
}
In your user control, use this constructor to create an instance of the settings class and pass in the control to it. Make sure this happens after the user control is sited in the designer, i.e., don't do it too early.
What this does is that VS will plug in a design time settings provider for this class that helps you persist defaults into app.config.Anonymous
August 16, 2005
Interesting, but I didn't understand your suggestion, because the settings editor already generated a type derived from ApplicationSettingsBase (in Settings.Designer.cs). Can you post a whole C# project or the whitepaper which demonstrates the IPersistComponentSettings. I'm very interested in this feature, because I'm writing a plug-in based framework.Anonymous
August 16, 2005
You can use the settings designer generated file. All you need to do is define an extra constructor for the class as I mentioned earlier and use that to create an instance instead of the default instance.
I haven't had a chance to write the whitepaper/sample yet, but will let you know when it is posted.Anonymous
August 29, 2005
About MendocinoAnonymous
January 09, 2006
Every example I see of this features shows how to keep form sizes and locations. But the XML file does not seem to keep multiple values for a single setting. So does this mean I have to define 50 FormSize settings and 50 FormLocation settings in order to keep the sizes and locations of all of my forms? Or am I missing something?Anonymous
January 18, 2006
DeborahK: Yes, you will unique need size and location settings for each form.
A mechanism we have provided for this kind of scenario is IPersistComponentSettings (also mentioned in an earlier comment), which can be used by a control to save its settings. In this case, for example, you can implement IPersistComponentSettings on a custom form that auto saves its size & location, and use instances of that form instead of the default Form across your application.
Look IPersistComponentSettings up on MSDN for more information. There should also be an article on this topic with a sample up there soon (if not already).Anonymous
February 02, 2006
Very informated. Just what I was looking for.Anonymous
March 08, 2006
Per leggere la configurazione da un assembly DLL la risposta è su http://blogs.msdn.com/rprabhu/articles/433979.aspx&nbsp;alla...Anonymous
April 04, 2006
I migrated my web using the Web Application Project, so I am not sure if this is related to that. I am getting this error when attempting to invoke a web service
The current configuration system does not support user-scoped settings.
The web service Url Behavior property is set to Dynamic since it changes based on the server the web is running on (in 1.1, it got it from AppSettings in Machine.Config).
I will read this blog entry closer and maybe the answer is in there.
Thanks
GarDavisAnonymous
April 04, 2006
> The current configuration system does not support user-scoped settings.
Somehow, the Web.Config had User Settings added to it. I changed the web service to static, removed the settings from Web.Config and the Settings.Settings, reset the web service to dynamic and the settings were put back into Web.Config correctly this time, as application settings.
So I think I am OK now.
GarDavisAnonymous
April 04, 2006
Gary: Yes, the ASP.NET configuration system does not support user scoped settings (the way to store user preferences in ASP.NET is through Profiles).Anonymous
April 12, 2006
Ingas asks a great question:
In windows form I have a ToolStripContainer inside a control (inherided...Anonymous
April 12, 2006
Одно из не совсем понятных мест в Visual Studio 2005 и .NET Framework 2.0 — этоAnonymous
May 05, 2006
If you missed it the first time out, check out Ragavendra Prabhu's Application Settings FAQ, which documents...Anonymous
May 05, 2006
The following links to .NET resources have been collated over time with the assistance of colleagues.&nbsp;...Anonymous
May 07, 2006
The comment has been removedAnonymous
May 08, 2006
Artem: are you trying to replicate the path construction algorithm? I would advise against doing that. If you need to access the path programmatically, you can use the approach mentioned in the FAQ.Anonymous
May 08, 2006
In fact I have a complex of applications which need to share the same settings. I tried to access the main application's settings from other modules. If there is other way to get access to the settings of another application than currently loaded one I would like to know it. Alternatively I can, of course, write my own settings provider.Anonymous
May 09, 2006
I am looking to share settings between applications without writing my own settings provider. I would like this information as well, if anyone knows.Anonymous
May 09, 2006
Artem/mhafner: I don't think there is a way to share settings across applications reliably with the default settings provider. I would recommend going with a custom SettingsProvider (these are pretty easy to write - there are a couple of samples on MSDN that should get you started).
Try also posting on one of the MSDN forums/newsgroups to see if anyone has other recommendations (as I mentioned, I moved to a different part of Microsoft ~6 months back, so am not in touch with this stuff).Anonymous
May 30, 2006
I have multiple applications that need to share settings also. Actually, I have libraries that have controls that need to share settings with other controls and with applications. Microsoft has this issue too, but I gather that they provided no support for it. I'm OK with writing a custom SettingsProvider; could you provide a URL for the examples you mention?
Thanks.Anonymous
May 30, 2006
You can find the samples in the .Net SDK documentation under .Net Framework SDK / Samples and QuickStarts / Samples / Technology Samples / Windows Forms Controls Samples.
Binding to Client Settings Sample
Demonstrates how to bind to application settings to reflect user changes.
Client Settings Web Service Client Sample
Shows how to use a Web service client to change application settings.
RegistrySettingsProvider Sample
Demonstrates how to persist application settings in the registry.
Here is the online link: http://msdn2.microsoft.com/en-us/library/ya940ct3(vs.80).aspxAnonymous
June 04, 2006
Is there sample about encrypting client settings?Anonymous
June 06, 2006
szzhouke: Not that I am aware of, sorry. Try asking on one of the MSDN forums.Anonymous
June 14, 2006
I have a class library that I used the project settings to create the settings file. The class library is referenced by a console app. The console app is run in a new process from a web service.
What i want to do is change the settings file for the dll and rerun web service webmethod and use the new settings. So far it seems like when the web app runs the exe the dll never reads the settings file. It also doesn't save it when I explicitly call the Save method. Is this a limitation of the Default settings? Should I just create my own settings file or class so I can control the loading of settings?Anonymous
June 14, 2006
Is it possible to save binary data like a List in user settings?Anonymous
June 19, 2006
Colin: I am not sure whether that scenario is supported. Please log it in MSDN Product Feedback and you should get a response from the product team.
jonj: Yes, that should be possible, provided the data is serializable.Anonymous
July 09, 2006
The comment has been removedAnonymous
July 11, 2006
You mentioned that there are samples in the .NET 2.0 SDK showing how to change the location of the user.config file by writing our own SettingsProvider class but it's still not clear to me how to do this. Can you point me to the specific example showing this? Thanks in advance.Anonymous
July 11, 2006
Burrj: You make a good point. I think the auto generated code wasn't designed to accomodate the possibility of a null default value for a setting.
Basically, I think the auto generated settings class is meant to tackle the basic settings scenarios, where you quickly hook together some settings to form properties. It doesn't do a good job today for (slightly) more advanced scenarios, and doesn't offer much flexibility. But the good thing is that we kept the 'notepad developer' experience for this feature pretty simple as well, so if you spend a little time understanding how things work, it is pretty easy to create and manage your own settings class.
Please also report this through MSDN Product Feedback so the team can work to improve this in the future releases (I moved to a different part of Microsoft some months back, so am no longer actively involved in this).
Regarding saving form size & location, see this post for a recommendation on how to do this:
http://blogs.msdn.com/rprabhu/archive/2005/11/28/497792.aspxAnonymous
July 11, 2006
Blue-Beetle: Here is the link to the settings provider samples:
http://msdn2.microsoft.com/en-us/library/ya940ct3(en-us,VS.80).aspx
Check out 'Client Settings Web Services Sample' and 'RegistrySettingsProvider Sample'.Anonymous
July 12, 2006
Cool, I just got feedback that they might just go along with .Net's default location for the user.config file. So, I might not need to write my own SettingsProvider.Anonymous
July 12, 2006
Now that it looks like my workplace might go along with the default location for user.config, I want to enable using the "roaming" user.config file.
I'm a little confused about enabling the "roaming" user.config file. How do I do this?
According to your FAQ:
"To store a setting in the roaming user.config file, you need to mark the setting with the SettingsManageabilityAttribute with SettingsManageability set to Roaming"
I don't see any way to do this in the Visual Settings Designer. Are we supposed to do this manually? If so, how?
Thanks for any information or help. :)Anonymous
July 17, 2006
Never mind. I figured out how to enable it to use the "roaming" user.config file. It was right in front of my eyes. On the settings Visual Designer we can set the name, type, scope and default value of any settings variable. I didn't see any way to set the "roaming" attribute.
But when you click on a setting, you will see the properties tab on the lower right of the IDE. In this tab, you will see additional attributes (with roaming being one of them) you can set for each settings variable.Anonymous
July 19, 2006
The comment has been removedAnonymous
July 21, 2006
Raj: Yes, but you can use ApplicationSettingsBase.Upgrade() to upgrade your settings from the previous version. Look the method up in MSDN for more information.Anonymous
August 06, 2006
Hello Raghavendra,
Sorry to bother you with this but I have a rather interesting problem with the ApplicaitonSettingsBase.
I have a .NET application that I'm writing that's using a singleton object which has been derived from ApplicationSettingsBase. When I'm ready to deploy my project, I use a .NET EXE packer to package up my custom dlls. I noticed with the packed EXE version of my application, simple primitive types are successfully stored and retrieved from user.config. However, more complex data structures such as BindingList<SomeType> are saved but not retrieved from user.config.
The interesting part is, if I do not pack my .NET exe application, the unpacked version can successfully save and retrieve both primitive types and complex data types.
I've also set the ApplicationsSettingsBase as SettingsSerializeAs.Binary, and marked all required items / classes as Serializable.
The only reason I'm trying to pack my EXE is to make it harder decompile by using some custom obfuscation and crypto/compression by the EXE loader.Anonymous
August 09, 2006
The comment has been removedAnonymous
August 09, 2006
Brian, Matt: First of all, a caveat: I moved to a different team in Microsoft several months back and have been working on a completely different problem space, so am rather out of touch with this stuff now.
Brian: Try catching all exceptions at the point when ApplicationSettingsBase loads settings from the provider (usually at first setting access). There might be a deeper problem, like the BinarySerializer failing to load certain types.
Matt: I suspect there is a bogus user.config file lying around somewhere, or maybe your app.config has some unexpected entries in it. Try resetting from the settings designer to see if that solves your problem. Johan Stenberg (http://blogs.msdn.com/johan_stenbergs_blog/) may be able to help you further if you have questions around the design time settings experience.Anonymous
August 10, 2006
The comment has been removedAnonymous
August 11, 2006
The comment has been removedAnonymous
August 12, 2006
Hello Raghavendra,
Thanks for the fast response, but I've pin pointed the problem. ;)
ApplicationSettingsBase internally uses Refleciton and Assembly.Load() to seralize/deserialze types. Deserialization failed for complex (custom) types because the EXE assembly containg these types was packed and encrypted by the loader as a resource (inside the loader EXE)... since the runtime only saw the EXE loader assembly, it failed to resolve types correcty.
Solution:
Move all seralized types that need to be accessed by the runtime to a seperate DLL library. Pack the EXE assembly and DLL assembly then hook assembly resolve type events emitted by the CLR to correct the problem.
-BrianAnonymous
August 15, 2006
Brian: Good to know you got it working!
Marty: Sorry, I am not aware of how NetRun deployment works. If you can isolate an issue, please report it through MSDN Product Feedback so the right folks can investigate.Anonymous
November 17, 2006
I'm developing a Windows CE application. I need to persist some settings across applications sessions like web service url. But there is no Settings option in Win CE Device App project. Any suggestion on how to persist the settings? Thanks.Anonymous
November 19, 2006
'Gbenga: Unfortunately, I don't know the answer to your question. I suggest posting it on one of the .NET forums or newsgroups.Anonymous
November 21, 2006
Hello rprabhu, in the answer of the last question (Is the settings functionality available only to Windows Forms applications?) you wrote, that user.config isn't supported for VSTO apps. I found out, that this is not correct. I use userSettings in my VSTO-OutlookAddin and it works. The only 'problem' is, that the path, where the user.config is saved contains "Microsoft_Corporation" istead of the AssemblyCompany of my AssemblyInfo. Could it become a problem? Is it safe, to use the default settings provider in a VSTO app, or should I write my own settings provider? Thanks in advance Regards, TonyAnonymous
November 22, 2006
Tony: IIRC, using the LocalFileSettingsProvider within VSTO is not a supported or tested scenario. It is not explicitly blocked so might seem to work, but I recommend against using it in shipping code, as you might run into problems (unfortunately, I don't remember what specific issues there were - I moved to a different part of Microsoft over an year ago). But do double check by posting this question on the MSDN forums if you wish. I would recommend writing your own provider, which is pretty simple to do, starting with the samples/docs on MSDN.Anonymous
December 16, 2006
Tony, I have the same problem when running my apps under Visual Studio when code is running under an app domain that doesn't have an executing assembly. For example, I have a host process (app domain) that creates several child app domains (one for each plugin). If I use the config manager under one of the plugin domains (which doesn't have an executing assembly), the config manager tries to pull the properties for the user path from the executing process EXE using a native call. Unfortunately, the executing process EXE is usually the vshost.exe wrapper process, which has Microsoft as the company, and the VS version as the version instead of the information from my process executing assembly. I suppose when deployed and not running under VS it would probably come up with the right company and version values, but it makes testing annoying.Anonymous
December 18, 2006
Aaron: One way to quickly test correct behavior is to use Ctrl + F5 in Visual Studio instead of F5. This will cause the app to run normally and not under the vshost process. Also, there is an option in Application Properties in VS to disable the vshost process if you want to.