Let's pretend that we have the following servers [dev, test, production] and that dev and test are very similar in configuration while production is quite different.
If I'm using web.config transforms that means I have to duplicate a lot of settings för Web.dev.config and Web.test.config. It would be very nice if I could use the same transform mechanism for my transforms so that test.config is based on dev.config.
I have thought of two possible approaches, i'm not sure any of them would work:
Try to get MSBuild to first transform dev.config and then run test.config against the result when we are running under test configuration
trying to get the transform mechanism to work for transformations files. I would somehow run test.config against dev.config and create a temporary file which I then use as as a transformation against Web.config.
Does anyone know if something like this is possible? And if so how would one go about to set it up?
The TransformXml is just an MSBUILD task that is invoked post compile. If you extend/mod your build you can have it run the transform task twice, or allow the normal run against your configurations, then provide a second file and use the task to perform that.
If you are familiar with msbuild, this is pretty simple. If not, reply/comment, and I'll try to provide examples later today.
But in the end, yes its possible, as I've had similar need on past projects.
I have even more configurations. And all of them synced with T4. See my answer here.
Although this has been answered I wanted to update it with an answer reflecting changes made in Visual Studio 2012 that make this considerably easier.
As of Visual Studio 2012 it is possible to "chain" build and publish profile transforms.
As such you can have a "Release" build transform that takes care of common configuration such as switching off debugging, switching on custom errors, and any number of "Publish" transforms which are associated with a publish profile, adding instance specific data such as connection strings and appSettings.
In VS 2012 (as well as the publishing updates for VS2010 through the
Azure SDK) now support the concept of publish specific transforms. You
can also now specify the project configuration used for a profile when
publishing on the publish dialog...
In this case I have created a profile named Production and set the
Configuration to Release. When I publish this project the following
transformations will be applied (if the files exist) in this order.
1.web.release.config
2.web.production.config
See Profile specific web.config transforms and transform preview for more information.
Related
My approach here may be wrong, so apologies if so - I'd appreciate any advice on what I did wrong.
I need to run (locally, for debugging), a specific configuration of a project that contains specific web.config transforms.
In my solution, in Configuration Manager I have the following listed:
Debug
Release
ClientFoo (copied from Release)
ClientBar (copied from Release)
I created a new entry, ClientXYZ (copied from Debug), then right-clicked web.config and chose Add Config Transform. I applied the transform rules, and when previewed, the transforms display correctly.
When I select ClientXYZ in the solution config drop down, and start the debugger...
...I see that the web.config used to initiate the application is the Debug one, and not my new ClientXYZ version.
Is it possible to run the project locally with web.config transforms applied, for debugging?
Web config transforms are only applied during publishing or building deployment packages by default (it does, after all, overwrite web.config). There is a way with some adjustments, however, described in this answer: https://stackoverflow.com/a/35561167/1464084
The purpose of using "Debug" and "Release" in Visual Studio are:
Debug constant defined in Debug configuration when you are developing application
Release optimize code enabled in Release configuration when you host that application for client side testing or publishing
Custom (ClientXYZ) constant defined for a developer's own settings (localhost or different IP's) for both Client site hosting and publishing your site
I have a build environment with multiple agents.
I would like to set up an Agent Requirement in my build that detects if certain software is installed. In some cases I can look in the env.Path for a particular string. But some software doesn't modify the Path.
I realize that after I install the software i could edit the BuildAgent.properties file to set a particular property, but I'd like it to be more automatic.
The specific instance is I have a build that uses MSDeploy to deploy websites, but it won't work if MSDeploy isn't installed. How can I specify in my build that I need an Agent that has MSDeploy installed?
You can build a simple agent plugin. Here are a few suggestions:
Extend AgentLifeCycleAdapter and implement agentInitialized method
Implement logic of detection the necessary application (for example based on some file existence) inside agentInitialized method
Use agent.getConfiguration().addConfigurationParameter() to report agent parameter to the server
If your detection logic can be implemented through file detection, you can use FileWatcher to monitor specific files and report parameters based on them even without restart of the agent
To my knowledge Agent Requirements work simply by validating either the existence of, or the value set in an Agent Parameter. As you say, this requires editing the <agent home>/conf/buildAgent.properties configuration file, either manually or in some automated way.
In terms of automation, you could take the approach of authoring a build configuration that acts as an agent bootstrapper; i.e. a build that runs on all agents (scheduled overnight / manually triggered) and maintains build agent parameters in the <agent home>/conf/buildAgent.properties file depending on certain conditions on the agent. Something like (pseudo):
if [ exists /path/to/MSDeploy ] then echo MSDeployExists to buildAgent.properties
This comes with a big disclaimer; I haven't tried this myself, and I believe that the agent will restart automatically based on changes to this file, so there may be issues with editing that file automatically. But it's a potential solution to maintaining your requirements in a centralised manner, and if it works then great. I use a similar approach to bootstrapping custom build scripts out to all agents to augment the already rich feature set in TeamCity.
I agree with the answer from SteveChapman. It is clear that you can test for environment variables (exits, contains, starts with, etc.). TeamCity is aware of versions of .NET installed on the agent (as well as Visual Studio, and VS SDKs). However, I can't find anything that would be equivalent to a "testpath" sort of capability.
The sure way to know is to add an agent parameter via the <agent home>/conf/buildAgent.properties configuration file.
Suppose I have a web.config parameter under <appSettings><add key="myParam" value="myValue"/></appSettings> and I want to modify the value for myParam depending on the publish profile I use, ie DEVELOPMENT.pubxml and TEST.pubxml for a web site deployment.
What is the most straightforward way to accomplish this? How do I specify in the pubxml which keys I want to transform, where they are, etc?
Either a direct answer or a link to a resource that answers this question would be highly appreciated.
You can create Web.config transform files for publish profiles as well as for build configurations. When you publish, either in Visual Studio or from the command line, Visual Studio applies both the appropriate build configuration transform and the publish profile transform. See this tutorial:
http://www.asp.net/web-forms/tutorials/deployment/visual-studio-web-deployment/web-config-transformations
This is one of a series of tutorials. Others in the series run through examples of creating publish profile transforms and examples of doing it from the command line.
The tutorials use a web application project. If by web site deployment you mean you're deploying a web site project, the process is basically the same as long as you have installed the latest VS update (see the first tutorial in the series for links to the VS update).
We essentially have two separate development paths:
Local → Dev → QA → Prod
Local-Release → Dev-Release → QA-Release → Prod
The first path uses our mainline/trunk, the second path is for when we cut a release branch and need to make bug fixes in between releases.
We use config transformations for Dev, QA, Prod, Dev-Release, and QA-Release and this all works great. However, after each time we cut a release branch, we have to manually change the config files for the Local-Release environment (things like changing the connection string from using LocalDB to LocalReleaseDB, etc).
It would be ideal if we could automate this using another transformation file, but we're not publishing anywhere. Is there a trick to get around this? Could we do it at runtime or have a powershell, batch file, or something else run after creating the branch? What do others do to accomplish this?
I believe that SlowCheetah will give you what you need.
Taken from the SlowCheetah website:
This package allows you to automatically transform your app.config (or any file) when you press F5 in Visual Studio. You can have different transformations based on the build configuration. This will enable you to easily have different app settings, connection strings, etc for Debug versus Release. If you want to transform other files you can do that too.
I haven't ever tried this in a TFS build scenario, but as long as SlowCheetah is installed on the build servers, I guess it would work.
I believe I found a viable solution here: http://kfigy.blogspot.com/2010/03/making-visual-studio-2010-webconfig.html
He's using the approach to allow multiple developers to each have their own config settings, but it can also be used to have config settings per branch.
Do I have to manually edit the Azure connection strings myself to switch between production and development, or is there something comparable to the Transformation Visual Studio applies to Web.Config?
To add to what Brent has said. I use a special small configuration-only (Config) project that contains a folder for every deployment type - inside each folder there is a collection of .config and .cscfg files that are tailored toward a specific deployment (a few partial .config files too). During every compile via Pre-Build event step, Visual Studio copies the files from the correct folder into the root folder of that Config project.
This is the command I use in the Pre-Build Event Command Line:
xcopy /Y "$(ProjectDir)$(ConfigurationName)\*.config" "$(ProjectDir)"
xcopy /Y "$(ProjectDir)$(ConfigurationName)\*.cscfg" "$(ProjectDir)"
Every other project in the solution links to the configuration files from the root folder of the Config project.
I also use config transformations as well, for Production vs. Non-production environments. Everything non-Production (local development environment, Azure-QA development environment) has a lot of debug and tracing built in - errors are returned completely to the clients/etc. Production environment has that locked down.
Edit: wrote a blog about this finally: http://www.paraleap.com/blog/post/Managing-environments-in-a-distributed-Azure-or-other-cloud-based-NET-solution.aspx
As Brent pointed out, it is not a good idea to have Staging area to be a full-blown Testing site. It is more geared toward a quick smoke test as well as a great way to deploy a new package into Azure without taking your main site down. (IP swap between Production and Deployment usually does not cause any issues to users)
Hope this helps
First a question, are you referring to configuration settings in the traditional configs? Or in the cloud service config (cscfg)?
If the later, then ATM I'm not aware of any support for configuration transformation. The approach I've seen most folks taking is to maintain number configuration files and use the appropriate file when doing your azure deployment.
This subject also touches on usage of the "Staging" environment. I've seen some folks using it as a parallel testing environment. In practice, its more affective to use it as a staging area to smoke test a new deployment before rolling it into production. If you have a need for a longer term test environment, I've found it better to deploy those services to their own unique namespaces that are then sandboxed away from the production services.
This again touches on ALM best practices for Azure (versioning, deployments, etc..). Something I believe the PNP team is working on and will hopefully have recommendations for soon.
Like knightpfhor said, you can use Visual Studio config transformations if you edit the .ccproj file manually. My answer to a similar question lists the minimum number of steps required to get transformations working.
You can use CloudConfigurationManager in Azure SDK 1.7 http://msdn.microsoft.com/en-us/LIBRARY/microsoft.windowsazure.cloudconfigurationmanager
This starts by looking in the ServiceConfiguration.cscfg e.g. ServiceConfiguration.Cloud.cscfg for config setting. If it isn't there it falls back to web.config and app.config
For example
CloudConfigurationManager.GetSetting("StorageConnectionString")
Will look in the appropriate cscfgfile for StorageConnectionString setting, then it will search the web.config and then app.config.
The simple answer to your question is yes, but you have to mess around with the .ccproj file manually to do it. A full description on how to to do this can be found here