MSBuild DeployOnBuild=true not publishing

Question

I have a Visual Studio 2010 MVC2 web application that I'm building via the command line using Hudson. I'd like to make Hudson publish a web output, so I added the DeployOnBuild=true and CreatePackageOnPublish=True tags to my command line.

My command is:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe 
   /target:Clean,Build 
   /property:Configuration=Debug;DeployOnBuild=True;CreatePackageOnPublish=True; 
   [my project name.csproj]

Running this command on my development machine (Windows 7) successfully publishes a web output to \obj\Debug\Package\PackageTmp\. But running it on the Hudson server (WS 2008) compiles successfully, but it doesn't publish. Same command, same version of MSBuild, same source code.

I've tried the /t:Publish target, which gives me a Skipping Unpublishable Project response, as I've seen on several other people's posts.

I've tried adding the DeployOnBuild=True and CreatePackageOnPublish=True tags to my project file as well, and no change.

Any thoughts on why this isn't publishing? Am I using these tags incorrectly? I'm sure there's something here that I'm just not seeing.

Loth

Did you ever figure this out? I am hitting the same wall right now. – Disposure

I moved TeamCity to a new server and all web apps artifacts were emtpy zips for over 50 projects. Normal services and test apps were artifacted fine.. been trying to solve this exact issue for over 24 hours now ;( – Wieldy

Answer 1

Assuming you do not have Visual Studio 2010 installed on your hudson server, then it may be that you are missing the publishing "targets" file. After a lot of head-to-desk banging, I finally solved this.

For quite a while I have known that I needed to copy the directory

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications

from my local machine with VS2010 to my server in order to get the project to build. But to get the project to also publish I needed to also copy over the directory

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web

Note: In my case I am actually committing those folders to my source control and changing the <MSBuildExtensionsPath32> value in my csproj file to point to these checked out folders (so there is one less step when prepping a server). This isn't necessary to get it to work, but you may want to consider this after you solve your issue.

UPDATE: So after I did the above, the build complained that it could not find "Microsoft.Web.Deployment.dll". To solve this I needed to install Microsoft Web Deploy v2.0 on the server even though I am only publishing to the file system. I guess I can see the logic in this.

UPDATE: I have discovered that installing "Visual Studio 2010 Shell (Integrated)" through the IIS Web Platform Installer will install the required build targets. This seems like a nice compromise between not having the entire Visual Studio application installed on your server and not manually copying seemingly arbitrary folders to your server from your dev machine.

Lunitidal

Already done this, and I am still getting the same results. DeployOnBuild is still being ignored. – Disposure

I tried the Web Deploy 3.0 RC and worked like a charm! Thanks – Yasukoyataghan

The update is no longer true: installing VS 2013 Shell (Integrated) does NOT provide the required "Web" folder under the MSBuild installation. – Parvati

Thank you so much. You saved me a lot of time. Everywhere I had read that the WebApplication folder was needed, but nobody mentioned the Web folder. My compilation on Jenkins always ended without errors but always ignoring the publication. My Visual Studio solution consists of a service, a couple of projects, and a WebApp and now finally publish on local filesystem perfectly simply using the /p:VisualStudioVersion=12.0 /p:DeployOnBuild=true /p:PublishProfile=ProfileName and without making no change to the .pubxml file. Thanks you again! – Elainaelaine

Has this location changed for msbuild 14.0? I don't see that web folder locally despite Visual Studio 2017 being installed but webapplications is there. – Wallet

If you have Visual Studio 2017+ installed locally, you will need copy the web folder from 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\Web' instead – Wallet

Answer 2

It seems that conditions to run publish target are not satisfied.

1) You can have different publication paths

2) Condition to run publish target is false

To verify both of them call your command with flag /v:diag. Search by Target "Publish" and try to figure out what really happens. It will looks like

Target "ExecuteT4Templates: (TargetId:144)" in file "D:\App\App.csproj" from project "D:\App\App.csproj":
Skipping target "ExecuteT4Templates" because all output files are up-to-date with respect to the input files.
Input files: D:\App\App.exe\\App_Config\Configuration.tt;D:\App\App.exe\\App_Config\Debug.App.tt;obj\\Debug.t4lastbuild
Output files: D:\App\App.exe\\App.config
Done building target "ExecuteT4Templates" in project "App.csproj".: (TargetId:144)

Smile

Thank you for the /v:diag idea. I think we're getting closer. It doesn't look like the "Publish" target is getting hit even when the package deployment is successful. The first indication of something different between the two outputs is that on the machine that works, the following settings are mentioned. This is very close to the start of the output: _CreatePackage = True _DeployOnBuild = True _PackageTempDir = obj\Debug\Package\PackageTmp Before this, there are no significant differences between the two outputs. Any ideas on the conditions for hitting these settings? – Loth

Answer 3

Was running into this with VS2012 -- ended up installing web developer tools on the build server and that fixed it.

Sydneysydnor

what is this web develoepr tools exactly you're talking about? – Achromat

It's web development tools in VS installation menu i assume – Wither

Answer 4

Further to the answer by Brian Hinchey, I found that I also required to append my msbuild batch call with the additional parameter VisualStudioVersion so that the correct version and path on the build agent (TeamCity in my case) to Microsoft.WebApplication.targets would be called. Without this parameter the web deploy and publish step was not completed and my batch completed successfully with a code 0 returned making analysis very difficult - even with the /verbosity flag appended to 'debug' the build. This point is made by SAYED IBRAHIM HASHIMI on his site: http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx

The scenario for my case was that I had the Visual Studio compatibility enabled on my MVC web project so that I could open the project in VS2010 or 2012 (as Sayed notes in the above link) - so I'm dev'ing locally in VS2012 whereas the TeamCity build agent has the VS 2010 web build and deploy targets.

Bandy