All, I have a large C# application that I am writing a plugin for. I want to provide settings for this plugin and came to the conclusion that writing my own setting manager ect. and creating XML settings which would be put in the relevant special folders is the best way to go. However, I can't remember why (after coming back to project) I came to that conclusion over using the Properties.Settings.MySetting route. Can someone offer any advice in terms of what method is more preferable in my case?
Is writing my own overkill here, or is there a clear and obvious benefit?
I aplogise if I have asked this on the wrong Stack site.
Thanks very much for your time.
It's a good question and I'd like to let you know that you came to that decision because your DLL plugin cannot normally work with its own app.config file (where the settings are stored).
This happens because the ConfigurationManager looks for app.config files attached to the executing process, which is main exe file.
You got several options over here, and the best one is to point the configuration manager which file to use as a config file which is greatly described at this page.
Related
I'm looking for the best way to generate a custom version of my application that contains unique resources -- settings, strings, images, etc. My app is a custom tool that will be used by others and needs to be customized and branded for their use.
Eventually, the build process will be automated and driven by another app that produces the custom build based on the client's registration info. I'm trying to prove that concept before I go much further.
A batch "make" process would be ideal but I'm not sure if that's possible in VS. And, I suspect there's more than one way to do this but some may be better suited to my needs.
Has anyone done something like this?
Thanks!
If what you're looking for is a way to programmatically control the resources for a group of builds, to me the obvious way to do this is have each app get these from a centralized database when it starts up. You then have complete control over which apps will receive which resources and can control it all programmatically.
One possible solution:
Edit the resources.resx file programmatically.
Run DEVENV to build the target.
Good? Bad? Pitfalls? Better methods?
I'm refactoring a WPF application and dealing with cleaning up storage of settings. I've re-written most to use the application's settings (Properties.Settings.Default) and this technically is working right now it seems to generate rather ugly paths in the %appdata% folder such as:
C:\Users\me\AppData\Local\Company_Name_With_Underscores\program.exe_Url_xs3vufrvyvfeg4xv01dvlt54k5g2xzfr\3.0.1.0\
These also then result in a new version number folder for each version that don't get cleaned up ever unless apparently I manually do so via file io functions.
Other programs don't seem to follow this format, including Microsoft programs, so I'm under the impression this seems like one of those 'technically the best way but not practical so nobody uses' solutions. Is this the case or am I missing something to make this more practical?
I ask mainly because I can foresee issues if we ever have to direct a customer to one of these folders to check or send us a file from there.
I'm using .NET 4.0 right now.
Im reading 2 books about WCf and one of them is showing Configuration as App.Config and the other is showing via Code in C#
I want to know which approach should i use and what are the benefits for each other.
Does the Wcf Configuration Wizard supports also the c# code behind configuration ?
thanks for the answers.
Configuration files can be changed without a rebuild (handy, say, to add a custom inspector or serializer), is pretty easy to copy/paste between client/server, has support from the IDE tooling.
Code is handy if you are configuring the system at runtime (i.e. getting the information from another server), or are running as a library (dll) and can't guarantee that a configuration file will a: exist, or b: have your configuration. Code also has intellisense / static checking to avoid brain-dead errors (typos in the xml etc).
I'd use a file until you know you have a scenario that doesn't work well with a file.
Also consider: how hard is it for you to deploy a code change vs a configuration change? for me they're about the same, but that might not be the case for you. Maybe it is easier to just change the config on the machines? maybe not.
I guess it depends on your needs. I personally tend to configure wcf with code, especially for things that are unlikely to ever change. That might include error handlers/logger, behaviors, authentication modules, service host factories, etc
For more dynamic stuff, like connection strings, passwords, file paths, etc are configured in .config files.
One of the biggest advantages of using code is that your code now can support things like IOC/Dependency injection, compile time checking, etc.
I don't buy into the idea that everything should be in a config file because it's easier to change it. In most cases I've seen it never changes in production.
The configuration file approach is better, it gives more flexibility. For example i change the authentication type (username password/windows) by changing config files.
I think this is what the asker of this question is getting at, but its hard to tell and there's no accepted answer...
I have a C# app built using visual studios application settings. A really useful feature would be the ability to export the settings in one file. Similarly it would be useful to be able to import configuration files exported by another instance.
I guess this would ordinarily be a matter of copying and pasting the file they're stored in, but my users won't be savvy enough for that sort of thing, so I'd like to do it through menus and dialogues.
To complicate matters, I had to add my own settings class in addition to Properties.Settings (the visual studio default) and I'd like the generated file to be a merge of the two sets of options. (To confuse matters further, I'm not sure where the custom settings file is being saved, but that's a separate question methinks...)
So to recap:
Where is my custom settings class likely to save it's XML?
How would I go about merging the two files?
On import, how could I split them?
I'm going to be a bit blunt about this. The .NET framework design is overall rather excellent. Easy to learn, few surprises, no fat. But not everything is great. System.Configuration has a very high suck factor. Between an absurdly complicated object model and an implementation that was paralyzed by security concerns, it inevitably becomes a PITA when you try to extend it beyond the point-and-click settings designer.
Just don't go there. Using XML serialization to load/save your own configuration class(es) is a wholeheckofalot easier than battling that borked design.
I have a problem using a dll with a service reference that should read a custom configfile.
My situation is as follows:
- DLL which read its own config file (by using configurationManager.openExeConfiguration(dllname.dll.config))
- main application which uses the DLL (3d-party application)
This is working fine, the dll reads the right configsettings.
Now I must add a service-reference to my DLL. The problem is that it tries to read the standard app.config file (which doesn't exist), instead of reading the dllname.dll.config file.
Anyone has a solution for this?
Thanks,
In .NET, it has never been the intention that libraries should have their own .config files, so there's no official support of this and lots of issues are sure to abound.
Although you can read such a file with ConfigurationManager.OpenExeConfiguration, this was never the intention of that API - it's mainly there to provide an API for editing application .config files.
You would be much better off if you let the library read from the app.config file instead, using the standard ConfigurationManager API. You can still have custom sections for your library in the app.config file. This is the way it was always intended to work, and it will give you far less trouble.
Not to revive an old question, but since it's unanswered I'll chime in.
While playing in the config section as of late, I cam across a couple of great resources. One goes in the the details of having clients and servers read custom configs by basically inheriting from the ServiceHost/etc. and overriding the methods that load the configuration.
Now, granted, I do agree with Mark, there are always exceptions and cases where this method could provide additional flexibility. I just felt compelled to pass along the article in hopes you'll also appreciate it.