Friday, October 18, 2013

Error: The target "_WPPCopyWebApplication" does not exist in the project

This applies to both Visual Studio 2010 and Team Foundation Server (TFS) 2010.

In my case, I had two projects of the follow types that needed to be published on the file system after build:

  • WCF Web Service Library


Build succeeds in the development environment, but fails on the CI/build server, giving the following error message:

The target "_WPPCopyWebApplication" does not exist in the project


Certain files do not exist unless you've installed Visual Studio on your build server.

The "good practice"-way to solve it

You can install Visual Studio on your build server to fix this easily. If you worry about maintaining files, I recommend simply installing Visual Studio and forgetting about it.

Now for the other method

On your development computer with Visual Studio installed, open the folder %ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v10.0.

For web development, two folders are required:

  • Web
  • WebApplications

Copy these folders to the same place on the build server.

Your awesome programs should be building and publishing properly now, but read on if the problem persists.

Files copied but still doesn't work?

In your project file (*.csproj), make sure to import the right .target file before trying to use "_WPPCopyWebApplication".

Here's example; this code automatically publishes a web application/service on the file system, after being buildt:

  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
  <Target Name="AfterBuild">
    <MSBuild Condition="'$(hasBuilt)' == ''" Projects="$(ProjectPath)" Properties="hasBuilt=true;Platform=$(Platform);Configuration=$(Configuration);WebProjectOutputDir=published" Targets="ResolveReferences;_WPPCopyWebApplication" />

In case you wonder where to put this, then somewhere at the bottom should be fine.

Check list
  1. Import Microsoft.WebApplication.targets, not Microsoft.Web.Publishing.targets. The latter will be imported automatically, so specify only the first one.
  2. Use $(MSBuildExtensionsPath32), not $(MSBuildExtensionsPath). The files don't exist under $(MSBuildExtensionsPath).

Decent reasons to only copy the files

  • Visual Studio 2013 was released just about a day ago, and I don't think we'll see (m)any updates for VS 2010.
  • The difference in size is several gigabytes (VS 2010) vs less than one megabyte (copy the files).


There are at least two ways to solve the problem; the right one depends on your needs.

If you install Visual Studio, the pro is that you never have to think about the files again ‒ not even when updates are released. The obvious con to copy only the necessities, is potential maintenance.

With all this in mind, I choose to copy just the files. They take less than 1 MB compared to several GB, and I think it's fair considering the age of Visual Studio 2010. If the problem persists with VS 2012 and 2013, I'm not certain that I would make the same decision at time of writing.