Im using VS 2015 for all of our projects now, but this one particular web app is using web forms. Should be no big deal, since I can perform a publish locally on my workstation to the test server without issue.
Ive setup TeamCity before but now it seems Im having trouble getting a new instance configured. Using TeamCity 9.1.5 (build 37377), but without Visual Studio on the server.
Code is in a solution created with Visual Studio 2015.
Pretty much going along with these examples
http://www.danmusk.com/how-to-build-asp-net-applications-in-teamcity-with-msbuild-tools-2013-and-net-framework-4-5-sdk/
Have installed MSBuild 2015 tools on the server
Upon running the build, I get this:
Microsoft.Web.Publishing.AspNetCompileMerge.targets(132, 5): Can't find the valid AspnetMergePath
My build step looks like this
[update]
I think I might have found the culprit - I looked at the locations where the Windows SDK is supposedly installed and it was very sparse. The aspnetmerge tool was nowhere to be found. Gee, that might be why I get the error?
[ update ]
Using msbuild from the command line, I get
Microsoft.Web.Publishing.AspNetCompileMerge.targets(133,5): error : Can't find the valid AspnetMergePath
Also, since starting this tread, Ive installed then Windows 10 SDK. My TeamCity build configuration works now. Ive updated my Microsoft.Web.Publishing.AspNetCompileMerge.targets file with this:
<Target
Name="GetAspNetMergePath"
DependsOnTargets="$(GetAspNetMergePathDependsOn)"
Condition ="'$(GetAspNetMergePath)' != 'false'">
<PropertyGroup>
<TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\</TargetFrameworkSDKToolsDirectory>
<AspnetMergeName>aspnet_merge.exe</AspnetMergeName>
<AspnetMergePath Condition="Exists('$(TargetFrameworkSDKToolsDirectory)$(AspnetMergeName)')">$(TargetFrameworkSDKToolsDirectory)</AspnetMergePath>
</PropertyGroup>
<Error Condition="'$(AspnetMergePath)' == '' Or !Exists($(AspnetMergePath))"
Text="Can't find the valid AspnetMergePath" />
</Target>
See the update in the original post. The server I was trying to build on had very minimal and old SDK's on it. I grabbed the latest Windows 10 SDK, installed and updated the Microsoft.Web.Publishing.AspNetCompileMerge.targets file as shown above. Then restarted both TeamCity services and the build finally worked.
Related
Hi Stackoverflow Community,
I am trying to build my Web and WebAPI, console applications with Target Framework - .NET Core 3.0, as per project 'Application' properties, using:
Microsoft Visual Studio Community 2019
Version 16.5.4 on Windows 10 PRO
I am seeing the following errors:
Error MSB3030 Could not copy the file "C:\Users...\WebApi3\obj\Debug\netcoreapp3.0\webapi3.exe" because it was not found
and
Error MSB3030 Could not copy the file "C:\Users...\Web\obj\Debug\netcoreapp3.0\webportal.exe" because it was not found
Hence these projects are not getting built.
Appreciate your time for reading this.
Please advise.
Here is the part of the code where the error points to:
============================================================
_CopyOutOfDateSourceItemsToOutputDirectory
Copy files that have the CopyToOutputDirectory attribute set to 'PreserveNewest'.
============================================================
-->
<Target
Name="_CopyOutOfDateSourceItemsToOutputDirectory"
Condition=" '#(_SourceItemsToCopyToOutputDirectory)' != '' "
Inputs="#(_SourceItemsToCopyToOutputDirectory)"
Outputs="#(_SourceItemsToCopyToOutputDirectory->'$(OutDir)%(TargetPath)')">
<!--
Not using SkipUnchangedFiles="true" because the application may want to change
one of these files and not have an incremental build replace it.
-->
<Copy
SourceFiles = "#(_SourceItemsToCopyToOutputDirectory)"
DestinationFiles = "#(_SourceItemsToCopyToOutputDirectory->'$(OutDir)%(TargetPath)')"
OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
Retries="$(CopyRetryCount)"
RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)"
UseHardlinksIfPossible="$(CreateHardLinksForAdditionalFilesIfPossible)"
UseSymboliclinksIfPossible="$(CreateSymbolicLinksForAdditionalFilesIfPossible)"
>
<Output TaskParameter="DestinationFiles" ItemName="FileWrites"/>
</Copy>
</Target>
I faced the same issue in VS2022(17.0.1) as well. I performed below steps based on a github issue [https://github.com/dotnet/sdk/issues/3122] discussion and my issue got resolved. I believe this works for VS2019 as well.
Step1: Clean Local Nuget Cache
..\projectDir> dotnet nuget locals all --clear
Step2: remove bin and Obj folders
..\projectDir> rd \s \q bin obj
Step3: Clean the solution using Visual studio build menu
Step4: Rebuild Project
Updating Visual Studio to 16.5.5. seems to have solved the issue so far.
I had a similar issue but whilst attempting to publish. The affected .DLL was a nuget package and I noticed I had an update for it.
Updating the affected package, cleaning the solution, rebuilding then re-publishing resolved my issue.
For CoreXT repos by default only outputs under obj for retail builds or objd for debug builds are collected. You seem to be using the retail bridge and using obj(Debug|Release) and bin (the MSBuild non-CoreXT defaults), so those outputs are not being collected.
To remedy this, you can set the -UsePredictedOutputPath QuickBuild flag which will avoid collecting those hard-coded paths and instead ask each project what its $(IntermediateOutputPath) and $(OutputPath) are and use those.
Note that in either case, outputs under output roots (eg /target) are always collected. This flag only affects the project-relative outputs.
I've been running my ASP.NET Core 2.1 Preview-1 app on Azure since this release became available. I had installed the ASP.NET Core runtime extensions through the portal and it's been working fine.
Now that Microsoft released ASP.NET Core 2.1 Preview-2, I installed the upgrade to the SDK. Updated my Nuget packages so that I have the preview-2 versions of everything. See my csproj file below:
I also removed the ASP.NET Core Runtime extensions from Azure App Service for my app which was showing 2.1 Preview-1. Instead installed ASP.NET Core 2.1 run times for x86 and x64 separately -- see below:
Compiled the app and published it to my Azure App service but I'm getting errors. First I got the 502.5 error. Now, I'm getting:
The specified CGI application encountered an error and the server
terminated the process.
What am I missing here?
UPDATE:
As the answer suggested, I set my target to x86 (to play it safe) -- see below:
I removed the extension and the individual x86 and x64 run times and installed only the x86 with support for ASP.NET Core 2.1 preview-2 -- see below:
I restarted the app several times and I'm still getting 502.5.
I then tried to do a self deploy through CLI command line by issuing the following command:
dotnet publish -c Release -r win10-x64
And I get the following error:
C:\Program
Files\dotnet\sdk\2.1.300-preview2-008530\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(125,5):
error : The RuntimeIdentifier platform 'win10-x64' and the
PlatformTarget 'x86' must be compatible.
Does this mean I have the x86 version of the SDK installed and I must target x86?
I didn't have half the trouble that I'm going through now going from ASP.NET Core 2.0 to 2.1!!!!
UPDATE 2:
Just ran dotnet --info in Kudu console. If I'm reading this correctly, I don't have the correct runtime.
Update 3:
I think this screen shot confirms what I was saying.
Update 4:
I installed x86 version of ASP.NET Core 2.1 Runtime -- see below:
When I run dotnet --info in Kudu console, I get the following which confuses me. I'm still not seeing the version I was expecting to see:
And when I hit the URL, I'm still getting 502.5 and the same message in Kudu console when I run dotnet MyApp.dll telling me that the correct version of the runtime is not found.
How will I get the correct version in there? I thought installing it through the portal would do it.
We've managed to publish ASP.NET Core 2.1 RC1 webapp to Azure app-service using "self-contained" deployment mode.
Platform target: Any CPU
Here are the package references from our .csproj:
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.1.0-rc1-final" PrivateAssets="All" />
<PackageReference Include="Microsoft.AspNetCore.AzureAppServicesIntegration" Version="2.1.0-rc1-final" />
The steps I took to get this working:
Remove the 2.1-preview1 ASP.NET Core Runtime Extension.
Check the application settings to see if you're running under 32-bit or 64-bit.
Install only the matching (32- or 64-bit) ASP.NET Core 2.1 Runtime.
Restart the web app.
Restarting is important - before restarting the .NET Core tools were the wrong version and I would also get 502.5 errors.
As you've installed both 32- and 64-bit runtimes I'd try removing the one that your application doesn't need and restart the web app.
I had the same problem. Finally after 2 hours I fixed it.
Here is my configuration:
Extensions:
Console dotnet --info command:
Console kudu dotnet --version command:
a) Remember to restart your app after install extension.
b) Clear your wwwroot folder from old files and publish again.
I got my project working on asp.net core 2.1 Preview 2 on Azure.
I did the following steps;
Deleted the old asp.net core extension from Azure app service Extension
Using kudus deleted all the files in wwwroot folder of the site.
Installed asp.net core site extension from Azure as shown in the picture below and restarted the app service
Before deploying to Azure, the publish configuration option used is as depicted in the picture below,
That's it.
Try adding a global.json file in your project folder with this content:
{
"sdk": {
"version": "2.1.300-preview2-008530"
}
}
Restart your app after that to be on the safe side.
Here's the only thing that seems to have worked for me.
I did a self-contained deployment using
dotnet publish --self-contained -r win10-x64 -c Release
I then had to do a manual deployment -- in my case using FTP.
I really would like this issue to be resolved but if it's not resolved by my next deployment, I'll do the zip deploy. Because my app has a ReactJs frontend, there were thousands of files to deploy and FTP was not a lot of fun!
Because this approach doesn't depend on what's installed or not installed on Azure App Service, it's a much more straight forward solution.
I still want to be able to simply click Publish in Visual Studio though!
UPDATE:
I just did a zip deployment and I'm still getting the errors I was getting before even though zip deployment was successful. So, something is still not right!
I had a problem with a complex website, so I created a simple one with just the App file set at the same version:
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.3" />
</ItemGroup>
and then, taken from Tim Diekmann's example, I did nothing apart from changing the Deployment Mode in the Azure publishing configuration Settings to Self-Contained - and that worked.
I am trying to learn how to develop apps for UWP for both Desktop and Mobile. I have been currently working on getting the Entity Framework working in my app to store application state and followed the following link:
https://learn.microsoft.com/en-us/ef/core/get-started/uwp/getting-started
It worked well for Desktop, the issue however is that when I try to run it on the Windows Mobile emulator I get the following error in debug mode when the code reaches the db.Database.Migrate() step:
Unable to load DLL 'sqlite3': The specified module could not be found
In the link I pasted above, someone else had the same issue and in the comments they recommended to try the following:
Step 1: Install SQLite VSIX pacakge for Universal Windows Platform development using Visual Studio 2015
https://www.sqlite.org/2016/sqlite-uwp-3130000.vsix
Step 2: Install NuGet package SQLite.NET-PCL
Install-Package SQLite.NET-PCL
Step 3: Add references
Add Reference -> Universal Windows ->Extensions -> Make sure the following packages have been checked: "SQLite for Universal Windows Platform" "Visual C++ 2015 Runtime for Universal Windows Platform Apps"
After that, if you get the error "Payload contains two or more files with the same destination path 'sqlite3.dll', do the following:
copy sqlite3.dll from
C:\Program Files (x86)\Microsoft SDKs\UAP\v0.8.0.0\ExtensionSDKs\SQLite.UAP.2015\3.8.11.1\Redist\Debug\ARM\sqlite3.dll
past to (override it)
C:\Users\%USERNAME%\.nuget\packages\SQLitePCL.raw_basic\0.7.1\build\native\sqlite3_dynamic\winrt81\arm\sqlite3.dll
The problem after doing those steps is that I am now seeing the issue when doing a build for "Payload contains two or more files" however not in the SQLitePCL.raw_basic directory (I don't even seem that have that). Instead my error is the following:
Payload contains two or more files with the same destination path 'sqlite3.dll'. Source files:
C:\Users\admin\.nuget\packages\SQLite\3.13.0\runtimes\win7-x86\native\sqlite3.dll
C:\Program Files (x86)\Microsoft SDKs\UAP\v0.8.0.0\ExtensionSDKs\SQLite.UWP.2015\3.13.0\Redist\Debug\x86\sqlite3.dll
I have been searching everywhere and am truly stumped as to how to get my UWP program working on Mobile. Thanks a lot for your help!
It seems like you got the solution for resolving the exception The specified module could not be found from #Leandro_Medeiros_Machado 's comment on this document. If you got the Payload contains two or more files with the same destination path 'sqlite3.dll' exception after you done the above three steps you may be also found the next solution from the comment.
After that, if you get the error "Payload contains two or more files with the same destination path 'sqlite3.dll', do the following:copy sqlite3.dll from
C:\Program Files (x86)\Microsoft SDKs\UAP\v0.8.0.0\ExtensionSDKs\SQLite.UAP.2015\3.8.11.1\Redist\Debug\ARM\sqlite3.dll
past to (override it)
C:\Users\%USERNAME%\.nuget\packages\SQLitePCL.raw_basic\0.7.1\build\native\sqlite3_dynamic\winrt81\arm\sqlite3.dll
For you, you may need to copy from
C:\Program Files (x86)\Microsoft SDKs\UAP\v0.8.0.0\ExtensionSDKs\SQLite.UWP.2015\3.13.0\Redist\Debug\x86\sqlite3.dll to(override) C:\Users\admin\.nuget\packages\SQLite\3.13.0\runtimes\win7-x86\native\sqlite3.dll.
But actually, for using EF core you don't need the above steps and I recommend you check your environment instead of using the above workaround. I created a simple EF project by following the document and without install the VSIX I can run successfully on the emulator (build 10586). My VS build is 2015 update 3, my OS version is build 14393 and the EF core version is Microsoft.EntityFrameworkCore.Sqlite 1.1.0. So please firstly check if your environment met the following requirements:
Windows 10
Visual Studio 2015 Update 3
The latest version of Windows 10 Developer Tools
And if your EF core and EF core tools versions are right.
First some background. At the end of 2012 we migrated our vs2008 solution to vs2010 but we still target .NET 3.5. (I know nothing but the latest and greatest here!)
We hadn't had any issues with this setup until a few weeks ago when people started getting these errors:
"foo.csproj" (Rebuild target) (16:5) ->
C:\...\foo.csproj(142,3): error MSB4019: 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.
The interesting thing is that if you look at the project file it references v10 which makes sense because we don't use Visual Studio 2012.
This error hit several of us at once and even on older code branches that haven't changed in months.
I suspect some update got pushed onto our machines that confused things but I don't know what to do about it.
The short term solution has been to install VS 2012 and not use it but I'm hoping for something a little cleaner than that.
I ran into the same issue with Visual Studio 2013. It turns out that I was using the old version of MSBuild--the one that ships with the .NET Framework--from the command line. Microsoft is now releasing MSBuild as part of Visual Studio itself and also as a separate installer (http://blogs.msdn.com/b/visualstudio/archive/2013/07/24/msbuild-is-now-part-of-visual-studio.aspx).
The solution was to use the new version of MSBuild.exe located in C:\Program Files (x86)\MSBuild\12.0\Bin. Once I did that, all the targets errors disappeared.
EDIT 1
As mentioned in the comments, each new version of MSBuild brings with it a new directory. For Visual Studio 2015, use C:\Program Files (x86)\MSBuild\14.0\Bin.
EDIT 2
As mentioned in the comments, for Visual Studio 2017, use C:\Program Files (x86)\Microsoft Visual Studio\2017\<Edition>\MSBuild\15.0\Bin\MSBuild.exe.
If you have a build server that does not have VS2012 installed, you can fix this by
a) installing the MSBuild.Microsoft.VisualStudio.Web.targets package to your solution, and
b) replacing this line in the .csproj file:
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
With this line pointing to the nuget package
<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" Condition="true" />
EDIT
As #joedragons points out the version in the updated line should match the nuget package version, i.e. replace targets.11.0.2.1 with targets.x.x.x.x for the current version.
A simple solution to this problem:
Go to the following path:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio
You will see the latest version V10.0, v11.0, v12.0 depending on your Visual Studio 2010, 2012 or 2013 install.
Copy WebApplications folder from either of latest version directory and paste to other.
Your issues should be resolved.
I've found that installing the free Visual Studio 2012 Shell (Isolated) installs the WebApplications v11 MSBuild files. Lighter than a full install of Visual Studio 2012 and no licensing concerns.
Wow. We just saw the same thing happen on our build machine. We use VS2010 and target .NET 4.0. Our project files explicitly import the v10.0 version of these targets. With no changes to the code, yesterday the build was fine and today it's failing with a complaint about a missing v11.0 version. The .NET Framework 4.5.1 got installed/updated last night on this build machine as an automatic update. We're going to force v10.0 with the parameter (or env. variable), but this certainly took us by surprise...
UPDATE: What's even more weird, is that it seems to be the case that today's version of msbuild seems to be using the first line of the sln file to determine which VisualStudioVersion to use by default, whereas yesterday's version did not:
Format Version 12.00
We tested manually changing this to 11.00 and the build started working again.
In our case, even though we're targeting and building everything for 2010/4.0, some devs have been getting ready for VS2012 (since MS claimed that the project files are compatible), and this particular solution was last saved (months ago) in VS2012. Before today, that wasn't causing a problem.
I had the same issue. Fixed by going through above listed solutions. The issue is caused because appropriate version of Visual Studio Tools (BuildTools) is not available on the Build server. As rightly pointed above, this can be resolved by installing BuildTools but is not the option in my case.
Here is another alternative - use Nuget
Install-Package MSBuild.Microsoft.VisualStudio.Web.targets -Version 14.0.0.3
Identify the start up project and Install the web.targets based on the version of Visual studio being used.
The following files will be modified which includes the required changes
In packages.config:
<package id="MSBuild.Microsoft.VisualStudio.Web.targets" version="14.0.0.3" targetFramework="net45" />
In .csproj:
<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props" Condition="Exists('..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props')" />
Hope this helps!!! Good Luck,
Cheers,
Hack, but solved it by copying:
c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications*.*
to
c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications*.*
I got this error in the end of November without making any changes to either the configuration of my TeamCity installation or MSBuild installation or the source code. On my build server Visual Studio isn't even installed, and the change from VS2010 to VS2012 was made in the end of August without any problems at the time.
My MSBuild version is 4.0.30319.18408, my build server is a Windows Server 2008 R2 SP1 with TeamCity v6.5.3.
I solved the issued by simply copying the v11-folder from another build server which was unaffected.
My guess is that this could have happened in two ways:
Something was updated which triggered a deletion of the v11-folder. Could it be a Windows Update to .NET or something?
Something was updated which changed my TeamCity/MSBuild configuration from using v10 to v11 and the builds stop working as the v11 never existed.
I've got a update to .NET Framework 4.5.1 on December 3rd, could that be the reason?
Brgds
Jonas
I've recently got stuck with the same problem. And my conclusion is that every version of VS (v10, v11, v12) changes path of build variable, like MSBuildBinPath.
So specifying exact version of VS isn't a hack, because you might not even have appropriate version of files installed. So intead you'd better specify a parameter and use targets that exist on you machine.
In some rare cases you might need to install specific version of VS and Web Deploy package. In my case just version was enough to solve problem.
You can add the VisualStudioVersion property like this:
<ItemGroup>
<ProjectToBuild Include="$(MSBuildProjectDirectory)\..\MySolution.sln">
<Properties>Configuration=$(BuildConfiguration);WarningLevel=0;VisualStudioVersion=12.0</Properties>
</ProjectToBuild>
</ItemGroup>
<MSBuild Projects="#(ProjectToBuild)" Targets="Rebuild"/>
As I was searching how to solve this one, almost everyone recommended either to copy the missing MSBUILD folder or install some SDK of some version.
Luckily, I've found this awesomely helpful post by Donovan Brown :
http://donovanbrown.com/post/So-sick-of-MicrosoftWebApplicationtargets-was-not-found-build-errors!
In a nutshell, the idea is to configure the VisualStudio version your build should use in your Build Definition:
Right Click -> "Edit Build Definition..."
Go to "Procss" -> "3. Advanced"
and set "MSBuild Arguments" with
/p:VisualStudioVersion=12.0
I am wanting to use Visual Web Developer Express 2010 to publish a website, pre-compiled to a remote server over FTP using the following settings:
Deploy only files needed to run this application
Precompile this application before publishing
Allow website to be updatable
No databases are being deployed
Site is being deployed as file hierarchy, not as .zip package
My first build/deploy seemed to have gone well, but after my second compilation I receive the following error:
Transformed web.config using C:\path_to_site\Web.Debug.config into obj\Debug\TransformWebConfig\transformed\web.config.
Copying all files to temporary location below for package/publish:
obj\Debug\AspnetCompileMerge\Source.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.5\Web\Transform\Microsoft.Web.Publishing.AspNetCompileMerge.targets(132,5): Error : Can't find the valid AspnetMergePath
And here's a subset of the content of the Microsoft.Web.Publishing.AspNetConfigurationMerge.targets file:
<Target
Name="GetAspNetMergePath"
DependsOnTargets="$(GetAspNetMergePathDependsOn)"
Condition ="'$(GetAspNetMergePath)' != 'false'">
<PropertyGroup>
<AspnetMergeName>aspnet_merge.exe</AspnetMergeName>
<AspnetMergePath Condition="Exists('$(TargetFrameworkSDKToolsDirectory)$(AspnetMergeName)')">$(TargetFrameworkSDKToolsDirectory)</AspnetMergePath>
</PropertyGroup>
<Error Condition="'$(AspnetMergePath)' == '' Or !Exists($(AspnetMergePath))"
Text="Can't find the valid AspnetMergePath" />
</Target>
EDIT: Changing the publish settings to delete all existing files before publishing does not fix the problem after all. I'm assuming that the problem is local for now because of this.
There does not appear to be an AspMergePath tag in my web.config. I am not aware if I am supposed to manually add the tag. However, the path "obj{publish setting}\AspnetCompileMerge\Source" does exist in my project.
And in case it matters, my project name is "TestProject.NET"
Your feedback is appreciated.
I hit the same problem. Searched through all microsoft related sites, found a lot of complaints and no intention from microsoft to fix it.
Here how I worked it around at my system. Edit the Microsoft.Web.Publishing.AspNetConfigurationMerge.targets file and add the following line. Please make sure that the Microsoft SDK path is the same on your PC, if not then change it:
<TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\</TargetFrameworkSDKToolsDirectory>
Here is how it should look like:
<Target
Name="GetAspNetMergePath"
DependsOnTargets="$(GetAspNetMergePathDependsOn)"
Condition ="'$(GetAspNetMergePath)' != 'false'">
<PropertyGroup>
<TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\</TargetFrameworkSDKToolsDirectory>
<AspnetMergeName>aspnet_merge.exe</AspnetMergeName>
<AspnetMergePath Condition="Exists('$(TargetFrameworkSDKToolsDirectory)$(AspnetMergeName)')">$(TargetFrameworkSDKToolsDirectory)</AspnetMergePath>
</PropertyGroup>
<Error Condition="'$(AspnetMergePath)' == '' Or !Exists($(AspnetMergePath))"
Text="Can't find the valid AspnetMergePath" />
What you need is aspnet_merge.exe, tool that is distributed as part of Windows SDK. It's intended to precompile sites, so you can either turn that precompilation off, or install proper version of Windows SDK. Reference is to the Wikipedia, because of nice prepared links to the download pages. You don't need to download/install everything (it's huge), just download web installer and select .Net tools, it will take around 50 megabytes.
Please, notice that bundled with Visual Studio 2010 Windows SDK ver. 7.0A isn't available to separate download, so you'll have to either install Visual Studio on your build server, or tweak something as described in answers to "Running MSBuild fails to read SDKToolsPath".
Here is a solution that does not require changing the targets file. The workaround from http://connect.microsoft.com/VisualStudio/feedback/details/786492/publish-cant-find-the-valid-aspnetmergepath suggests passing additional properteries to msbuild. I was able to get it to work using this:
msbuild website.publishproj /p:DeployOnBuild=true /p:PublishProfile=Release /p:VisualStudioVersion=12.0 /p:AspnetMergePath="C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\"
The key here is the AspnetMergePath property, which you may need to change if the Windows SDK is installed in a different location. If I include the GetAspNetMergePath property from the workaround it fails, but that may be needed depending on the SDK version.
One workaround for all this stuff [including having to install the SDK etc] is to disable the Precompile On Publish option, which requires AspNetMerge to be present even if you're not specifying that you want stuff to be merged in the ultimate output.
I was going to great lengths to figure out how to turn it off, poring over the options dialog and Reading the Friendly Manual to confirm I had it turned off for ages only to realize it was the checkbox outside:
Unchecking yields the following changes to the .pubxml:
- <PrecompileBeforePublish>True</PrecompileBeforePublish>
- <EnableUpdateable>True</EnableUpdateable>
- <DebugSymbols>False</DebugSymbols>
- <WDPMergeOption>DonotMerge</WDPMergeOption>
Which worked for me.
NB it is however critical to have as covered here both the Web (which will silently make publishing via /p:DeployOnBuild inert) and the WebApplications (which will give a compiler error) subfolders present under %Program Files (x86)%\MSBuild\Microsoft\VisualStudio\v14.0 (assuming Visual Studio 2015 tooling) for publishing to successfully generate packages
I hit the same problem.
Edit the Microsoft.Web.Publishing.AspNetConfigurationMerge.targets file and add the following line. Make sure run editor with Administrator Rights.
Looks the correct versión Visual Studio in my case VS2013.
x64
<TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\</TargetFrameworkSDKToolsDirectory>
x86
<TargetFrameworkSDKToolsDirectory>C:\Program Files\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\</TargetFrameworkSDKToolsDirectory>
And it Works! I can compile my Project.
In my case was missing. It happened after updating Visual Studio 2017 to 15.7.5. Before that it was working fine. I have to add
<TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\</TargetFrameworkSDKToolsDirectory>
It was at Line no 129 in Microsoft.Web.Publishing.AspNetCompileMerge.targets
change targetFramework ...
<compilation debug="true" targetFramework="4.8"/>
<httpRuntime targetFramework="4.8"/>