72

So, I have VS 2010 installed and am in the process of modifying my MSBuild script for our TeamCity build integration. Everything is working great with one exception.

How can I tell MSBuild that I want to apply the Web.conifg transform files that I've created when I publish the build...

I have the following which produces the compiled web site but, it outputs a Web.config, Web.Debug.config and, Web.Release.config files (All 3) to the compiled output directory. In studio when I perform a publish to file system it will do the transform and only output the Web.config with the appropriate changes...

<Target Name="CompileWeb">
    <MSBuild Projects="myproj.csproj" Properties="Configuration=Release;" />
</Target>

<Target Name="PublishWeb" DependsOnTargets="CompileWeb">
    <MSBuild Projects="myproj.csproj"
    Targets="ResolveReferences;_CopyWebApplication"
    Properties="WebProjectOutputDir=$(OutputFolder)$(WebOutputFolder);
                OutDir=$(TempOutputFolder)$(WebOutputFolder)\;Configuration=Release;" />
</Target>

Any help would be great..!

I know this can be done by other means but I would like to do this using the new VS 2010 way if possible

abatishchev
  • 98,240
  • 88
  • 296
  • 433
xspydr
  • 3,030
  • 3
  • 31
  • 49
  • This is an excellent writeup about custom transformations: http://www.diaryofaninja.com/blog/2011/09/14/using-custom-webconfig-transformations-in-msbuild We needed to customize web deployments a bit more than normal due to tons of classic ASP and other nastiness we had to accommodate for. This article saved hours of digging through the MS targets. – kenchilada Aug 14 '12 at 20:06

6 Answers6

63

I was looking for similar information and didn't quite find it, so I did some digging around in the .targets files that come with Visual Studio 2010 and MSBuild 4.0. I figured that was the best place to look for the MSBuild task that would perform the transformation.

As far as I have been able to tell, the following MSBuild task is used:

<Project ToolsVersion="4.0"
         DefaultTargets="Deploy"
         xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

    <UsingTask TaskName="TransformXml"
               AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll"/>

    <PropertyGroup>
        <ProjectPath>C:\Path to Project\Here</ProjectPath>
        <DeployPath>C:\Path to Deploy\There</DeployPath>
        <TransformInputFile>$(ProjectPath)\Web.config</TransformInputFile>
        <TransformFile>$(ProjectPath)\Web.$(Configuration).config</TransformFile>
        <TransformOutputFile>$(DeployPath)\Web.config</TransformOutputFile>
        <StackTraceEnabled>False</StackTraceEnabled>
    </PropertyGroup>


    <Target Name="Transform">
        <TransformXml Source="$(TransformInputFile)"
                      Transform="$(TransformFile)"
                      Destination="$(TransformOutputFile)"
                      Condition="some condition here"
                      StackTrace="$(StackTraceEnabled)" />
    </Target>
</Project>

I have tested the above and can confirm that it works. You might need to tweak the structure a bit to fit with your build script better.

Umar Farooq Khawaja
  • 3,925
  • 1
  • 31
  • 52
  • 4
    this is very similar to the solution I ended up with. The only caveat is that the TransformXml action currently has a bug where it doesn't close the source file and therefore you cannot get rid of the source file. Just something to consider; in my case after I did the transform I wanted to remove both the Debug.config and Release.config files from the deployment directory. To get around this until MS fixes the issue. You can simply copy the source and transform file to a temp directory and then copy the newly transformed file back then you should be able to delete/remove the files... – xspydr Jun 04 '10 at 12:18
  • 1
    Yeah, I hit that bug as well when I was trying it out. That is why I had to use $(ProjectPath) and $(DeployPath). Actually, I would suggest using an intermediate location to collect all the build artifacts (which would include the Web.config file) and then deploying to the various web servers from that location containing all of the artifacts. This would save from transforming the Web.config multiple times, assuming all web servers will take the exact same Web.config file. – Umar Farooq Khawaja Jun 07 '10 at 11:06
  • 2
    +1 for solving my issue from http://stackoverflow.com/questions/2992778/asp-net-web-config-transformation-wont-work-in-installer – Ryan M Aug 09 '10 at 22:17
  • Works perfectly for me, great find! The full path of the referenced assembly is here (on x64) "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.Dll". – stephen Apr 19 '11 at 11:34
  • 1
    The bug @Jason is talking about is now resolved, I am using v12.0 for msbuild.exe and it works like a charm – Sarvesh Jul 24 '15 at 11:18
14

You should be able to accomplish this by using the Package target and specifying the temp directory.

msbuild solution.sln /p:Configuration=Release;DeployOnBuild=true;DeployTarget=Package;_PackageTempDir=..\publish

http://pattersonc.com/blog/index.php/2010/07/15/visual-studio-2010-publish-command-from-msbuild-command-line/

pattersonc
  • 1,282
  • 11
  • 13
  • 1
    Only problem is that this approach won't apply the config transforms to the connection strings. – Troy Hunt May 12 '11 at 00:37
  • All web.config transforms should work using this method. Why would connection string specifically not work? – pattersonc May 12 '11 at 13:37
  • 3
    Because connection strings are handled differently and you'll see a replaceable token instead: http://troy.hn/gYb7M5 That is unless you override : http://troy.hn/mk8iJL – Troy Hunt May 12 '11 at 23:49
  • Ugh this puts it in some very random directory many levels deep underneath my bin folder – jjxtra Jan 23 '12 at 21:38
  • 2
    Like Troy suggests above, I simply added /p:AutoParameterizationWebConfigConnectionStrings=False to my msbuild command and the package now contains the final web.config transforms. – Ben Cull Jun 03 '12 at 22:13
8

Alternatively, you try using the XDT Transformation Tool:

https://github.com/greenfinch/ctt

I'm using this instead of messing with obscure msbuild targets. Works with app.config not just web.config.

mybrave
  • 1,662
  • 3
  • 20
  • 37
Brian Chavez
  • 8,048
  • 5
  • 54
  • 47
5

It worked for me with the following change

<MSBuild Projects="$(ProjectFile)"
         Targets="ResolveReferences;_WPPCopyWebApplication"
     Properties="WebProjectOutputDir=TempOutputFolder;OutDir=$(WebProjectOutputDir);Configuration=$(Configuration);" />

From Microsoft.WebApplication.targets file under MsBuild folder

_CopyWebApplication

This target will copy the build outputs along with the 
content files into a _PublishedWebsites folder.

This Task is only necessary when $(OutDir) has been redirected
to a folder other than ~\bin such as is the case with Team Build.

The original _CopyWebApplication is now a Legacy, you can still use it by 
 setting $(UseWPP_CopyWebApplication) to true.
By default, it now change to use _WPPCopyWebApplication target in
 Microsoft.Web.Publish.targets.   
It allow to leverage the web.config trsnaformation.
Syam
  • 1,629
  • 1
  • 20
  • 32
  • I'm using nant, and the TransformWebConfig target would not work right for me until I also added the target _WPPCopyWebApplication. This fixed my problem. – SouthShoreAK May 22 '14 at 16:09
0

I'm no expert with MSBuild, but I was able to use the information from this link to accomplish the same task:

http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx

There is a section related to MSBuild near the bottom of the article. Hope this helps.

Jonathan S.
  • 5,837
  • 8
  • 44
  • 63
0

Another answer to this topic after I've been searching for days before I tackled this issue:

Your publish profile and configuration names should match.

In my case mine didn't. Manually publishing through the publishing profile gave me the result I wanted, because my configuration was set in the publish profile. MSBuild however tries to be intelligent and magically connects the publish profile and configuration based on name. (Adding the /p:Configuration in the command resulted in other strange errors about the outputpath of a referenced project).

Just to be exactly clear in what I mean:

MSBuild statement from command line

msbuild myproject.csproj -t:Clean -t:Rebuild /p:DeployOnBuild=true /p:PublishProfile="Development"

WORKS

  • Publish Profile name: Development
  • Solution Configuration name: Development

DOES NOT WORK

  • Publish Profile name: Development
  • Solution Configuration name: Dev

Hope this helps!

Hutjepower
  • 1,241
  • 12
  • 17