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.
Related
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.
Every .NET project I've worked on uses an app.config file for its configuration. Fair enough.
Today I am asking, "is there a better way?" (in the spirit of continual learning of course)
I guess my specific questions are:
Does it matter either way if I use app.config or settings file?
Are there any scenarios where settings files should not be used e.g web sites where you should use a web.config instead?
Other than not having to edit xml, are there any other benefits gained by using settings instead of app.config, e.g. its easier to deploy or maintain apps etc.
Clarification:
I'll put this question another way:
Can I completely ignore app.config files if I want to and keep all the configuration in a settings.cs file and interact with configuration via the designer only?
IMO, the main advantage of settings files is scoping (for client apps at least) - that is, that you can have different values of the same setting for a different user. It also allows you to easily edit and save user-scoped settings. And yes, if you don't like editing XMLs - then settings have the advantage of a designer too :)
I don't think it really matters either way, as long as it works for you.
I wouldn't use settings files in situations where values are going to change after an application has been set up.
I tend to use a mixture of custom settings in the web.config and settings within a database.
Custom settings in the web.config are based on this here http://msdn.microsoft.com/en-us/library/2tw134k3.aspx These settings will be things that are not likely to change once the project has been set up, but allow for you to easily share class libraries with other projects.
The database settings are things that are likely to be updated at times during the project, e.g. email addresses
In Visual Studio, when we develop, the web.config file is often modified but I don't know what is modified, and what are consequences in production envirionment for performance, and if configurations sections are important.
For example :
<compilation>
<compilers>
<runtime>
...
There are lot of sections I thinks are not essentials, and without it or with another configuration, can improve performance in production environment.
So my question is :
What are you looking for in web.config file in production environment to not to lower performance and have a light configuration file ?
What are best practices ?
Thanks for your answers !
In Web.Config you can configure whether you want debug assembles or release assemblies. You can tune the performance of WCF, thread pool. You can configure logging, etc.
Visual Studio doesn't change critical settings for you automatically. The only thing it does however is enable debug assemblies when you're trying to debug your app. It asks you for confirmation in that case. For production you can disable debug assemblies.
I would recommend you to use a diffmerge tool to see what sections are added since last commit. However please note that shorter config doesn't necessarily mean better performance.
Your web.config is merged with machine.config which has many sections. So not putting a section usually means you're not modifying the defaults in machine.config. Adding a section doesn't mean you're adding something new. It only means you're configuring something that will have otherwise some default setting.
As far as best practice is concerned. It is advisable to have a short config file to make it more maintainable. There is no point in specifying the defaults in the config again if they are implicitly default or are otherwise in machine.config anyway. VS2010 already avoids unnecessary sections.
The number of sections in a web.config file has nothing to do with performance.
Some machines will require more things configured than others (hence a size difference) in order to run the same application.
As Hasan pointed out, the web.config is merged with the machines config file. You might very well have 1 machine (call it test) which defines things in it's machine.config that isn't defined in your production config. So, for test you might not need certain sections that production would require.
Also, the machine configs for a particular item might vary. In a web farm scenario it is common practice to override the machines config file with a common machinekey. This doesn't have a performance impact but does impact whether you are going to be successful in load balancing the site.
To iterate: the number of sections is immaterial to performance. The contents of defined sections, on the other hand, is.
Now, how to improve performance: This is on an application by application basis. For production you will want to turn off debugging, and turn on things like url compression for static content.
You might want to turn on compression for dynamic content as well or even configure certain directories to inform the browser that content is cachable (like /images, /css, or javascript). Incidentally, these would generally increase the size of your production config file and has certain consequences (like when you want to change a css file), but will generally yield improved performance for the client.
For other items you might turn off logging or use a completely different logging storage provider. We use elmah and our dev boxes are configured for in memory storage whereas production is configured to use a database server. Not necessarily a performance issue, but certainly one of concern.
The point here is that a config file should be used for the purpose of making sure the application can execute on that particular platform / machine.
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.
Why is it better to store data inside an appSettings element (or inside a custom section) of a web.config file than to store it in a class?
One argument would be that by using custom sections we don’t have to recompile code when we change data, but that’s a weak argument, especially if we’re using Web Sites, which get recompiled automatically whenever code changes!
Thank you
Because you can change it on the fly and use it without regard to class structure. Your configuration can vary from each developers machine to staging to deployment environment by changing and maintaining a single file independently of the code, and you can take advantage of *.config masking with different areas of your site.
Hard coding anything configurable is a recipe for failure and it absolutely will bite you - this is just a matter of experience, if you don't believe it then you have but to wait a little while!
By putting settings into web.config, you have them all in a centralized location.
Also when deploying a web site, you might want to precompile it once. So you won't be able to change the source afterwards (without another recompilation).
It's not really a concern of just recompiling the code, it's more about re-deploying the code. Normally, you don't deploy code to the web server, you just deploy the binaries and aspx/html files. If you hard-code your config data in the code, you'll have to rebuild and redeploy the library or application to get the change up to the server, which is a lot more work than just updating the web.config.
Putting data in the web.config file also allows the same code to be run in different environments with different environment-dependent data. This can mean running the same website code in staging with a test database connection string and in the production environment with the production database connection string. Or it could mean allowing the developers to configure the data for their own tests without changing any code, as 'annakata' mentioned.
It's just a WHOLE lot easier to manage and update the settings.
If you're using Notepad to do your development and putting the code out on the server, I would agree that there is little benefit, but if you're using Visual Studio and you build your website and publish it, you're publishing the pre-compiled dlls and not just updating text source code (.cs or .vb files) on the server. So when it comes time to update a setting at that point, anything in the web.config can be updated by simply modifying the text file, where as with other changes, you have to re-compile t whole web site and publish it.
And from experience, that becomes tricky when taking over after other developers that weren't careful about ensuring everything needed to make a web site work is in source control. I'm now stuck with a web site where we can't update huge chunks of it because of (kindly putting it) non-standard practices in the past.
Being able to update something without re-publishing the site is a huge blessing in my situation, and you never know who the poor maintenance programmer will be that takes over on your code.
Be nice to him or her. Make it easy to make simple changes.