Has any put much thought into this? Personally, I think managing endpoints in configuration files are a pain. Are there any pros/cons to doing one over the other?
Only points in favour of configuration files from me.
Managing endpoints in configuration files mean that you don't have to update your application if (or perhaps I should say when) the endpoints change.
You can also have several instances of the application running with different endpoints.
I tend to like the config approach myself too, other than the config file can get pretty big.
The one thing I have noticed with WCF configuration is that there is a lot of stuff that you can do from code that you can't do in XML config without adding your own custom extensions. In other words, doing config in code will allow more flexibility, of course you could also just code your own extensions and use those from configuration.
However, do note that there is what I would consider a 'bug' in Visual Studio that if you start making your own extensions and including them in XML, then VS won't like your config file any more and will tag them as errors, and then if you try to add a new service through the wizards, it will fail to add the endpoint to the configuration.
This is sort of a followup to my own answer:
After months of having everything in xml configuration, I'm changing everything to construct the endpoints and bindings in code. I found a really good case for having it in code;
When you want to have a deployable / sharable .dll that contains WCF clients.
So for example if you have a CommonClients.dll that contains all your WCF interfaces and contracts to communicate with some remote server, then you don't want to also say "here is 100 lines of xml that you also have to drop into your app.config for every client to make it work". Having it all constructed in code works out much better in this case.
There is also a "feature" of .NET 3.5 where if you have some wcf extensions, you have to specify the fully qualified assembly name. This means that if your assembly containing the extensions changes the version nnumber, you have to go change the assembly name in the config file too. It is supposedly fixed in .NET 4 to use a short assembly name and not require the full name.
Offhand, an endpoint in a config file doesn't need to be recompiled when it's changed. This also means that you just need to update your config file when moving an application from Development to UAT to Production.
If your just coding something for your own use at home, then there's no real difference. However in a business environment, having the enpoint defined in your config file saves all sorts of headaches.
When using an app.config, your application does not need to be recompiled to adjust to a change. Also it can be resused in multiple situations with the exact same code. Finally, hardcoding your endpoints (or anything subject to change) is poor coding practice. Don't fear the configuration file, it's declarative programming. You say, "I want to use this endpoint." and it does the work for you.
I generally do programmatic configuration, as I don't want to expose my applications internal structure the the user. The only thing I keep configurable is service address, but even this I keep in userSettings section, not system.ServiceModel.
I prefer and recommend the configuration file approach. It offeres a lot of flexibility by allowing to make change to your server without the need to recompile the applcation.
If you need security, you can encrypt the config file.
The biggest worry with plain config files could be that it can be accidentally (or on purpose) modified by the end user causing your app to crash. To overcome this you could make some tests in code to check the configuration is ok in the config file and if not, initialize it programatically to some defaults. I presented how you could do that in another answer to this question.
It's just a question of how much flexibility you need.
Usually I prefer the config file approach.
Check out the .NET StockTrader app. It uses a repository to store config data and has a separate app to manage the configuration. The setup and structure is pretty advanced and there's a fair bit of head scratching for anyone like me that only has the basics of WCF configuration so far, but I would say it's worth a look.
Related
I'm not sure about what changes should I care about when going to production using Migrations and the publish option through File System.
I mean, for example, I guess I should not use any initializer when going to production right? since I might be deleting data there I think I should always get the script and run it in production db. Is this correct?
What about Configuration class?
Should I turn to false AutomaticMigrationsEnabled on each publish?
Is there a better way than modifying the connectionstring in web.config and app.config from dev to production each time I want to publish my code?
Thanks in advance! Guillermo.
I've found the perfect answer with Web Config transformations
The idea is to have the Web.Config and Web.< environment >.Config.
Then each Web..Config has for example replacements to the values of the original Web.Config so when we publish the transformation of the environment selected is run and ConnectionString can be changed automatically for the one in production.
This Introductory Video is great to get involved with it.
Then there are a lot of tutorials in the Internet and something called SlowCheetah to handle this easier.
Best Regards. Guillermo.
If you follow the principle that an application should run "out of the box" when pulled out of version control, .htaccess should be included. Something doesn't feel right about that though, as it doesn't really feel part of the application. I'm conflicted, could someone put my mind at rest?
I typically do keep an application's .htaccess in source control which includes the Apache configuration required for the application to run, that is, rewrite rules which are not specific to the server it is running on, access to environment variables, etc.
Think about it this way - if the .htaccess file contains rewrite rules used by your application, those are effectively functioning as part of the application routing and therefore are part of the application.
If you are packaging an application for others to download and use, you should probably include a skeletal .htaccess file which includes the rules needed to make the application run. If your application is only intended to run on your own server and you keep all its relevant Apache config in .htaccess other than VirtualHost configuration, I would say it does indeed belong in source control.
This is a common problem for us, too, and I know what you mean about 'not feeling right'.
However, for me the issue is not about being feeling that .htaccess is not part of the application, as bits of it clearly are. The issue is more that that the file mixes application-specific code (routing, etc.) with installation-specific stuff (local URL rewrites, authentication/access rules, etc.). Ideally you would version control the application-specific rules but not the installation-specific rules, but of course this is not possible as both need to be in the same file.
I can think of four approaches to managing this. The optimal one will depend on your particular situation (and may vary from project-to-project):
Michael's second suggestion is the best option, if you control the deployments. Namely, keep application-specific code in the .htaccess file, under version control, and any installation-specific code in your main Apache VirtualHost directive. This gives full separation but is not a viable solution if you don't have direct access to the main Apache config or are distributing to third-parties.
Version control the application-specific elements of your .htaccess file, with clear comment markers, e.g. ### FOO APPLICATION SETTINGS - DO NOT CHANGE ### and ### ADD ANY ADDITIONAL LOCAL CONFIG BELOW THIS LINE #### and do not version anything that is installation-specific. This is fine if the rules are simple enough to not really cause conflicts, but is not great if your skeletal file requires users to modify existing lines, as you will likely end up with merge conflicts down the line. It also runs the risk of unwanted edits getting into your repository if deployments are version-controlled (as is probably the case for dev versions, at least) and it runs the risks of local changes being blown away by an upgrade if not (e.g. public zipfile distributions).
What we settled on as a good alternative is to version control a file called .htaccess.sample which can contain both application-specific rules and (where relevant) suggestions for installation-specific rules that users may find useful. This is easy to maintain and deploy whether or not version control is being used, but makes upgrades slightly harder as users will need to hand-merge any changes into their local .htaccess file. In our case, upgrades are always done by developers therefore this is not a big issue, assuming appropriate diff tools are available.
Same as #3, except you also provide a script to automatically apply any modifications. More work to set up, not necessarily more work to maintain, depending how you implement it (e.g. if it just replaces a block of code between some markers) and possibly worthwhile if you are distributing to a wide user base. This is what Wordpress does, for example.
My client insists not to store prone-to-change configuration settings in the Web.Config file for our webservice (WCF). His reasoning is that he will have to deploy the application every time he wants to change this or that setting in the configuration file. He, then, told me to store this configuration information in the database because, he says, that way one can change it whenever one needs without re-deploying the whole application, and because it is a more central place if we ever need to have more than one instance of the service running.
Of course I find this argument and reasoning plainly wrong. However, I would like to provide him with clear evidence in that he his mistaken. Can anyone please point me out a source or two I may site to show him that changes in Web.Config are automatically propagated to the runtime and that he doesn't need to do any kind of re-deployment?
Straight from MSDN on ASP.NET Configuration.
ASP.NET Configuration Overview
ASP.NET detects any changes to the configuration files and then
automatically applies those changes to the affected applications,
restarting the applications in most cases.
See How to: Transform Web.config When Deploying a Web Application Project
when adding a service reference an app.config is generated. What I'd like to know is, do the bindings, endpoints and everything else reflect the service, that I created the reference to? Do they specifically define that services bindings, security type,..etc, or is it simply a generic app.config? There seem to be a lot of settings..
Yes, the amount of stuff the Add Service Reference wizard dumps in your app.config/web.config is staggering - and largely unnecessary (because it basically puts in all the settings, even all of those that are default values).
Yes, the settings include thing like
binding and binding configuration (parameters like timeouts, proxies etc.)
behaviors (client-side)
client endpoint(s)
If you're interested in learning how to manually create those configs to the bare minimum (which is very easy to do, very easy to understand, too!), watch these videos:
DotNet Rocks TV Show #122: Miguel Castro on Extreme WCF
DotNet Rocks TV Show #135: Keith Elder Demystifies WCF
Both show how easy it is to create manual configs and how little you really need to supply! Highly recommended.
The settings do pertain to the service reference you just created. At least sometimes, the app.config is not useful in itself. For instance, if you are consuming services from a web application, the information in app.config needs to be copied to the appropriate section of web.config to be used.
If the service moves to a different location, you can just change the endpoint in the configuration accordingly, and the service should work as before.
I have a Windows application in .Net 2.0 that uses several levels of configuration files. For reasons out of my control, the application consists of a Windows app (.exe) project and several DLLs, each of which has its own app.config file.
I have successfully figured out how to read the config file for each DLL, using (in C#)
ConfigurationManager.OpenMappedExeConfiguration("my DLL's config file path", ConfigurationUserLevel.None);
This works just fine - I can confirm that I get a Configuration object from this method when pointed to the file path name of my DLL's configuration file ("foo.dll.config"). However, when I try to access a custom configuration section, I get an exception saying that the data type for my custom configuration section cannot be found.
What else do I need to do to get the typing information available to my code when loading a configuration file in this manner?
It's unfortunate but true: the way to handle this is to copy the configuration from the .dll.config files into the applications' config file. The only exception has something to do with the Settings system used in Windows Forms. I think that does the OpenMappedConfiguration for you, but I'm not sure.
I've never known why they didn't unify this in .NET 2.0 and solve the problem. Maybe I should ask.
Earlier in the day, I asked a question like this as relates to WCF, in the Oslo Forum on MSDN (http://social.msdn.microsoft.com/Forums/en-US/oslo/thread/c93ee7f3-4f9b-4044-b1f0-43ad72fb508d). As I was searching for a blog post or some other answer (as I said above, "maybe I should ask"), the answer to my Forum post arrived.
Long story short, and somewhat tongue-in-cheek, the answer is: they didn't fix this in .NET 2.0 because they were waiting for Oslo to solve the problem.
Without trying to avoid downvotes by making sense out of that, I'll just mention: Oslo will encourage models of applications and application components to be stored in a central repository. That will include models of per-instance configuration. The theory is that all such data would be stored in a single repository (at least per-system). So, no more question of where the configuration file is located it's all in one place. No more question of finding the assembly containing the configuration section metadata - the metadata is stored in the repository along with the configuration data.
Ask me tomorrow, and I may feel differently, but right now, I may be picking up the Oslo religion...