I have a test and production web server. My project has a piece of code that I would like in place on the test server, but not in place on the production server.
#if (DEBUG) doesn't work, because I prefer both to be published in RELEASE mode.
Is there any way to set up a preprocessor directive based on which web Publish profile is being used?
The easiest way to accomplish this is to create separate build configurations for each of the environments you need to publish to. You can clone your new build configurations from Release. Then, in the project settings, enter the name of your build configuration in the Conditional compilation symbols box.
So, for example, we have a Stage build configuration which is identical to Release except it defines the STAGE compiler constant. Then, in the code, you can use #if (STAGE) checks.
If you are like me wondering where MS moved everything, on VS2022, here it is:
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'm aware you can include directives to compile and run different code based on whether you're in debug or release mode. Can you do the same sort of thing when you build the project for distribution?
I ask because I've just submitted and had approved an app update which points to a web service on our test server rather than live!
Yes, you sure can.
In MonoDevelop under Project Options->Compiler->Define Symbols, choose the appropriate build configuration (AppStore), and you can make a new variable such as PRODUCTION.
You can then use:
#if PRODUCTION
#endif
Throughout your code.
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 am attempting to make it so that we can have our application to behave differently based on the presence of a preprocessor directive. I've read that you can create build configurations to define different preprocessor directives based on which build you do. Well, I am not seeing anything in Visual Studio to do this.. I know how to do it from the command line, but not how to do it within the automated environment of VS 2008.
Can someone tell me how to create a new build configuration which has preprocessor directives set in it?
Also, not sure if it has anything to do with it, but our project is an ASP.Net website
I do not even see a way to control the
DEBUG symbol, and it is an ASP.Net
website
Ok, there's the problem. The ASP.net web site option gives you a lot less control over builds, etc as it doesn't even use a project file.
If it is at all feasible for you to switch, switch over to an ASP.net web application. A web app will behave much more like a typical C# project (you have a project file, and the contents of the csproj file control what is in the app instead of just the directory structure, etc.
After you have converted, you should see the options that you are expecting.
Here's a link with directions for converting: How To Convert ASP.NET Website to ASP.NET Web Application
If you right-click the project and select "Properties", then select the Build tab, you can enter custom compilation symbols in "Conditional compilation symbols".
For example, if your code looks like this:
#if DEBUG
// do something
#else
// do something else
#end
You can set "DEBUG" as a Conditional compilation symbol.
You can set different values for different build configurations, by changing the "Configuration" drop-down.
In VS2008 (and earlier if I'm not mistaking) I have dropdown that lets me choose between Debug and Release mode. All well.
When I switch VS to Release, the debug attribute in my web.config files isn't set to false at all though.
Is this the way it is supposed to be? I am bound to forget to set it to the correct value on deploying.. What measures should I take to make sure this is working like it should?
This is one solution to this problem:
http://blog.aggregatedintelligence.com/2009/04/aspnet-never-again-fear-publishing-your.html
Well your web.config would probably be different for debug and release (connection string, passwords, etc...) but if it's not, look at a postbuild event which would copy over a different file.
Also check this blog post from Scott Guthrie.
Changing release mode will not change web.config, however when you build your web app, it will build the dll for only C# files in release mode where else your web.config's debug on/off is used by IIS to build debug/release version of ASPX markup files.
The build flavour just affects how the code is compiled, it does not affect your configuration files. So yes, to answer your question, this is how it is supposd to be.
The element is a good solution if you have access to the machine.config of your server, which hosts only production applications.
I usually modify the web.config file when generating the deployed files as part of the automated build process. For example web deployment projects can perform web.config section replacement. There are a number of reasons I don't like web deployment projects and I tend to do it with a simple VBS file that modifies the file using MSXML.
The answer you selected from Bobby is not correct. Visual Studio builds the files for you in release while you are in VStudio.
IIS compiles the code at startup with that setting when you deploy. Not the bin directory, but the App_Code and the code behind files.
You should precompile your app before deployment which will compile your code behinds and App_Code dir into dlls in the bin directory.
The deployment tools automatically switch that setting if you set the deployment tool to Release
I use web deployment projects. http://weblogs.asp.net/scottgu/archive/2008/01/28/vs-2008-web-deployment-project-support-released.aspx