I've been searching for a long while trying to get this issue solved but so far I've not figured it out. Like David from asp.net config transforms - don't apply for normal builds, only publish, I would like to run a build locally and easily change the database and APIs it connects to with a toggle.
The Solution Configurations with Transforms seems like the best solution but the transforms only get applied when publishing and I can't figure out how to make them apply when doing a local run of the app in IIS Express. I installed SlowCheetah I assumed it'd fix that issue since it does the transforms at compile time but they're still not applied when doing a local build in Visual Studio.
I've also tried using the ConfigurationManager extensions and while they do work for local changes, they're not dynamic. So I can't have a different config based upon the selected Solution Configuration, or a flag in a config file saying "Prod", "Staging", or "DEV".
So how do I make this happen? I'm looking for the following "features":
No secrets checked in to the code repository
Config changes happen even when running the application locally WITHOUT publishing
Being able to debug is important as well.
Changing between local, Dev, Staging, and Prod databases/apis is easy. Best would be the Solution Configuration selection but a single line in a config file specifying the environment and then the system knowing which configs to use from that would be OK as well.
Related
I am trying to improve the development and deployment experience in our company by trying to limit the overhead in using multiple environments. We currently have 3 environments: Debug, Test, Release. This means I have multiple configuration files: web.Debug.config, web.Test.config, web.Release.config.
We are using NuGet packages to deploy the internally developed libraries. The library itself is responsible for the configuration values it uses. This is easily done with NuGet transformation files. Thus, when adding a package to a project, the correct environment transformation file is applied to the correct .config file. Using SlowCheetah and some manual modifications to the csproj file, this works quite well. When switching the build configuration during development, the correct .config file is used; when creating a deployment package it also uses the correct .config file.
The problem arises when I want to use a parameters.xml file to allow the release manager to change the configuration values when deploying. (How to: Use Web Deploy Parameters in a Web Deployment Package) He sometimes wants to set up a separate environment to do be able to test certain things, whilst not disturbing the existing test environment.
In theory, the use of a parameters file is the perfect solution. In reality it seems the parameters file is not capable of using the configuration values from the corresponding configuration file when no values are passed. This means that, when we provide a parameters file, we must define the actual default values for each possible replacement value. And of course, this complicates things as their is only one parameters file for all configurations. Always specifying every configuration value when deploying is also not preferred, because this means that, when a configuration value changes, we must change it in two places: the NuGet package and the deployment script which deploys to the default environments.
What would be the easiest way to solve our problem? How can we tell the web deploy wizard to use the default values from the .config file generated when creating the deployment package if no value is filled in?
I have been struggling with this issue as well, The best solution I can come up with is to add parameters via the .pubxml files for each deployment, this means a duplication of efforts unfortunately(Surely someone has a better approach?)
I'm maintaining a webforms application for several different clients in Visual Studio 2008. Each client has their own separate web.config file. We are using config transformation when deploying which works great.
There are many developers currently working on this project, and while developing each developer needs to have the configuration values for a specific client. Right now, what we are doing is that each one of us, has their own version of web.config locally, and we just try to be careful not to check in the web.config file.
This approach of course has several drawbacks. We need to do this manually, which is annoying, we need to be really careful not to check in the config files since it could cause trouble for the rest of the developers, it's cumbersome to add a new value to the config, etc.
I'd like to transform the config files when building from visual studio, so we can chose which file to take the configuration values from, without having to manually edit web.config.
I've been looking in the web for a while, but the best thing i found so far is this:
http://www.codeproject.com/Articles/399002/Project-Build-Web-config-transformation
Which is not working for me, it gives me a build error saying it can't copy Web.config_output because the file is missing.
By default tools like SlowCheetah and other config transform technologies use the $(Configuration) to figure out the name of the transformation to apply. You could take the slowcheetah.targets file and edit it to take $(username) which will pick up the standard windows logged on user name if you're building inside visual studio. You could use a condition to apply the change specifically when '$(BuildingInsideVisualStudio)'='true'.
This will require you to do some work with MsBuild target files, but the end result would be that your developers can check in a web.jesse.houwing.config (in my case) and that of that file is there, their transformation will be applied instead of the standard release or debug transformation.
As for a good starting point, look at SlowCheetah.
I'm sure this question has come up before, but I can't seem to find an elegant solution.
I have a web application project with multiple configurations based on deployment environment (Test, QA, Production) along with web.config transforms for each environment. We are using a web deployment package to automatically create the .zip of the app which can be deployed via MSDeploy. It's easy enough to call the package target multiple times, each with a different configuration:
msbuild MyProject.csproj /t:Package /p:Configuration=QA
msbuild MyProject.csproj /t:Package /p:Configuration=Test
But this triggers a complete rebuild of the web project each time before packaging. I want to build once, then apply the web.config transforms, and create separate packages for each environment. Is there an easy way to accomplish this without forcing a complete rebuild for each environment?
Dupe of Build once and deploy to multiple environments with msdeploy & Visual Studio 2012
I've also been wanting a solution to this, but apparently there isn't any real COMPLETE MS solution that I know of. Visual Studio provides the following (as noted here):
Web.Config transformation
Parameterization
Vishal Joshi concluded with the following:
If you can know your environment settings during build time use
Web.Config transformation.
If you would want to create deployment package only once and then
enter the settings during install time then use Parameters.xml
What I would like to see, though, is have the best of both worlds. I want to "package" up a target having ALL the configuration transformations embedded. Therefore, when the IT guy runs the WebDeploy cmd file (that gets generated when you "package"), they can provide a switch of which environment configuration they want (i.e. Dev, Test, Stage, Prod, Release, etc). I don't believe there is a solution from MS out there that does that. :(
I would like to issue one command to build both a grails and a flex project (the Flex project can be built with Ant). I have a file, WEB-INF/flex/services-config.xml which needs to be different for the PROD war build and the DEV environment.
I'm thinking of having two files: services-config-PROD.xml and services-config-DEV.xml and then copying the relevant one to services-config.xml whenever a build happens.
So in dev I run 'grails run-app' and it copies the file and runs the app; and for prod I run 'grails war' (or some other command) and it copies the file, creates a war, and also calls the Flex project to build via its Ant build file.
What would be the best way to acheive this, or at least any part of what I'm asking?
Seems overly complicated. Why do you need the services-config? Personally, I never use it, I use code to create my services which can be done dynamically if needed. If you want one for prod or dev, you can all do it within code.
I would imagine that prod and dev is just 2 different server urls? I normally let html pass those urls using FlashVars. That way, both servers can point to exactly the same swf (or different swf versions), but just change that one FlashVar to make the application point at a different location.
I am working with couple of friends on an ASP.NET MVC website. The project is maintained in SVN and I have CC.Net set up to checkout latest version and do automated build and deploy to a pre-production server. The default build configuration is set to Debug, but the automated build is set to build Retail. Everything works just fine, except for the <compilation debug=""> in web.config which currently is set always to true. I'd like to be able to specify true or false for <compilation debug=""> based on the build flavor.
I've thought about two separate solutions to this problem.
I could have a pre/post-build step that modifies the value. However, the web.config file is under source control, so modifying it in the automated build will leave it checked out on the build machine. I could also have additional step that would revert it as well.
I could also instead of having web.config under source control, have a web.config.base file that is used as a source during the build to generate the web.config file. The problem with this approach is that most of the tools modify web.config directly and we have to manually merge such changes back in the base file. And since there's no indication when any tool changed web.config, we have to look for changes at any checkin. Not only this becomes a tedious manual step, but it's also error prone.
Both of these approaches would work, but have some shortcomings. I was hoping there's a more elegant way of doing this. Thus the question - how do you guys deal with modifying web.config that is under source control during the CI builds?
You can take a look at the Web Deployment Projects VS add-in. Scott Guthrie does a great job explaining it in this post.
Why not modify web.config as part of a build-step using a command line utility that can edit XML?
e.g. Obtain a command line utility that works like:
xml_mod.exe web.config [xpath-of-value-to-change] [new-value]
Then have different value per debug/release(retail)..
Why don't you just make the web.config read/write without checking it out from source control, make your changes you need during the build process and then discard them?
AFAIK SVN has the files read/write anyway.
we have a
web.config for development
web.config.cert which is deployed by hudson to our cert environment
web.config.prod which is used for production
This allows us to put comments in there and values in there specific to the environments when that would normally have to go in some documentation somewhere, and it would surely be ignored.
Like I said, we have Hudson deploy to our cert environment on each build, so it just copies the directory over, deletes the web.config and renames web.config.cert to web.config
You may want to check out Hudson, I dont think I've ever heard of anyone choosing CC.net over Hudson if they had the ability to choose :)