Cool Client Stuff

Hi Prabhu,

I had seen your "client settings" blog from part1 to part3, in all of these you are explaining about the ApplicationSettingsBase but I want to write my own custom SettingsProvider class. please help me out in
How to write a custom SettingsProvider class?I am asking this question as we could not able to get any links explaining it in better way. If you can provide any samples that will be helpful and also please provide us a solution how to set this custom SettingsProvider to the application, so that application reads the settings from the custom SettingsProvider rather than default LocalFileSettingsProvider

Thanks
MDeevi.

Sorry! Prabhu, I could not able to find the samples in Beta2 SDK. Can u please get me the links or sample code so that i will try to change according to our requirement.

Thanks
MDeevi.

Thanks Prabhu, Got the path for samples and could able to write custom SettingsProvider class. But there is a problem we are getting an error saying that

"Failed to load provider type: MyCustomSettingsProvider"

I configured my settingsprovider in the following way in Settings.CS file as

[SettingsProvider("MyCustomSettingsProvider", "MyCustomSettingsProvider")]
class Settings : ApplicationSettingsBase
{
. . . . . .
. . . . . .
}
Please try to help me out how to get rid of this error.

Thanks
MDeevi.

Thanks Prabhu for your quick response. Its working fine when I changed that to

[SettingsProvider("MyCustomSettingsProvider.CustomSettingsProvider", "MyCustomSettingsProvider")]

and also working if I had given it as

[SettingsProvider(typeof(CustomSettingsProvider))]

Thanks for your help. Now I want to use SQL Server 2005 Express to store my settings using the custom SettingsProvider. Can you give me some suggestions how to do that...

Thanks
MDeevi.

Here's a scenario I can't figure out how to address. I have a service that is currently using the new .NET 2.0 settings. These settings have application scope. What I want to be able to do is to change them during the installation phase of the service. I'm not having any luck figuring out how to go about doing this though. Can a service even call Save() on the settings? Where would that persist to?

I can set the value of an application scoped setting by doing:

Properties.Settings.Default["SettingName"] = "Blah"

Upon calling Properties.Settings.Default.Save() though, the value disappears. Any suggestions?

Can the path returned by Application.LocalUserAppDataPath and the path used by LocalFileSettingsProvider be the same? I need to store additional files, and it would make supporting the application alot easier if they could reside in the same directory (<AppPath>\My Company\<exe> versus <AppPath>\My_Company\<exe>_<signatures>).

Could there be a way to get the path that the LocalFileSettingsProvider uses? For example, Properties.Settings.ApplicationPath and Properties.Settings.UserPath?

It really doesn't matter to me what the directory is. It just would be nice to put everything in same place.

Hey, that's great! You should put that into your FAQ.

I created a custom Settings Provider and now I do not want to use the app.config file for the settings. Does it arises any issues if I am not going to use app.config file? Does app.config take priority over the settings class for assigning defaults?

Is there any mechanism in Visual Studio 2005 that we can tell the settings designer to generate the class but not the app.config values?

Please let me know about these details....

Thanks Prabhu for your reply. We are planning a large application with many components (dlls). We realize that we can use different settings classes (groups) to separate functionality among the various components.

To accommodate our settings groups, we are considering a hierarchical approach whereby MainSettings would hold some settings and also hold references to other settings classes/groups, which in turn could hold references to other settings classes/groups. For instance, you might access a setting via MainSettings.Component1Settings.SubcomponentASettings.TheSetting. however there is only one app.config file for the entire application! How do most projects handle settings for components? Does the main app handle reading/saving settings for all the components?Can we encounter any potential problems with this approach? Does the internal class generated by Settings Desginer prevent these type of references from going across dll boundaries?

Please let me know about these details....

How do we access the GroupName information from GetPropertyValues and SetPropertyValues in the custom SettingsProvider?

Hi Prabhu,

We have implemented a simple SqlCustomSettingsProvider based on the Registry example provided in MSDN Samples.

We have many settings and want to group them. In fact, we want to group them hierarchically, but that is outside the scope of the group name issue.

We noticed that using multiple settings classes is a logical way to group settings. However, we would like to use a single settings provider for all settings classes. The settings architecture documentation (ApplicationSettingsBase class) states that "each class defines a settings group" and that "if the group name is not explicitly set by decorating the wrapper class with a SettingsGroupNameAttribute, then a name is automatically generated".

Our design requires us to store the groupname in the settings database. This allows 2 different settings groups to each have a setting with the same name.

How do we access the GroupName information from GetPropertyValues and SetPropertyValues in the custom SettingsProvider?

Please kindly provide us some solution so that we can continue the rest of the things.....

Thanks Prabhu, We will look into the solution provided by you. If we face any problem we will get back to you.

Thanks in advance....

I have a big issue with client settings I would appreciate if you could comment on. When using strong names, the expected behavior of ApplicationSettingsBase.Upgrade() is thrown out the window if your version changes because an entirely new directory is created one level above the directory where side-by-side versions are contained, which apparently is the only place the default implementation of Upgrade() looks... Was this considered during the design and is it intentional? What is the recommended work-around? I am considering writing my own provider, because my assembly must be strong-named and I absolutely require upgrading settings with each release.

Unless I'm missin' something, it didn't make it into RC1, did it? I recently tested it and the problem was still there unfortunately. Guess I have to wait until release...

By the way, thanks for the quick response!

I would like to have settings which are scoped which can be written by one user and and read by all users.

The UserScopedSettingsGroup doesn't work because the same user.config isn't read equally by all users. The ApplicationScopedSettingsGroup doesn't work because it is read only.

I realize I can create my own SettingsProvider but then I seem to lose the .config file location, grouping, heirarchy, and general structure provided by the LocalFileSettingsProvide.

Do you have any recommendations?

j

P.S. I also can't find the samples you mention in the faq on the Visual Studio RC1.
i.e. / .Net Framework SDK / Samples and QuickStarts / Samples / Technology Samples / Windows Forms Controls Samples

We have an application that dynamically loads DLLs using reflection. This is essentially a plug-in architecture - it looks for DLLs in a particular directory that implement a particular interface and loads them.

The question is this: Some DLLs need to have their own configuration data. With Visual Studio 2005, we're allowed to create the settings information for the DLL project, and all of the constituent files are created (app.config, settings.*). However, when the DLLs try to access data using Properties.Settings.Default, the settings are not loaded from dllname.dll.config. How can we cause each DLL's .config file to be loaded (and the Settings.Designer.cs properties to be loaded as a result)?

Hi;

We have a case where the dll is a Word Add-In and for securtiy reasons some of our customers will not allow any changes to winword.exe.config. They also will not allow any files to be placed in the Office subdirectories.

So we need to place config information with our dll (which is in a different directory). How can we set things so our dll can read from autotag.dll.config?

Again, this is a security limitation from some of our customers, we cannot use winword.exe.config.

thanks - dave

I know that ConfigurationManager.GetSection uses the cached instance of objects inside the ConfigurationManager. I have two questions:

1. Do the following two ways to access settings:
string str = Settings.Default.testSetting;
and
Settings set = Settings.Default;
string str = set.testSetting;
also use cached instances and what's the difference between them?

2. If I call a class that is inside my configuration class library that calls ConfigurationManager and returns ConfigurationSection instance to my application will there be caching for subsequent class calls in my application?

Hi blog

I am trying to make an extension to my.settings as I want to save the application password encrypted.

I am trying to acomplish this by making a partial class:

Namespace My
 Partial Friend NotInheritable Class MySettings
   Inherits Global.System.Configuration.ApplicationSettingsBase
       Private Function EncryptString(ByVal strPlain As String) As String
         ...
       End Function
       Private Function DecryptString(ByVal strCrypt As String) As String
         ...
       End Function

       <Global.System.Configuration.UserScopedSettingAttribute(), _
        Global.System.Diagnostics.DebuggerNonUserCodeAttribute(), _
        Global.System.Configuration.DefaultSettingValueAttribute("")> _
       Public Property frmLoginPassword() As String
           Get
               Return Me.DecryptString(CType(Me("frmLoginPassword"), String))
           End Get
           Set(ByVal value As String)
               Me("frmLoginPassword") = Me.EncryptString(value)
           End Set
       End Property
 End Class
End Namespace

This seems to be working, but every time I modify the Project Application Settings, the frmLoginPassword property is re-created in the original class hence giving a:
'Public Property frmLoginPassword() As String' has multiple definitions with identical signatures.

Am I misusing the whole settings concept or is there a workaround?

Regards

> The configuration system does not support config files for dlls, only exes.

Will they address this in the future. I think security restrictions will make this more common - especially for Add-Ins.

thanks - dave

I must admit even after reading the above, I'm still having trouble getting our data layer dll to use the main exe's configuration file for a connection string.


The exe has a config file and an application setting for connection strings.

The dll has an application setting for connections strings.  I have tried labelling this the same and different from the the main executable.

I then alter the config file (the executables) in the test environment, and the application continues to fall over.  It is easily fixed by hardcoding a valid connection string in the dll's settings, but this isn't configurable.

Help.

I'm having trouble loading a custom SettingsProvider from a COM object written in .net.  This same provider works with no problem in a WinForms App.

I'm explicitly declaring the provider's type in the SettingsProvider attribute.  My settings class is declared like so:


<SettingsProvider(GetType(DBSettingsProvider))> _
Public Class SomeSettings
   Inherits ApplicationSettingsBase

       Public Sub New()
           MyBase.New() '<-- Breakpoint here
       End Sub

etc.


When I instantiate the SomeSettings class and set a breakpoint where indicated, the properties are undefined before calling the parent's constructor, but after stepping over the call they contain this message:

Could not load type 'Configuration2.DBSettingsProvider' from assembly 'DBSettingsProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.

Initially I thought it might be because the application was running a different directory than the COM object's location, but I've tried copying the SettingsProvider's assembly there with no luck.  I've also tried hooking the AppDomain.CurrentDomain's AssemblyLoad event, but it never gets called.  What's the best way to track down where/how the CLR is trying to load the provider?  Is there a way to pre-load it or set an explicit path to find it?

Thanks,
Andy

Sorry for the delay -- I was busy on another project briefly, and then this took a while to figure out.  The problem seems to be: while "normal" assemblies referenced by the COM object are loaded in the LoadFrom context, the SettingsProvider was loading (or failing to load) in the Default context.  The upshot of this was (as I suspected) it was probing the calling App's directory, not the COM object's.  The Fusion Log viewer helped confirm that -- it's a good tool that I was unaware of.  Thanks very much for the pointer.

The fix was to load the assembly in the AppDomain's AssemblyResolve event.:

[VB] Return GetType(DBSettingsProvider).Assembly
or
[C#] Return typeof(DBSettingsProvider).Assembly


Why, (you may ask) did my experiment of just moving the provider assembly to the calling app's directory not work?  I had an unrelated bug:  When initializing the provider, I was accessing Assembly.GetEntryAssembly().GetName().Name, but in the COM object, GetEntryAssembly() is Null/Nothing.

So, thanks for the tip -- I could have gone around in circles for a long time looking at that.

 Thanks again for the help.  While I'm picking your brain...

 I can't seem to find any way to set values in the Config parameter that gets passed to the SettingsProvider's Initialize method.  Are there attributes I'm missing, or some other method of adding Name/Value pairs to Config?

Yes, I'm familiar with the NameValueCollection type.

The problem is that the Initialize method is called from somewhere within the CLR, so I don't have direct access to the collection.  I can't figure out how to let the CLR know what I want to put in that NameValueCollection  parameter when it calls Initialize on my SettingsProvider.

Got it.  So in the Windows Forms case, I'll need to get my initialization information from other (persistent) sources.  The application/consumer of the settings can't pass me anything.

That's not great news, but better to know than to wonder.  Thanks for the Info.

I know you've stated before if you want to change where the user.config file is saved you have to write your own settings provider, but I like everything about LocalFileSettingsProvider except the "Evidence" stuff that it appends to the application name in the path to user.config. Is there anyway to extend LocalFileSettingsProvider and just override this on piece?

I need to know exactly where the user.config file is going. Standard convension would be the exact path used by LocalFileSettingsProvider except that ApplicationName_Evidence... should just be ApplicationName. I guess the evidence part would be ok if it is constant. What causes the Evidence Hash and the other part to change? Will this always be the same for my application or would changing the assemblies loaded, for example, change it? I guess my question now is what determines what is appended to the application name, and what factors would cause it to change?

Thank you very much for answering my questions. Just to make sure I have things straight, so if we decide to obtain a certificate and sign our coding using signtool.exe, then the Evidence hash would be dependant on the public key? So as long as our public key stays the same, so will our Evidence hash? The signature changing due to the code changing will have no effect on the hash? Am I understanding correctly?

This does not seem to be the case. From my tests with signing the executable using signtool.exe, the only thing that I can tell that affects the Evidence hash is the executable location. Having it signed or not signed has no effect. I really need to folder name not to change on me; do you have any other ideas to get the Evidence hash to be a fixed value?

Form that test the Evidence hash is still only based off the application location if the assembly is signed with a certificate. However, if I use strong names it seems to work as you stated. Is this a bug? We really don't want to use strong names but are fine with signing with a certificate. Is there something in the certificate signing process that I can do differently to make this work? Right now I just generated a .pfx file and added a post-build event that runs signtool.exe on my executable.

We don't like strong naming because it forces all code called to be strong named, we have concerns about versioning, and the main complaint, it dramatically slows down developers with all the verification that it requires when you build. I guess we'll have to live with the application's location determining the hash. Thanks for all your help.

Hi, I'm back. I'm trying to write a custom SettingsProvider and from looking at the examples (which aren't very complete by the way since they don't implement IApplicationSettingsProvider) when getting a value from storage, they are only setting the SettingsPropertyValue's SerializedValue and not the PropertyValue. When I do this, the SerializedValue is correct but the property is always returning the default value. Could you explain the interactions between the PropertyValue and SerializedValue and how they are used to determine the value of the property? Thanks.

Hello,

I'm late to this chat (which has been really helpful) so I hope you're still there...

I've created a custom ServiceProvider that reads/writes settings to a specific location used by a DLL.  This is working a charm when the DLL is initialised by a .Net application thread.

The problem is that the DLL is also loaded in a COM thread.  In this case, the attribute [SettingsProvider(typeof(Csaaw.CsaawLogic.CsaawSettingsProvider))] is seemingly ignored (the SettingsProvider's constructor is not called).

Also, if I interogate the Providers property of my Settings class (to get its Count) I receive the following exception:

Failed to load provider type: Csaaw.CsaawLogic.CsaawSettingsProvider, CsaawLogic, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.

I've been unable to figure out why my custom ServiceProvider would behave differently under COM whereas the LocalFileServiceProvider works fine.

Any thoughts?

I've resolved the issue.  In case anyone else encounters a similar problem, the resolution was to install my DLL in the Global Assembly Cache (GAC).

The problem was that when my COM application was using the DLL, the Deserialize(...) method would be looking for the DLL in the COM application's Path.

Adding my DLL to the GAC made it visible to the Deserialize(...) method.

Thanks for the tip and for hosting the discussion.  Without it I would've been pretty stuck!

Rob

PingBack from http://outdoordecoration.info/story.php?id=1525