Question

I'm pulling my hair out over this MSBuild issue.

We're using TeamCity to build a solution with two MVC websites in it. As part of the build we're deploying to a folder on the build server. IIS points to this folder to give us an integration build visible to management.

Here's the code from the MSBuild file that uses MSDeploy to publish a package - but not as a zip file.

<Target Name="Deploy">
  <MSBuild 
    Projects="$(SolutionFile)"
    Properties="Platform=$(Platform);Configuration=$(Configuration);
    DeployOnBuild=true;
    DeployTarget=Package;
    PackageLocation=$(PackageLocation);
    PackageAsSingleFile=False;
    AutoParameterizationWebConfigConnectionStrings=False" />
</Target>

The problem here is that we get an incredibly deep folder structure. Here's an example...

C:\DEPLOY\Archive\Content\C_C\Users\Edmond\Documents\Visual Studio 2008\CreatioGreen\Creatio\Code\core\trunk\Website\Website\obj\Release\Package\PackageTmp[published files]

I really want to deploy to predictable folders like...

C:\build\website[published files] C:\build\mobilewebsite[published files]

That's the background. Here are the specific questions.

  1. Are we making a mistake trying to use MSDeploy to publish to a local filesystem? We basically need the equivalent of the VS2010 "publish" feature, with config transforms. We're not trying to deploy to remote IIS instances or anything.

  2. Is there any way of doing this but specifying the publish folders?

  3. I've been trying to use the MSBuild Copy task to copy the files into more sensible folders - but I can't work out how to use wildcards to specify the folders we need to take - it would need to be something like...

C:\FolderPackageEndsUpIn[ANYFOLDERS]\Website[ANYFOLDERS]\PackageTmp**.

Help!

Was it helpful?

Solution

You can use WebDeploy directly to get a more tuned outcome. For example you can use the following command to sync 2 folders directly root-to-root:

>"%ProgramFiles%\IIS\Microsoft Web Deploy\msdeploy.exe" -verb:sync -source:dirPath=<SourceFolder> -dest:dirPath=<DestinationFolder>

Or you can make WebDeploy include IIS configuration on the destination by using iisApp provider instead of dirPath:

>"%ProgramFiles%\IIS\Microsoft Web Deploy\msdeploy.exe" -verb:sync -source:iisApp=<SourceFolderOrIISPath> -dest:iisApp=<DestinationFolderOrIISPath>

For example, to sync from a simple folder to a new app "NewApp" under Default Web Site, you will call it this way:

>"%ProgramFiles%\IIS\Microsoft Web Deploy\msdeploy.exe" -verb:sync -source:iisApp="d:\MyWebSite" -dest:iisApp="Default Web Site/NewApp"

Then, you can have a batch file that will perform sync/packaging by calling WebDeploy directly and will be execute as a post-build event.

OTHER TIPS

If you add the _PackageTempDir parameter to MSBuild it will give you the same results as doing a local publish. e.g.

msbuild C:\PathToMyProj.csproj /p:Configuration=UAT;DeployOnBuild=true;PackageAsSingleFile=False;DeployTarget=Package;_PackageTempDir=c:\PathToMyDeploy\;AutoParameterizationWebConfigConnectionStrings=false

This command will publish all my files to c:\PathToMyDeploy\ without the crazy subfolders

There is a slightly hidden but elegant solution.

When running a build on a shared CI server it might be hard to pack in the c: root for isolation reasons. One would ultimately prefer to remove the deep path in the package itself.

Fortunately there is a solution. Add a replace rule in the .pubxml file! I found it in the supplement to inside ms build engine, 2nd edition: https://www.microsoft.com/learning/en-us/book.aspx?ID=16854

I also found it in this blog: http://learnaspmvc.blogspot.se/2014/07/web-packaging-fixing-long-path-issue.html

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top