I created a transformation file "Web.Release.config" with a specific configuration (appsetings,connectionstring, bindings). In the same project, I created the parameters.xml file as well, and added a couple of parameters of my configuration (app setings, bindings).
After this I built the deployment package "mypackage.zip."
I went and modified the setparameters.xml file with the intention of deploying mypackage.zip using a different configuration to the one specified in the transformation file "Web.Release.config". But when I deployed the package, msdeploy ignores the parameterization, even though I specify to use the setparameter.xml during deployment.
are transformation files and parameterization mutually exclusive?
I am not sure if I fully understand your question, but here is a shot.
In Visual Studio 2010 Web.config transformations are executed based on the build configuration that is being used to publish/package. So in your example you stated that you created a config transform, Web.Release.config, and then you said "...with the intention of deploying mypackage.zip using a different configuration...". If you want to deploy a different configuration (i.e. not Release) then your config transformation will not kick in. You will need to create another web.config transformation which has similar content (or the same) as web.release.config.
Can you let me know if that helps, if not can you provide more details?
Related
I'm using Octopus as part of our deployment for a .NET Core 3.1 Web API project.
log4net.config exists in .\Utility\Logs.
I'm trying to follow the pattern here:
https://help.octopus.com/t/transformation-best-practice-log4net-config-or-any-non-web-app-config/9906/4
As I understand it, this consists of three parts:
Create Log4Net.DeploymentTransform.config, with the variables in #{name} format - this has been done.
Turn on the "Substitute variables in files" feature, and point at the Log4Net.DeploymentTransform.config transformation file (variable replacement happens before transformation). That would result in the #{LogFileLocation} variable being replaced with whatever value was set for your LogFileLocation variable in the current scope.
This is done and is working.when my app is deployed, Log4Net.DeploymentTransform.config is there as well and the variable has been successfully set in it.
You'd also turn on the configuration transforms feature, and fill out the additional transforms section in the configuration transforms feature to identify your transform file (e.g. Log4Net.DeploymentTransform.config => log4net.config).
This is not working, the content of Log4Net.DeploymentTransform.config is not being copied on top of log4net.config, though they are in the same folder upon deployment.
Here is what I did in our "deploy step"
Which sure looks like what the article is saying to do.
What else should I check? Any idea why step 3 isn't occurring?
Your syntax looks correct for the files - have you checked to ensure that you have the xdt attributes set?
In the example forum post you shared, the log4net and appender elements are tagged with xmlns:xdt, xdt:Transform and xdt:Match attributes that help the XDT layer determine how to transform the files.
A quick example - I created a Log4NetConfigTest package with two files -
Utility/Logs/log4net.config
Utility/Logs/log4net.trasnform.config
I used the same sample code from the forum post as well.
Here's the set up for my package deployment configurations:
With that set up (and my LogFileLocation project variable set), I was able to see the following in my task log for the deployment:
Deploying package: C:\Octopus\Files\Log4NetConfigTest#S1.0.0#20004C95A0E0094490814B5A365DDAD2.zip
Transforming 'C:\Octopus\Applications\Development\Log4NetConfigTest\1.0.0_1\Utility\Logs\log4net.config' using 'C:\Octopus\Applications\Development\Log4NetConfigTest\1.0.0_1\Utility\Logs\log4net.transform.config'.
No matching appSetting, applicationSetting, nor connectionString names were found in: C:\Octopus\Applications\Development\Log4NetConfigTest\1.0.0_1\Utility\Logs\log4net.config
The task log confirmed that Octopus did apply the transformations, and once deployed, I confirmed that my new test log location was present and correct in both the base configuration and the transformation file.
The question is a follow up to this one: Generate Web.Debug config which could be debugged](Generate Web.Debug.config which could be debugged)
I have defined a transformation for web.debug.config. During compilation I see the following:
Transformed Web.config using C:\data\Main\WebRole\Web.Debug.config into
C:\data\Main\obj\obj\x64\Debug\WebRole.csproj\TransformWebConfig\ [...]
transformed\Web.config.
Checked Web.config in the specified location - it is correct (transformation succeeded)
But when I start the service in the azure emulator I get an alert that
Why does it happen? Looks that incorrect web.config is taken. Where should I specify the location of correct (transformed) file?
The key thing to realise with web.config Transforms (and is mentioned in the answer to your linked question) is that they are only part of the story.
When you build your sources, the transformed web.config file is built into the /obj/ folder, ready for deployment.
It is only the act of deploying your solution somewhere that puts the transformed config file into use - as noted in the docs:
When you deploy the Web application by using the selected build configuration and by using either a deployment package or one-click publish, the Web.config file is transformed according to your specifications.
How are you running the application after you build it? You need to publish or deploy it using one of the built in mechanisms that support web transforms to see those changes on your site.
If you are running the emulator against the original source files, they won't see the transformed web.config file - which is why typically the debug build doesn't have any transforms and you then turn off debugging with your Release build which is then deployed to production.
As you're trying to test this in the emulator you should be able to do the following:
In the Solution Explorer, ensure you've selected a file within the project that runs in the emulator.
From the Build menu, select "Publish [Project Name".
In the Publish Wizard, create a new "Profile" using the "Custom" publish target.
In the "Connection" pane select "File System" as the publish method, and give it a suitable target location.
In the "Settings" pane choose the appropriate configuration (in your case probably "Debug"), and set any other options that you'd like.
Then press "Publish", and the project should be built, and then deployed to the new file location.
You should then be able to start the emulator from this newly published location, which will be using your transformed web.config.
I have found this solution and it works perfectly
https://translate.google.co.il/translate?hl=en&sl=de&tl=en&u=http%3A%2F%2Fwww.sascha-dittmann.de%2Fpost%2FWebConfig-Transformation-im-Windows-Azure-Compute-Emulator.aspx&anno=2
I'm struggling to get web.config transformations working with automated builds.
We have a reasonably large solution, containing one ASP.NET web application and eight class libraries. We have three developers working on the project and, up to now, each has "published" the solution to a local folder then used file copy to deploy to a test server. I'm trying to put an automated build/deploy solution in place using TFS 2010.
I created a build definition and added a call to msdeploy.exe in the build process template, to get the application deployed to the test server. So far, so good!
I then tried to implement web.config transforms and I just can't get them to work. If I build and publish locally on my PC, the "publish" folder has the correct, transformed web.config file.
Using team build, the transformation just does not happen, and I just have the base web.config file.
I tried adding a post-build step in the web application's project file, as others have suggested, similar to:
<target name="AfterBuild">
<TransformXml Source="Web.generic.config"
Transform="$(ProjectConfigTransformFileName)"
Destination="Web.Config" />
</target>
but this fails beacuse the source web.config file has an "applicationSettings" section. I get the error
Could not find schema information for the element 'applicationSettings'.
I've seen suggstions around adding arguments to the MSBuild task in the build definition like
/t:TransformWebConfig /p:Configuration=Debug
But this falls over when the class library projects are built, presumably because they don't have a web.config file.
Any ideas? Like others, I thought this would "just work", but apparently not. This is the last part I need to get working and it's driving me mad. I'm not an msbuild expert, so plain and simple please!
Thanks in advance.
Doug
I just went through this. Our build was a bit more complicated in that we have 8 class libraries and 9 web applications in one solution. But the flow is the same.
First off get rid of your after build target. You won't need that.
You need to use the MSDeployPublish service. This will require that it be installed and configured properly on the destination server. Check the following links for info on this part:
Note that the server in question MUST be configured properly with the correct user rights. The following sites helped me get that properly set up.
http://william.jerla.me/post/2010/03/20/Configuring-MSDeploy-in-IIS-7.aspx
http://vishaljoshi.blogspot.com/2010/11/team-build-web-deployment-web-deploy-vs.html
How can I get TFS2010 to run MSDEPLOY for me through MSBUILD?
The next part requires that your build definition have the correct MSBuild parameters set up to do the publish. Those parameters are entered in the Process > 3.Advanced > MS Build Arguments line of the build definition. Here's a hint:
(don't change the following for any reason)
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:CreatePackageOnPublish=False
/p:MSDeployPublishMethod=WMSVC
/p:SkipExtraFilesOnServer=True
/p:AllowUntrustedCertificate=True
(These control where it's going)
/p:MSDeployServiceUrl="https://testserver.domain:8172/msdeploy.axd"
/p:UserName=testserver\buildaccount
/p:Password=buildacctpassword
/p:DeployIisAppPath="MyApp - TESTING"
Obviously the user will have to be configured in IIS on the target server to be allowed access to that axd (see previous links). And the IisAppPath is the name of the website on the target server.
You won't have to do anything special for the config transformations as the build itself will take care of that for you. Just have the correct setting in the line at Process > 1. Required > Items to Build > Configurations To Build.
Instead of trying to do the deploy by adding tasks myself into the build process template, I followed advice in Vishal Joshi's blog post here.
Now the entire project is built and deployed and the web.config transformations work also. Brilliant!
I now have another problem to solve! The web application references web services and the build process results in an XmlSerializers dll. However, although this is built OK, it does not get deployed to the web host. I think this needs a new post!
Doug
I’m a fan of the new VS 2010 Web.config transformations. I use this feature for deployment purposes and wondered if it is possible to use them for debugging too.
I think of using them in the IDE: I want to create different built configuration (with linked transformation configurations); choose one of them; start the web site in the IDE and debug the different configurations this way.
Update
Thanks to a 3rd party plugin, SlowCheetah, this is now possible. Scot Hanselman has a blog post about it.
Original response:
Unfortunately, the web.config transformations appear to effect only publishing sites and building deployment packages.
In our scenario we have two development groups, one with access to multiple environments (in-house) and the other with access to a single environment (offshore). We have periods where the in-house group needs to debug directly against QA, while offshore remains locked-out (so their web.config's must point to the dev environment).
We were hoping to have 1x build-configuration per-environment, and be able to choose the build-configuration which matched the environment to debug against--which, as I understand it is your question.
In case anyone is curious why they haven't built this feature, from:
http://forums.asp.net/p/1532038/3711423.aspx
"When the web app gets run, the web.config under project root folder will be picked up by asp.net and I know unfortunately it is under source control . I certainly understand the cleanness coming with letting runtime use a transformed web.config from a temp folder; however, asp.net runtime doesn't know anything about vs projec structure and it is totaly based on directory structure. Using alternate path might also break as a web.config under a subfolder expect to inherit settings from the upper level of directory."
I found an alternative solution that does not involve any third party tool: http://ledtalks.blogspot.in/2011/09/webconfig-transformations-when.html. I only tried this for the web.config file
I am using the built in test framework in VS2008 and I would like be able to write a test that makes sure all the expected web.config settings have been defined so that if by accident one is removed or changed my suite of tests will detect it and not have to be tested in a runtime scenario. How would I set this up?
I do not want to setup a mockup of my web.config since I don't want to maintain two versions and this would make my test invalid anyways since I am really trying to capture the fact that the project's web.config is correct.
Any suggestions, alternatives, hints?
Solution: I ended up using the copy in the pre-build that was suggested with one change. On copy I rename the web.config to app.config so that the test project would automatically pick it up.
I tried to split out the config files as suggested as well but the problem I ran into was when the test project ran, it actually didn't run out of the bin directory (which setting the config files to 'Content' type would copy to) but instead to a results directory that has been pre defined. I could not figure out how to make it copy thos extra files to this results directory so the config files could never be found.
I'am using the pre-build event to copy working web.config to your test project directory.
Set the command line of the pre-build event of test project to string like this:
copy $(SolutionDir)\YourWebAppDir\web.config $(ProjectDir) /y
After that your tests will always run with actual web.config version.
Comment to pcampbell's answer:
I think if you use the configSource attribute you can just set it to the same path in web.config of your web app and app.config of test project and that makes not necessary to use build events.
sorry, I can't leave comments yet.
To expand on bniwredyc's answer, perhaps consider:
refactoring your web.config to reference a new config file like appSettings.config or similar.
modify your project's web.config to:
<appSettings configSource="appSettings.config" />
modify your Unit Test project's app.config to use this file as well.
modify your post or pre-build events to copy just this file.
this also helps ease of deployment in Test/Staging/Prod
Ultimately, the web.config is an XML file. You could generate a schema to validate the sections required are present and that required values have been populated. Obviously, you couldn't contextually validate any sort of business logic that the configuration might contain, but you could use a combination of an XSD validation plus a lightweight class that is used to parse conditions within the file.
Used in conjunction with a copy pre-build event you actually create a very nice test harness for your production quality configurations.