For one client, I have to deliver a build they use in QA and production. The checksum of the build file has to match - it cannot change at all between QA and production. The configuration for each environment is different, so I have a build that contains just the code and then a separate build for each environment that contains just the environment specific config files. The config file builds puts the files in the same location regardless of environment, so the code can always load c:\myapp\myconfig.xml which will contain the settings for that environment. Most articles I read about this (such as Scott Hanselman's) involve different builds for each environment, but this won't work because the checksum values will be different. Should I deploy these config files some other way, or do I have a viable solution? The one problem with my current solution is it requires multiple config files that are nearly identical but not quite. One change therefore has to be added to multiple files, which is something I would like to avoid, but I don't know how to do it except at build time or with an external script that copies the proper file.
Not sure if your setup is more complicated, but we have a similar problem and we added a custom actions class that updates the config files based on the environment (which the user selects during installation), then you add this custom actions project to your setup project. That way you use one setup exe no matter what environment you're installing to.
Let me know if you're interested and I can post some samples or more info on how we accomplished it.
Here are some more details:
Add a new dialog to your Setup project to request the environment from the user (we use a 4 radio button dialog with the 4 environments we have: dev, qa, staging and production)
Configure the values of the 4 radio buttons and the property that this value will be setting i.e. "environment" (to latter be used by the CustomActions class)
Add a dll project to your solution with a single class (CustomActions)
in the CustomAction class, you read the property we configured in step two as:
if(!this.Context.Parameters.ContainsKey("environment"))
{
string error = "'environment' argument is null. Please configure config file manually";
//...handle your error, etc.
return;
}
string env = this.Context.Parameters["environment"];
now your env variable contains the value we assigned to each radio button in step. You then can use a switch statement to decide what environment the user selected. and update your config file appropriately with:
Configuration config = ConfigurationManager.OpenExeConfiguration(this.servicePath);
//for example, to change your connection strings you'd use:
config.ConnectionStrings.ConnectionStrings["oracle"] = "dev conn string here";
Back in your setup project, add the output of the CustomActions project to your CustomActions editor (View menu -> Editor -> Custom Actions)
Finally, configure the CustomActionData property of your setup project to pass the environment and other variables to the CustomAction class (mine looks something like this:
/serviceFolder="[TARGETDIR]\" /serviceExe="blahblah.exe" /serviceName="MyServiceName" /environment="[ENVIRONMENT]"
Hope that makes sense and applies to your solution!
Assuming:
1) XML config files
2) Total number of changes between builds are few (even if copied to many config files)
I would have the installer handle updating the config files at install time
For instance we use WiX v3 for our installer and update several config files with values during install using the XmlFile element
<util:XmlFile Action="setValue" File="[DIRECTORIES.WEBSERVICES]web.config" ElementPath="//configuration/system.web/compilation" Name="debug" Value="false" Permanent="yes" />
Related
I want to configure our pipeline to allow one build to be used for multiple environments without having to create separate builds. According to the docs, it seems like it is possible, as it says:
You can use this technique to create a default package and deploy it to multiple stages.
I named my stage as my environment (preview), and I created a web.config file for that environment (web.preview.config) file. All my environment configuration files in the same path as Web.Config file.
The logs say transformation was complete:
2018-11-17T00:26:52.0383966Z [command]D:\a_tasks\AzureRmWebAppDeployment_497d490f-eea7-4f2b-ab94-48d9c1acdcb1\3.4.13\ctt\ctt.exe s:D:\a_temp\temp_web_package_06958915987488234\Content\D_C\a\1\s\Microsoft.Xbox.Mvp\Microsoft.Xbox.Mvp.Api\obj\Preview\Package\PackageTmp\bin\Web.config t:D:\a_temp\temp_web_package_06958915987488234\Content\D_C\a\1\s\Microsoft.Xbox.Mvp\Microsoft.Xbox.Mvp.Api\obj\Preview\Package\PackageTmp\bin\Web.Release.config d:D:\a_temp\temp_web_package_06958915987488234\Content\D_C\a\1\s\Microsoft.Xbox.Mvp\Microsoft.Xbox.Mvp.Api\obj\Preview\Package\PackageTmp\bin\Web.config pw i
2018-11-17T00:26:52.4335280Z [command]D:\a_tasks\AzureRmWebAppDeployment_497d490f-eea7-4f2b-ab94-48d9c1acdcb1\3.4.13\ctt\ctt.exe s:D:\a_temp\temp_web_package_06958915987488234\Content\D_C\a\1\s\Microsoft.Xbox.Mvp\Microsoft.Xbox.Mvp.Api\obj\Preview\Package\PackageTmp\bin\Web.config t:D:\a_temp\temp_web_package_06958915987488234\Content\D_C\a\1\s\Microsoft.Xbox.Mvp\Microsoft.Xbox.Mvp.Api\obj\Preview\Package\PackageTmp\bin\Web.Preview.config d:D:\a_temp\temp_web_package_06958915987488234\Content\D_C\a\1\s\Microsoft.Xbox.Mvp\Microsoft.Xbox.Mvp.Api\obj\Preview\Package\PackageTmp\bin\Web.config pw i
2018-11-17T00:26:52.5443873Z XML Transformations applied successfully
I can see that it first transformed to release and then it applied preview as the doc says (release then environment). However, although it says XML Transformations applied successfully, when I check the config variables, they are not changed. The only way I could make the transformation work was to define the buildConfiguration variable when I queue a new build, which blocks me from using the same build for different environments.
When I was researching, I found this from this link:
Web.config is transformed during the build process, if you generate the deployment package from "Build" and then deploy it in "Release", then you cannot transform it before deployment.
But the doc said I can use one default package for multiple stages...Does that still mean I have to create separate build for each environment? Is XML transformation not what I should be looking at for the scenario I wanna solve?
Thank you in advance!
++ Edit:
Release Settings:
Release steps (I think? I have a strong feeling that this is what you are looking for...):
1) Make sure you transform works. Test it
here.
2) Ensure in your VS project that you are including the transform file, Web.Preview.config, and copying to output dir.
3) Disable the config transform during the build, you just need to add argument /p:TransformWebConfigEnabled=False in MSBuild Arguments section of your Build task. You also need to add /p:AutoParameterizationWebConfigConnectionStrings=False if you want to update the connection string during the release. This will use the Web.Preview.config to "transform" the web.config.
4) Double check that in your release for the IIS Web App Deploy task under File Transforms & Variable Substitution Options you have XML transformation checked.
None of the answers I found on the internet worked for me on their own for my build and release pipeline. The web.config I got from the release pipeline was always pointing to the non transformed values.
After a few hours pulling my hair I got it to work though.
Some short info about my setup
I want to be able to deploy on all environments with just one build and one release pipeline.
My setup:
One build pipeline that builds all of our standard branches (test,
release, master).
One release pipeline that has different stages
depending on branch that started the release.
Our test stage releases the test branch on our test server.
Stage/Production comes from the same release branch but have their own transform files.
Solution
I followed some of the guide from Microsoft and set up my web.<environment_name>.config to match the release stage names.
I did not need to remove the <Dependent Upon> rows from my .csproj for each transform. Instead all I did was set the property Build Action of each transform to Content as shown by the image bellow.
I then added these commands to the build pipeline's Build Solution -> MSBuild Arguments:
/p:MarkWebConfigAssistFilesAsExclude=false
/p:TransformWebConfigEnabled=false
/p:AutoParameterizationWebConfigConnectionStrings=False
The build now does not try to transform the .config on it's own and also does not exclude the transform files from the artifact, allowing the release pipeline to do the transformation instead. Also, keeping the <Dependent On> for the transform files lets us have a "cleaner" look inside our code editors.
I just got this working so I could have one build with deployment to multiple environments. This is what I did.
In the code, I set each Web.<Environment>.config property to Build Action = "Content". I also set all mine to Copy to Output Directory = "Copy Always". I also unloaded the project and edit the csproj file, then removed the <DependendUpon>Web.config</DependentUpon> lines. This dumps all your web.configs to the root (no file nesting).
In the build, I set pipeline variable BuildConfiguration = "Release". I don't have a Web.Release.config in my project.
In the release, I named the deployment stage after the environment (in my case, Development, Staging, and Production). In all stages, on the Azure deployment task, I checked the XML transform checkbox.
In Azure, I set the ASPNETCORE_ENVIRONMENT to the naming of the staging environment, in my case, Development, Staging, and Production).
I just got this working as well. My issue was actually at the Visual Studio Solution level. I had the MVC project pointed to a different Configuration than the others. So always double check the configs!
I have a windows service written in .net c#. We have three different environments say dev, test and prod. I also have 3 different config files for 3 environments say devAppConfig , TestAppConfig and ProdAppConfig.
Earlier, we used to deploy manual, so we used to replace the config files and deploy the binaries.Now the deployments are to be automated for that we are using Bamboo.
Now my question is how do I dynamically change the AppConfig for different environment deployments.
I have 3 different stages in Bamboo naming DevDeploy , TestDeploy, ProdDeploy. When I run these stages, it has to change the config file and do the deployment, but I'm not sure how.
Can anyone guide me in the right direction for my issue?
I suppose this would work:
Create few configuration files in some directory in the solution in the format Config.ConfigurationName.xml, eg Config.DEV.xml, Config.Test.xml...
Add PreBuild event (by the csproj properties window or manually in the csproj file), for example: <PropertyGroup><PreBuildEvent>xcopy /y (ProjectDir)\Configs\Config.$(Configuration).xml $(ProjectDir)\CONFIG\Config.xml</PreBuildEvent></PropertyGroup>
or in VS rigth click on the project -> Properties:
Add few configurations in VS in Configuration Manager for different configuration eg. DEV, Test.
My project configuration:
Execute in the Bamboo msbuild with arguments: /p:SolutionConfiguration=%CONFIGURATION% where %CONFIGURATION% is a variable in Bamboo saying on which ENV you are deploying, eg DEV, Test etc.
Is there a way to set Project Settings with Build Configuration specific values in VS2013?
I need to set different values for a WebServiceURL setting from one Build Configuration to another (say MSSQL configuration vs Oracle configuration).
I saw both a preprocessor assembly configuration using #if DEBUG and an afterbuild config file overwrite approach, but the former does not allow for custom configuration names or more than 2 configurations while the later involves copying files after build rather than the quick and easy edit in the Project Properties > Settings page.
Is there something similar to Web.config Transformation available to App.config maybe?
Try this plugin, it works for me. And you can transform any xml-file.
https://visualstudiogallery.msdn.microsoft.com/579d3a78-3bdd-497c-bc21-aa6e6abbc859
How to pass a parameter to a TeamCity Test Runner?
I've added a build configuration to my teamcity project which copies out a test project from TFS into a local location on the server then it runs the tests with NUnit and display the results.
The problem is that when the tests run from my local pc, they should be using some configurations, when they run from Dev Automated Build and Test Automated Build, they should be using other configurations and all should be in TFS.
For example, BaseUrl and Connection string configurations...
private static readonly string BaseUrl = ConfigurationManager.AppSettings[AppSettingKey.BaseUrl];
Currently, I've added a web.config file to my project which works fine only locally.
So, how to pass these parameters to a TeamCity Build Configuration which is configured on Dev and Test environemnts?
Even if I create separate web.config files (e.g. dev.web.config and staging.web.config), I need a way to tell the Build Configuration to use which configuration file?
Hope the question is clear.
many thanks.
Enlightened, found a solution (should have thought more before submiting a question here)!
I'd just create separate dev.app.config and staging.app.config files then on the "Version Control Settings" page on teamcity I can define rules such as copy this file somewhere.
So I just Copy the file onto the root app.config; that's it!
Rule:
+: SolutionName\Tests\ConfigFiles\Dev\App.config=>SolutionName\Tests\App.config
Consider using the configuration parameter i.e. Build | Release
Use your debug build locally and release on TeamCity. You can do this with an MSBuild parameter (/p:Configuration=Release)
Then use the solution here (How to select different app.config for several build configurations) to use the correct app.config.
I prefer this solution as it keeps the definitions within the solution / projects rather than within the build.
[I'm adding this just for completeness - I had originally followed this approach but then found the other solution]
Rules in Version Control Settings works only for directories so the better approach is to use Build step - command line
Go to Build Step in Settings section
and Add Build Step with following settings
Command Line
Custom script: copy TeamCity.App.config App.config
Execute: Only if all previous steps were successful
Reorder this step and run it before compilation step
I have a Deployment Project for my VS2008 C# application. When installing a new version of my application I want to make sure that files are updated with the files contained in the installer.
I want my installer to automatically remove any old version of the installed application. To do that I follow this procedure (also described here):
Set RemovePreviousVersions to True
Set DetectNewerInstalledVersion to
True
Increment the Version of the
installer
Choose Yes to change the ProductCode
For the assemblies I make sure the AssemblyVersion is set to a higher version:
[assembly: AssemblyVersion("1.0.*")]
Everything is working as intended except for my configuration files (xml files). Since I cannot find a way to "version" these files I cannot make sure that the files are updated if they have been modified on the target machine.
Is there any way to do this and how?
UPDATE: I have tried the approach/solution/workaround found here
Include the file directly in a
project with the following
properties: "Build Action -> Content
file" and "Copy to Output Directory
-> Copy always"
Then add it to the deployment
project via Project
Output->Database->Content Files
Unfortunately it did not make any difference. The behavior is exactly the same.
Add the following property to the Property table of the MSI:
Property REINSTALLMODE with Value amus
Note: This will cause all the files in the MSI (versioned and nonversioned) to overwrite the files that are on the system.
If you're willing to use Orca (there may be another way to do this method, but it's the only one I know of) you may be able to set up RemoveFile directives.
See here for a typically light-weight MSDN document -- could be a starting point.
http://msdn.microsoft.com/en-us/library/aa371201.aspx
Alternatively you could always create a very simple bootstrapper executable that simply calls "msiexec /i REINSTALLMODE=oums" (or whichever command-line switches are needed). Call it setup.exe if you like...
Better option long-term may be to switch to InstallShield or similar -- VS2010 includes a light version of IS and I believe they're moving away from vdproj projects.
Have you tried the approach/solution/workaround found here?
Include the file directly in a
project with the following
properties: "Build Action -> Content
file" and "Copy to Output Directory
-> Copy always"
Then add it to the deployment
project via Project
Output->Database->Content Files
I may be incorrect here, and therefore I am exposing myself to down votes, but here goes anyway!
I believe it is on purpose that config files do not automatically get overwritten; the principle there being that you would not normally want your application's configuration overwritten when you install the new version of the program... at least not without numerous warnings and/or chances to merge configuration first.
Having your application configuration get overwritten by an updated version of a program could make for a very upset end user (in this case, web site admin).
Further, I know that sometimes, the developer may be the person doing the deployment. In such a case, this behavior might not seem so logical when deploying a single site to a single server; but when roles are split and/or you have multiple servers with different configurations, this can be a life saver.
You need to include the new version of your files in your custom installer and manually install these file during Custom Install routine is called
This must be applied to any file that does not have version that can be tracked by the installer.