Related
I am trying to include Directory.build.props file as I want to have one place to change the version of all the projects.
If I build solution using Visual Studio the properties inside Director.build.props file are correctly embedded inside the built exe file.
If I use the dotnet build command, the exe file does not have the required properties embedded.What I observed is that the dll files have correct properties embedded using CLI command as well using Visual Studio.
The Directory.build.props file is located at the root of the solution (I've tried putting it at the root of the project and the same thing happens).
This is the Directory.build.props file that I'm using
<Project>
<PropertyGroup>
<Company>Company</Company>
<Copyright>Copyright</Copyright>
<Version>1.0.0</Version>
<AssemblyVersion>1.0.0</AssemblyVersion>
<FileVersion>1.0.0</FileVersion>
</PropertyGroup>
</Project>
I'm wondering if I'm missing some configuration, and why are dlls successfully embedded with properties while the exe file is not?
Credits go to #Martin Ullrich, but on *nix the file should indeed be called Directory.Build.props (proper casing) otherwise it will be ignored.
Setting the attributes on the apphost executable is supported in the 3.0 SDK. Make sure you have at least the 3.0.100 SDK (i tested .NET Core 3.0 Preview 5) installed.
Trying to build my project on the build server gives me the following error:
Microsoft (R) Build Engine Version 4.0.30319.1
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamData\Microsoft.Data.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
I solved this problem a few months ago, with installing Visual Studio 2010 on the Build Server. But now I'm setup a new server from scratch, and I want to know if there any better solution to solve this issue.
To answer the title of the question (but not the question about the output you're getting):
Copying the following folder from your dev machine to your build server fixes this if it's just web applications
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications
Remove x86 according to how your build breaks. If you have other project types you will probably need to copy the entire msbuild folder.
The solution would be to install redistributable packages on build server agent. It can be accomplished multiple ways, out of which 3 are described below. Pick one that suits you best.
Use installer with UI
this is the original answer
Right now, in 2017, you can install WebApplication redists with MSBuildTools. Just go to this page that will download MSBuild 2017 Tools and while installation click Web development build tools to get these targets installed as well:
This will lead to installing missing libraries in C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\WebApplications by default
Use command line
disclaimer I haven't tested any of the following proposals
As #PaulHicks and #WaiHaLee suggested in comments, it can also be installed in headless mode (no ui) from CLI, that might actually be preferable way of solving the problem on remove server.
Solution A - using package manager (choco)
choco install visualstudio2017-workload-webbuildtools
Solution B - run installer in headless mode
Notice, this is the same installer that has been proposed to be used in original answer
vs_BuildTools.exe --add Microsoft.VisualStudio.Workload.WebBuildTools --passive
Building and publishing WAPs is not supported if VS is not installed. With that said, if you really do not want to install VS then you will need to copy all the files under %ProgramFiles32%\MSBuild\Microsoft\.
You will need to install the Web Deploy Tool as well. I think that is it.
UPD: as of VS2017, there is workload in Build Tools that eliminates this problem completely. See #SOReader answer.
If you'd prefer not to modify anything on build server, and you still want the project to build right out of source control, it might be a good idea to put the required binaries under source control. You'll need to modify the imports section in your project file to look like this:
<Import Project="$(SolutionDir)\BuildTargets\WebApplications\Microsoft.WebApplication.targets" />
<Import Condition="false" Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
The first line is the actual import from the new location that is relative to the solution directory. The second one is a turned-off version (Condition="false") of the original line that allows for Visual Studio to still consider your project to be a valid Web Application Project (that's the trick that VS 2010 SP1 does itself).
Don't forget to copy the C:\Program Files (x86)\Microsoft\VisualStudio\v10.0\WebApplications to BuildTargets folder under your source control.
You can also use the NuGet package MSBuild.Microsoft.VisualStudio.Web.targets, referencing them within your Visual Studio project(s), then change your references as Andriy K suggests.
Based on this post here you can simply download the Microsoft Visual Studio 2010 Shell (Integrated) Redistributable Package and the targets are installed.
This avoids the need to install Visual Studio on the build server.
I have just tried this out now, and can verify that it works:
Before:
error MSB4019: The imported project "C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
After the install:
[Builds correctly]
This is a far better solution than installing Visual Studio on a build server, obviously.
The latest Windows SDK, as mentioned above, in addition to the "Microsoft Visual Studio 2010 Shell (Integrated) Redistributable Package" for Microsoft.WebApplication.targets and "Microsoft Visual Studio Team System 2008 Database Edition GDR R2" for Microsoft.Data.Schema.SqlTasks.targets should alleviate the need to install Visual Studio 2010. However, installing VS 2010 maybe actually be less overall to download and less work in the end.
Add dependency through NuGet & set a Build Parameter
Goal: no changes / installs necessary to the build agents
I have taken a hybrid approach to the NuGet approach by Lloyd here, which was based off of the committing binary dependencies solution by Andrik.
The reason why is I want to be able to add new build agents without having to pre-configure them with items such as this.
On a machine with Visual Studio, Open the solution; ignore that the web project fails.
In the NuGet package manager, add MSBuild.Microsoft.VisualStudio.Web.targets, as Lloyd mentioned.
This will resolve the binaries to [solution]\packages\MSBuild.Microsoft.VisualStudio.Web.targets.nn.n.n.n\tools\VSToolsPath\
You can copy these to a references folder & commit,
Or just use them where they are at. I chose this, but I'm going to have to deal with the version number in the path later.
In Version 7, I did the following. This may not have been necessary, and based on the comments is definitely not needed now. Please see the comments below.
Next, in your TeamCity build configuration, add a build Paramenter for env.VSToolsPath and set it to the VSToolsPath folder; I used ..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath
When building on the build/CI server, turn off the import of Microsoft.WebApplication.targets altogether by specifying /p:VSToolsPath=''. This will, essentially, make the condition of the following line false:
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
This is how it's done in TeamCity:
If you migrate Visual Studio 2012 to 2013, then open *.csproj project file with edior.
and check 'Project' tag's ToolsVersion element.
Change its value from 4.0 to 12.0
From
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" ...
To
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" ...
Or If you build with msbuild then just specify VisualStudioVersion property
msbuild /p:VisualStudioVersion=12.0
Solution Source
It seems the new version of msbuild does not ship with Microsoft.WebApplication.targets. To fix you need to update your csproj file as so:
1) Edit the web app csproj (right click). Find the section in the csproj towards the bottom concerning build tools. It should look like so.
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
2) You need to add one VSToolsPath line below the VisualStudioVersion tag so it looks like so
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<!--Add the below line to fix the project loading in VS 2017 -->
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
<!--End -->
</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
Reference link:
https://alastaircrabtree.com/cannot-open-vs-2015-web-project-in-vs-2017/
This is all you need. Only 103MB. Don't install everything
I have found this on MS connect:
Yes, you need to install Visual Studio
2010 on your build machine to build
database projects. Doing so does
not require an additional license of
Visual Studio.
So, this is the only option that I have for now.
Anyone coming here for Visual Studio 2017. I had the similar issue and couldn't compile the project after update to 15.6.1.
I had to install MSBulild tools but still the error was there.
I was able to fix the issue by copying the v14.0 folder from C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio to the same folder as v15.0 and that resolved all the errors.
So now my folder structure looks like below, where both folders contain the same content.
If you are using MSBuild, as in the case of a build server, what worked for me is:
Change the following:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
to:
<Import Project="$(MSBuildBinPath)\Microsoft.VisualBasic.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
My Msbuild command is: *"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" solution.sln /p:Configuration=Debug /p:Platform="Any CPU"*
Hope this helps someone.
My solution is a mix of several answers here.
I checked the build server, and Windows7/NET4.0 SDK was already installed, so I did find the path:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets`
However, on this line:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />
$(MSBuildExtensionsPath) expands to C:\Program Files\MSBuild which does not have the path.
Therefore what I did was to create a symlink, using this command:
mklink /J "C:\Program Files\MSBuild\Microsoft\VisualStudio" "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio"
This way the $(MSBuildExtensionsPath) expands to a valid path, and no changes are needed in the app itself, only in the build server (perhaps one could create the symlink every build, to make sure this step is not lost and is "documented").
I fixed this by adding
/p:VCTargetsPath="C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\V120"
into
Build > Build a Visual Studio project or solution using MSBuild > Command Line Arguments
I tried a bunch of solutions, but in the end this answer worked for me: https://stackoverflow.com/a/19826448/431522
It basically entails calling MSBuild from the MSBuild directory, instead of the Visual Studio directory.
I also added the MSBuild directory to my path, to make the scripts easier to code.
I was having this issue building a SQL Server project on a CI/CD pipeline. In fact, I was having it locally as well, and I did not manage to solve it.
What worked for me was using an MSBuild SDK, capable of producing a SQL Server Data-Tier Application package (.dacpac) from a set of SQL scripts, which implies creating a new project. But I wanted to keep the SQL Server project, so that I could link it to the live database through SQL Server Object Explorer on Visual Studio. I took the following steps to have this up and running:
Kept my SQL Server project with the .sql database scripts.
Created a .NET Standard 2.0 class library project, making sure that the target framework was .NET Standard 2.0, as per the guidelines in the above link.
Set the contents of the .csproj as follows:
<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="MSBuild.Sdk.SqlProj/1.0.0">
<PropertyGroup>
<SqlServerVersion>Sql140</SqlServerVersion>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
</Project>
I have chosen Sql140 as the SQL Server version because I am using SQL Server 2019. Check this answer to find out the mapping to the version you are using.
Ignore the SQL Server project on build, so that it stops breaking locally (it does build on Visual Studio, but it fails on VS Code).
Now we just have to make sure the .sql files are inside the SDK project when it is built. I achieved that with a simple powershell routine on the CI/CD pipeline that would copy the files from the SQL Server project to the SDK project:
Copy-Item -Path "Path.To.The.Database.Project\dbo\Tables\*"
-Destination (New-item -Name "dbo\Tables" -Type Directory -Path "Path.To.The.DatabaseSDK.Project\")
PS: The files have to be physically in the SDK project, either in the root or on some folder, so links to the .sdk files in the SQL Server project won't work. In theory, it should be possible to copy these files with a pre-build condition, but for some obscure reason, this was not working for me. I tried also to have the .sql files on the SDK project and link them to the SQL Server project, but that would easily break the link with the SQL Server Object Explorer, so I decided to drop this as well.
In case if you're trying to deploy a project using VSTS, then issue might be connected with checking "Hosted Windows Container" option instead of "Hosted VS2017"(or 18, etc.):
I fixed this by running the build in a docker container, specifically dotnet/framework/sdk. It includes the VS build tools.
Creating a new project and copying over the settings should probably provide the best guidance in what to do. This is what it looks like on mine
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
In my case, It was just a Port-Block.
After installation of MSBuild tools from Microsoft, define the MSBuild path in the environment variable, so that it can be run from any path.
Edit the .csproj file in any notepad editor such as notepad++, and comment the
Check for the following elements,
-->
Make sure you use import only once, choose whichever works.
Make sure you have the following folder exists on the drive, "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0" or whichever version is referenced by MSBuild target at "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications\Microsoft.WebApplication.targets"
From the command prompt, run the following command, to check
C:>msbuild "C:\\DotnetCi.sln" /p:Configuration=Release /p:UseWPP_CopyWebApplication=true /p:PipelineDependsOnBuild=false
choose /p switch as appropriate, refer to enter link description here
enter image description here
I have a .NET MVC project that I'm trying to deploy using Jenkins.
I had been letting Jenkins run msbuild, then copying the resulting files out using RoboCopy. I wanted to switch to just use a publish profile. The publishing profile works fine on my local machine using Visual Studio, but on the Jenkins host it fails using msbuild.
The error it gives is
ASPNETCOMPILER : error ASPRUNTIME: Could not find a part of the path 'C:\Program Files (x86)\Jenkins\jobs\myProject\workspace\myProject\obj\Debug\AspnetCompileMerge\Source\bin\roslyn\csc.exe'. [C:\Program Files (x86)\Jenkins\jobs\myProject\workspace\myProject\calendar.csproj]
I'm using the Microsoft.Net.Compilers nuget package to pull in the C# compiler, because some of the collaborators on the project are still on Visual Studio 2013, but we're using C#6 language features in the project.
Thing is, the project built just fine using MSBuild on jenkins before I added the publish flag. It's only since adding the /p:DeployOnBuild=true;PublishProfile=MyProfile setting that it started failing... yet the publish step works fine from withing Visual Studio, and the roslyn compiler even gets copied to the obj\Debug\AspnetCompileMerge\Source\bin\ folder on my local machine. What gives?
Honestly, since msbuild14 is available on the Jenkins server, it probably doesn't even need the roslyn csc.exe file. Is there a way I can make msbuild ignore it?
My Publish Profile
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<LastUsedBuildConfiguration>Debug</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
<ExcludeApp_Data>False</ExcludeApp_Data>
<publishUrl>\\myserver\someshare\mysite</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
<PrecompileBeforePublish>True</PrecompileBeforePublish>
<EnableUpdateable>True</EnableUpdateable>
<DebugSymbols>False</DebugSymbols>
<WDPMergeOption>DonotMerge</WDPMergeOption>
</PropertyGroup>
</Project>
What I've Tried So Far
I've tried updating the compiler package.
Manually copying compiler
I added steps to my .csproj file to force-copy the missing compiler files to the AspnetCompileMerge directory (I'd already been copying them to the bin\roslyn directory to resolve another problem)
<Target Name="CopyRoslynFiles" AfterTargets="BeforeBuild">
<ItemGroup>
<RoslynFiles Include="$(SolutionDir)packages\Microsoft.Net.Compilers.1.1.1\tools\*" Exclude="$(SolutionDir)packages\Microsoft.Net.Compilers.1.1.1\tools\*.sys" />
</ItemGroup>
<MakeDir Directories="$(WebProjectOutputDir)\bin\roslyn" />
<MakeDir Directories="$(WebProjectOutputDir)\obj\$(Configuration)\AspnetCompileMerge\Source\bin\roslyn" />
<Copy SourceFiles="#(RoslynFiles)" DestinationFolder="$(WebProjectOutputDir)\bin\roslyn" SkipUnchangedFiles="true" Retries="$(CopyRetryCount)" RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)" />
<Copy SourceFiles="#(RoslynFiles)" DestinationFolder="$(WebProjectOutputDir)\obj\$(Configuration)\AspnetCompileMerge\Source\bin\roslyn" SkipUnchangedFiles="true" Retries="$(CopyRetryCount)" RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)" />
</Target>
Turning off Updateability in the publish profile
Based on Wesley Rathburn's answer on a similar question, I tried making the precompiled site so it could not be updated in the publish profile:
<EnableUpdateable>False</EnableUpdateable>
Though this revealed some dead code that needed removed in my views, it didn't fix the error during the jenkins build.
Running MsBuild locally
I can successfully run the msbuild command on my local machine. It deploys to the server and everything. Here's the command I run in powershell:
&"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" /p:Configuration=Debug "/p:DeployOnBuild=true;PublishProfile=MyProfile" myproject\myproject.csproj
Removing the statements that copy the compiler entirely
It occurred to me that maybe I didn't need the statements to copy the roslyn compiler to the bin folder anymore, since msbuild14 was available on Jenkins now (and I'm not sure it was when I first built the project). Sadly, same error occurs. It's looking for the roslyn\csc.exe file, even though there's no apparent need for it to do so!
Just putting this here, because I spent two days trying to resolve this same issue (roslyn csc.exe not copied), but none of these answers solved my problem.
It turns out that Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.6 (and 1.0.7) is broken. Downgrade to 1.0.5.
I was getting the same errors as everyone else here, but I'm using VS 2017, and both local WebDeploy as well as AzureDeploy were broken (no csc.exe found). I tried all the suggestions that I could find on the internet (most of them redirect back to this SO post) but nothing worked until I downgraded to 1.0.5.
So I hope this is helpful to anyone who is struggling and has just recently upgrade to 1.0.6!
See:
https://github.com/aspnet/RoslynCodeDomProvider/issues/13
and
https://github.com/dotnet/roslyn/issues/21340
So, the workaround I'm using for now (which I don't entirely like), is just to remove the dependencies on the Compilers and CodeDOM Compilers packages. I also had to clear out the references in the .csproj and web.config files. That involved removing those packages from a shared assembly as well.
This will break the project for people still using Visual Studio 2013, which I don't like, but it builds on my Jenkins host now, which I do like. If anyone has a better solution, I'd be happy to hear it.
So yeah, I have this problem too with VS2017 & VS2019 and Microsoft.CodeDom.Providers.DotNetCompilerPlatform2.0.1 too. Did a lot of troubleshoooting msbuild and digging deep and trying to do my own workarounds and the changes in build file that just did nothing, but that didn't seem right at all. So I started looking in a different direction.
What I discovered was I couldn't build a .csproj directly and have either the nuget targets in Microsoft.CodeDom.Providers.DotNetCompilerPlatform get run by msbuild, or my own custom ones.
However using msbuild with the .sln with a target of myproj:Rebuild made everything work.
I am building a project through the command line and not inside Visual Studio 2013. Note, I had upgraded my project from Visual Studio 2012 to 2013. The project builds fine inside the IDE. Also, I completely uninstalled VS2012 first, rebooted, and installed VS2013. The only version of Visual Studio that I have is 2013 Ultimate.
ValidateProjects:
39>path_to_project.csproj(245,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 <Import> declaration is correct, and that the file exists on disk.
39>Done Building Project "path_to_project.csproj" (Clean target(s)) -- FAILED.
Here are the two lines in question:
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
The original second line was v10.0, but I manually changed that to v12.0.
$(VSToolsPath) elongates from what I see to the v11.0 (VS2012) folder, which obviously is not there anymore. The path should have been to v12.0.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications\
I tried specifying VSToolsPath in my system environment variables table, but the external build utility still uses v11.0. I tried searching through the registry and that came up with nothing.
Sadly, I do not see any easy way to get the exact command line used. I use a build tool.
Thoughts?
I had the same issue and find an easier solution
It is due to Vs2012 adding the following to the csproj file:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
You can safely remove that part and your solution will build.
As Sielu pointed out you have to ensure that the .proj file begin
with <Project ToolsVersion="12" otherwise the next time you open the
project with visual studio 2010, it will add the removed node again.
Otherwise, if you need to use webdeploy or you use a build server, the above solution will not work but you can specify the VisualStudioVersion property in your build script:
msbuild myproject.csproj /p:VisualStudioVersion=12.0
or edit your build definition:
I had this too and you can fix it by setting the tools version in your build definition.
This is very easy to do. Open your build definition and go to the "Process" page. Then under the "3. Advanced" group you have a property called "MSBuild Arguments". Place the parameter there with the following syntax
/p:VisualStudioVersion=12.0
If you have more parameters, separate them with a space and not a comma.
This is closely related but may or may not fix OPs specific issue. In my case I was trying to automate the deployment of an Azure site using VS2013. Building and deploying via VS works, however, using MSBuild showed a similar error around the "targets". Turns out MSBuild is different under VS2013, and is now part of VS and not the .Net Framework (see http://timrayburn.net/blog/visual-studio-2013-and-msbuild/). Basically, use the correct version of MSBuild:
OLD, VS2012
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
NEW, VS2013
C:\Program Files (x86)\MSBuild\12.0\bin\msbuild.exe
Newer, VS2015
C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe
Newer still, VS2017 (not fully testing but discovered - they've moved things around a bit)
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\msbuild.exe
I just received a response from Kinook, who gave me a link:
Basically, I need to call the following prior to bulding. I guess Visual Studio 2013 does not automatically register the environment first, but 2012 did, or I did and forgot.
call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86
Hopefully, this post helps someone else.
giammin's solution is partially incorrect. You SHOULD NOT remove that entire PropertyGroup from your solution. If you do, MSBuild's "DeployTarget=Package" feature will stop working. This feature relies on the "VSToolsPath" being set.
<PropertyGroup>
<!-- VisualStudioVersion is incompatible with later versions of Visual Studio. Removing. -->
<!-- <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> -->
<!-- VSToolsPath is required by MSBuild for features like "DeployTarget=Package" -->
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
...
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
I had this problem for our FSharp targets (FSharpTargetsPath was empty).
Many of the paths are built with reference to the VS version.
For various reasons, our build runs with system privileges, and the environment variable "VisualStudioVersion" was only set (by the VS 2013 installer) at the "user" level - which is fair enough.
Ensure that the "VisualStudioVersion" environment variable is set to "12.0" at the level (System or User) that you are running at.
Running this in the commandline will fix the problem also.
SETX VisualStudioVersion "12.0"
If you migrate Visual Studio 2012 to 2013, then open *.csprorj project file with edior.
and check 'Project' tag's ToolsVersion element.
That's value 4.0
You make it to 12.0
From
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0"
To
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0"
Or If you build with msbuild then just specify VisualStudioVersion property
msbuild /p:VisualStudioVersion=12.0
I was using an external build utility. Think of something like Ants, if I understand the product correctly, just a commercial version. I had to contact the manufacturer for the answer.
As it turns out, there is a global macro in the project, DEVSTUDIO_NET_DIR. I had to change the path to .Net there. They list various visual studio versions as "Actions", which through me off, but all roads lead back to that one global variable behind the scenes. I would list that as a defect against the product, if I had my way, unless I am missing something in my understanding. Correcting the path there fixed the build problem.
I have Visual Studio 2013 installed. This worked for me:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' != ''">12.0</VisualStudioVersion>`
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
So I've changed the condition from == to != and the value from 10.0 to 12.0.
I had similar issue. All proposed solutions are just work around for this issue but are not solving source of error. #giammin solution should not be applied if you are using tfs build server as it is just crashed publish functionality. #cat5dev solution - solves issue but do not solve source of it.
I`m almost sure that you are using build process template for VS2012 like
ReleaseDefaultTemplate.11.1.xaml or DefaultTemplate.11.1.xaml
these build templates have been made for VS2012 and $(VisualStudioVersion) set to 11.0
You should use build process template for VS2013
ReleaseTfvcTemplate.12.xaml or TfvcTemplate.12.xaml which has $(VisualStudioVersion) set to 12.0
This works without any changes in project file.
I also had the same error .. I did this to fix it
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" />
change to
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
and it's done.
In my case i just comment below line by opening .csproj file and did the trick
.<!-- <Import Project="..\PRPJECTNAME.targets" /> -->
My problem may be different but i am dragged here, but this may help someone.
I picked a single web project from my solution and try to open it as a stand alone project which was making issue, after above heck am able to solve issue.
Use the correct version of MSBuild. Set Environment Variable to:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin
This will also work for VS 2019 projects
Previously we were setting it to C:\Windows\Microsoft.NET\Framework\v4.0.30319
In my case dev environment is VS2013 and I am using TFS 2010. Build was targeted for .NET 4.5.1. I was setting up auto build for CI. whenever I tried workarounds mentioned above - like removing properties group completely or replacing some lines etc.my build used to happen in TFS but my publish to azure used to fail with 'MSDeploy' or at times some different error.
I was not able to achieve both simultaneously.
So finally I had to pass MSBuild argument to resolve the issue.
Goto Edit build definition > Process > 3. Advanced > MSBuild Arguments (set to) /p:VisualStudioVersion=12.0
It worked for me.
You should copy folder WebApplications
from C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\
to C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\
you will find
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets
in csproj file for which this error is appearing.
Just remove this from csproj and then build.
Only one thing needs to be done to solve the problem: upgrade TeamCity to version 8.1.x or higher because support for Visual Studio 2012/2013 and MSBuild Tools 2013 was only introduced in TeamCity 8.1. Once you've upgraded your TeamCity modify MSBuild Tools Version setting in your build step accordingly ans the problem will disappear. For more info read here: http://blog.turlov.com/2014/07/upgrade-teamcity-to-enable-support-for.html
Me - nothing was helping in changing the v11.0 value of VisualStudioVersion variable to v10.0. Changing variable in .csproj file didn't. Setting it through command promt didn't. Etc...
Ended up copying my local folder of that specific version (v11.0) to my build server.
I had tried all of the above solutions and still no luck. I had heard people installing visual studio on their build servers to fix it, but I only had 5gb of free spaces so I just copied C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio to my build server and called it a day. Started working after that, using team city 9.x and visual studio 2013.
Based on TFS 2015 Build Server
If you counter this error ... Error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Open the .csproj file of the project named in the error message and comment out the section below
<!-- <PropertyGroup> -->
<!-- <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> -->
<!-- <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath> -->
<!-- </PropertyGroup> -->
I got this error when I install some VS components. Unfortunately none of these answers didn't help me. I use TFS for command development and I have no permissions to edit build definition. I solved this problem by deleting environment variables which called VS110COMNTOOLS and VS120COMNTOOLS. I think it was installed with my VS components.
I found I was missing the WebApplications folder on my local PC, did not install with Visual Studio 2017 like it had when I was using 2012.
In my case I was using the wrong version of MSBuild.exe.
The version you need to use depends on what version of Visual Studio you used to create your project. In my case I needed 14.0 (having used Visual Studio 2015).
This was found at:
C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe
You can look under:
C:\Program Files (x86)\MSBuild
To find other versions.
I'm totally stumped by this one. The ideas that I've found through google stack overflow don't work for me and I've no idea why.
We recently upgraded the project to Visual Studio 2012 and MVC 4 with .NET 4.5 and now it won't publish properly.
We have another branch that just has the project publishing in Visual Studio 2012 without the upgrade to MVC4 or .NET4.5 and that seems to work, so I'm guessing it isn't a Visual Studio issue. Just something with the way that MVC 4 is set up in our project. MVC 3 was added by referencing the DLLs directly from a lib folder we had created in the source control (but outside of any projects). MVC 4 is added via NuGet.
The issue is that System.Web.Helpers (amongst others) don't appear in the bin directory of the published application. This means that when it is put on the test server it won't run as the DLL is missing.
I've set Copy Local to be TRUE (actually, it already was, but I turned if off and on again). I also read somewhere that if the file exists in the GAC it won't matter what this setting is, it won't copy. However, I've checked and it isn't in the GAC.
I've ensured that the reference in the MVC application was pointing to the version of the file in the NuGet packages folder. (It wasn't originally, but I've manually edited the csproj file to do that as removing and readding the NuGet package didn't help)
I've added a post-build event to copy the relevant files (which doesn't affect the publish, although they are in the project's bin directory)
I've attempted to put a _bin_deployableAssemblies folder in place, as per Phil Haack's blog, but it seems this doesn't work in Visual Studio 2012.
I've tried modifying the csproj file (which is just an MSBuild file) to copy the relevant files for me, as per this SO answer. But for what ever reason that doesn't want to work either.
I've run out of things I can try. Well, I can always copy the file manually as some SO answers have suggested elsewhere, but that defeats the purpose.
Any ideas?
UPDATE
Added more things in the bullet points above for things I've tried that don't work for me.
How about this:
Right-click on the MVC project in solution explorer.
Add Deployable Dependencies
Tick MVC
I've found an answer. It is a bit of a hack because I couldn't get the MSBuild copy command to work, so I used the Exec command to get xcopy to do the copying for me.
First of all I added a folder called _bin_PublishAssemblies to the project and put in there the assemblies that I need to publish that the build process is not picking up already.
Then I added the following towards the end of the csproj file:
<Target Name="AfterBuild">
<Message Text="Build | Copying assemblies to output folder ($(OutputPath))" Importance="high" />
<Exec Command="ECHO Going to copy from '$(ProjectDir)\_bin_PublishAssemblies'" />
<Exec Command="xcopy $(ProjectDir)\_bin_PublishAssemblies\* $(OutputPath) /Y" />
</Target>
<Target Name="CopyBinFiles" AfterTargets="CopyAllFilesToSingleFolderForPackage" BeforeTargets="MSDeployPublish">
<Message Text="Deploy | Copying assemblies to output folder ($(_PackageTempDir)\bin\)" Importance="high" />
<Exec Command="ECHO Going to copy from '$(ProjectDir)\_bin_PublishAssemblies'" />
<Exec Command="xcopy $(ProjectDir)\_bin_PublishAssemblies\* $(_PackageTempDir)\bin\ /Y" />
</Target>