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.
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
I have a WCF service which references a 3rd party DLL. That DLL looks for a settings file in the same directory as the DLL. However, WCF by default sets the current directory to "Inetpub" so of course the setting file can't be found.
I tried to set WCF to "Aspnet compatibility mode" but that didn't seem to work.
Any help is much appreciated!
Can you pass in the location of the settings files to the DLL? That's when the Aspnet compatibility mode comes to use, see this answer.
But this might be what you're looking for.
Maybe you can try to access it from System.AppDomain.CurrentDomain.BaseDirectory.
I am currently working on Axis2 deployed on Resin 3.1.3. However, I got the below error during deployment:
org.apache.axis2.deployment.DeploymentException: The "Dispatch" phase is not found on the global "InFlow" phase of the axis2.xml file. Make sure the phase is within the axis2.xml file.
Any idea how to resolve this? Thanks in advance for your valuable help.
-Angel
Have a look at this page, underneath the "Phase Order" heading. That should let you know how you need to define the Dispatch phase in your axis2.xml.
It's also possible that the axis2.xml file can't be found or is missing. You haven't provided many details so it's hard to be more specific than that.
Edit:
Remember that Axis2 is a standalone web application that is deployed into a servlet container.
You indicated in your comments that you modified your web application's web.xml. You should not need to do that to get Axis2 to work properly, so you can remove those mappings and redeploy your applications.
Try this guide. Make sure that you can see the "Axis2 Happiness" page described in step 6.
Once you have that working, you can go back to your other web applications and start modifying them to call your web services.
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.