MSBuild 2015 publish: Can't find the valid AspnetMergePath

Question

I have a build on TeamCity that packages a web project ready for later deployment, currently using MSBuild 2013. When I pushed some code recently I got build errors (due to the fact that I was using some C# 6 features) so I went to change the build configuration to use MSBuild 2015 instead and got this error:

[Error] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Transform\Microsoft.Web.Publishing.AspNetCompileMerge.targets(132, 5): Can't find the valid AspnetMergePath

This error has been mentioned in other questions before (such as here: VS 2012 Publish: Can't find the valid AspnetMergePath) but unfortunately none of the fixes mentioned in those questions have worked for me.

Things I have already tried or were already the case:

• Web and WebApplication directories from local machine (at C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0) have been copied up to build server (they've always been there)
• Added <TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\</TargetFrameworkSDKToolsDirectory> to Microsoft.Web.Publishing.AspNetCompileMerge.targets file
• Added /p:AspnetMergePath="C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\" to MSBuild command

I'm at a bit of a loss with this one: pretty much the only thing I haven't tried is installing Visual Studio on the build server, but I'd really like to avoid that if I can (because I think it's ridiculous that you should have to install a full IDE on a CI server!).

Some further info:

• everything continues to work just fine if you switch the build back to MSBuild 2013 (although, obviously, we don't want to get stuck in the past)
• we have a number of other pure compilation builds that are running against MSBuild 2015 with no errors

Answer 1

Both the second and the third solution originally proposed on VS 2012 Publish: Can't find the valid AspnetMergePath actually do work, but the right version of the SDK tools has to be provided.

The original article (VS 2012 Publish: Can't find the valid AspnetMergePath) was written in 2013 and covers the Visual Studio 2012. The aspnet_merge.exe that supports C# 6.0 and .NET 4.6 is not the one that is found under the path "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\".

In order to get the third solution work, use the following path instead "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\".

In oder words, adding /p:AspnetMergePath="C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\" to MSBuild command solves the problem.

My team had exactly the same issue as the one you are describing and adding this parameter to the MSBuild step immediately fixed it. (I assume of course that you have the NETFX 4.6 version of the tools on your build machine.)

As a side note, since you said that you use Team City - instead of adding the above parameter directly as a command line parameter, you can use the Team City recommended and configure the corresponding build parameter.

Answer 2

The accepted answer is just symptom treatment and doesn't address the underlying issue. Please run MSBuild with diagnostic logging. If you look at the Microsoft.Web.Publishing.AspNetCompileMerge.targets you will see that it attempts to concatenate TargetFrameworkSDKToolsDirectory with AspnetMergeName. If you search in your MSBuild log, you will find that TargetFrameworkSDKToolsDirectory is empty. TargetFrameworkSDKToolsDirectory is build from TargetFrameworkSDKDirectory which is also empty.

That is what you need to fix. In my case:

• Install the Windows 7.1 SDK (using this workaround on Windows Server 2016).
• In VS2017 the path is determined based on /configuration/msbuildToolsets/toolset/property[@name="FrameworkSDKRoot] which is in my case Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\NETFXSDK\4.6.1@InstallationFolder. In my case this node was only available in the WOW6432Node, it needs to be available in the 64-bit registry too. You need to copy the node to the equivalent location in the 64-bit registry.