Environment: TFS 2012 build agent running on a Windows Server 2012 VM. .Net 4.0/.Net 4.5 installed. The Windows SDK (http://msdn.microsoft.com/en-us/library/ms717422.aspx) has also been installed.
Issue: The build agent cannot build .net 4.0 web applications developed using VS 2012.
The build fails because it cannot resolve the web targets:
Error The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
Additional warnings then follow: The reference assemblies for framework ".NETFramework,Version=v4.0" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
I searched for .NET 4.0 targeting packs here:
http://msdn.microsoft.com/en-US/hh487283.aspx
but Windows Server 2012 is not listed as a supported platform.
The IT infrastructure team are not keen on installing VS on each build agent VM just to get a targeting pack.
Does anyone have any ideas as to how I might resolve this?
Disclaimer
I realise the solution I mention below is frowned upon by alot of dev ops people, but in my experience it it by far the simplest and most reliable way to solve the issue.
Solution
By far the easiest solution to this issue is to install Visual Studio 2012 on your build server. I know you've said that the infrastructure team are not keen to do it, but IMO it's a best practice. I'll try to outline why below.
Installing Visual Studio on your build server seems like a strange thing to do, but having been around the TFS block a bit, I have found it to be the simplest way to manage build servers.
You can copy the files (targets) manually from your dev machine to your build server, but if an update to visual studio comes out, you will need to figure out what has changed and make sure you update all those files too. These files typically include Targets files and associated dlls.
Also with all the extensions and packages that are available now, it is just easier to load Visual Studio on your build server and install the required packages than try to work out what is needed to replicate the functionality.
This was made very clear to me recently when Microsoft released ASP.Net and Web Tools 2012.2. This altered the publishing pipeline for Web Sites and Web Projects and I needed to use this in my TFS build. It was so much easier to just be able to log onto my build server, load Visual Studio and download the new update.
I would definitely support installing Visual Studio on your build server.