Related
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
After upgrading my WinForms VS2013 project to VS2015, I started seeing the MSB3884 "Could not find rule set file" warning.
A Google search turned up one MSDN article, which a Stack Overflow article points to as well as numerous other sites.
Similar Question: 33020507
MSDN: VS2015 MSB3884 Warning
I have both VS2013 and VS2015 installed.
The project files giving the warnings (and those that do not), do not have these entries.
<CodeAnalysisRuleSetDirectories>
<CodeAnalysisRuleDirectories>
If I delete the other two entries from the project file, then the problem goes away, which is obvious, as there is no rule file set.
<CodeAnalysisIgnoreBuiltInRuleSets>
<CodeAnalysisIgnoreBuiltInRules>
I am trying to build externally using msbuild, however VS2015 tends to show the problem too.
Interestingly enough, if I click on the open button in the project properties Code Analyzer area, I do get the file.
Specifying a different rule set makes no difference. That makes me think that possibly, there is an environment variable setting, not that any come to mind. Code Analyzers is a function of the project file. I can add a directory attribute, but the consensus is to take out paths, the <CodeAnalysisRule*Directories>.
The GUI uses defaults:
'
Here is a typical project file fragment.
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x86'">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x86\Debug\</OutputPath>
<DefineConstants>TRACE;DEBUG</DefineConstants>
<DebugType>full</DebugType>
<PlatformTarget>x86</PlatformTarget>
<CodeAnalysisIgnoreBuiltInRuleSets>true</CodeAnalysisIgnoreBuiltInRuleSets>
<CodeAnalysisIgnoreBuiltInRules>false</CodeAnalysisIgnoreBuiltInRules>
<Prefer32Bit>false</Prefer32Bit>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<CodeAnalysisRuleSet>BasicCorrectnessRules.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x64'">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x64\Debug\</OutputPath>
<DefineConstants>TRACE;DEBUG</DefineConstants>
<DebugType>full</DebugType>
<PlatformTarget>x64</PlatformTarget>
<CodeAnalysisRuleSet>MinimumRecommendedRules.ruleset</CodeAnalysisRuleSet>
<CodeAnalysisIgnoreBuiltInRules>false</CodeAnalysisIgnoreBuiltInRules>
</PropertyGroup>
Without getting rid of the Code Analysis lines from the project file, though saving a project file again would just add it back, how can I eliminate/fix the warning?
I've just had the same problem after upgrading from VS2013 to VS2015.
My solution was:
On the project properties go to the Code Analysis section.
Select the Browse option on the list of rule sets.
Browse to the VS2015 rule sets folder. C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\Rule Sets
Pick a rule set. The default used by new projects is: MinimumRecommendedRules.ruleset
Rebuild. Check the warning has gone.
I hit this warning after migrating from VS 2013 to VS 2015 as well. In my case the error was Could not find rule set file "AllRules.ruleset". The fix for me was to change the VisualStudioVersion setting in the .csproj file to be 14.0 so that it looks in the correct rule set folder:
After that and a rebuild, the warning was resolved. Much easier.
I spent some time looking at the different solutions proposed here - they each had good elements but each required some adjustments. I found a clean solution to be:
Locate an existing or create a <PropertyGroup> element in the project file that has NO conditions (e.g configuration or platform) i.e that will apply to all configurations on all platforms. To this element add a <CodeAnalysisRuleSetDirectories> element specifying the relative path to the "Rule Set" directory from the current dev env directory, e.g:
<PropertyGroup>
<CodeAnalysisRuleSetDirectories>$(DevEnvDir)\..\..\Team Tools\Static Analysis Tools\Rule Sets</CodeAnalysisRuleSetDirectories>
</PropertyGroup>
I got rid of this warning by setting <CodeAnalysisIgnoreBuiltInRuleSets>false</CodeAnalysisIgnoreBuiltInRuleSets>
You said your project files giving off the warnings did not contain any <CodeAnalysisRuleSetDirectories> entry.
Mine did not either, and like you I get the file if I click the Open button in the project properties Code Analysis section.
However, searching all project files in the solution turned up two projects which did have <CodeAnalysisRuleSetDirectories> tags, and those tags contained an older version of the Visual Studio reference in the path.
Fixing those paths fixed my problem, and I've just confirmed that the project which was raising the error references a project which referenced the projects which contained the bad <CodeAnalysisRuleSetDirectories> entries.
So search the whole solution and fix all <CodeAnalysisRuleSetDirectories> paths, or try removing them.
In my case
<CodeAnalysisRuleSetDirectories>;C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\\Rule Sets</CodeAnalysisRuleSetDirectories>
became
<CodeAnalysisRuleSetDirectories>;C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\\Rule Sets</CodeAnalysisRuleSetDirectories>
(Jon Shadforth's answer also worked for me, but I didn't like adding the path to more projects - as timB33 commented)
These binary analyzers are now deprecated link.
I am using VS 2019 and my solution was to edit the projects files and remove all lines related to the CodeAnalysis, in all PropertyGroups:
Before:
After:
*To edit the .vbproj or .csproj in Visual Studio you need to unload the project.
-Perform a right-click in solution and then unload the project.
-Perform a right-click again and go to edit 'fileName'
I didn't try but this solution must work in VS 2015, VS 2017 too.
Had this when compiling a solution upgraded from VS2015 to VS2017 but had MSBuild 14 in the path (C:\Program Files (x86)\MSBuild\14.0\Bin). Changed to ensure 15 was in the path (C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin) and all worked.
I had this error on my build server which has Visual Studio Build Tools on it rather than Visual Studio.
The solution for me was to use the installer to enable Static analysis tools in the individual components list.
For people who are not using Visual Studio but for example Rider or a other IDE:
I had an older version of the compiler installed. So the Ruleset-Files did not exist.
The solution for me was to install the curren Visual Studio Build Tools from:
https://visualstudio.microsoft.com/de/downloads/
In my case 'Buildtools für Visual Studio 2022' - here you need to select the C# Options.
After installation the following folder should exist:
C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\Team Tools\Static Analysis Tools\Rule Sets
There the AllRules.ruleset and MinimumRecommendedRules.ruleset is located and should be used if you use the C# Compiler from the build tools.
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 have 2 c# test projects in my VS2012 Update 1 solution, one shows a class library icon, one shows a test project icon. They both work as test project, but the discrepancy is driving me crazy. (short drive). Anybody know how to fix this? I've looked at the .csproj and the .sln files, but nothing is leaping out at me.
Right-click the project in Solution Explorer and choose Edit Project File
Add a new child in the <PropertyGroup> node:
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
Save your changes and close the file
Right-click the project in Solution Explorer and choose Reload Project
https://adamprescott.net/2012/03/29/convert-a-class-library-to-a-test-project-in-visual-studio/
If your project is on a new-style .csproj file (less verbose, says like <Project Sdk="Microsoft.NET.Sdk"> as the top line, supports globbing etc), then you can get a test tube icon for your project by either adding Microsoft.NET.Test.Sdk NuGet package to your project, or adding this line to your .csproj file (which amounts to the same thing):
<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.6.1" />
</ItemGroup>
(Version number correct at the time of writing - check for what the latest is.)
Pawel's answer is right, but it was truncated by the html parser... Mentioned child node should look like:
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
This line could be also directly added to the csproj file (to the main PropertyGroup).
This isn't really a solution, but it seems to be a bug in Visual Studio.
See Microsoft Connect issues here, here and here which you can follow.
There is also a similar question here.
UPDATE:
This seems to be resolved in Visual Studio 2013 preview.
Open up Solution Explorer, right-click, go to properties and under 'Application' there is a drop-down menu called 'Output Type' and change that from Class Library to whatever you want it (most likely an Application).
When I build my c# solution the .tt files will not create the .cs file outputs. But if I right click the .tt files one at a time in solution explorer and select "Run Custom Tool" the .cs is generated, so the build tool setting is correct. What do I do to get the overall solution build to force the custom tool to run on the .tt files?
Paul, you can also generate code at build time with TextTransform.exe or Elton Stoneman's MSBuild task. Just keep in mind that behavior of the built-in directives, like assembly and include is different when T4 runs in Visual Studio vs. the command-line host.
Answering my own question, they are supposed to be generated at design time as per this discussion:
https://web.archive.org/web/20081227142303/http://www.olegsych.com/2008/02/t4-template-directive/
In Visual Studio 2017 (probably next versions too), you should add this in Pre-build event:
"$(DevEnvDir)TextTransform.exe" -out "$(ProjectDir)YourTemplate.cs" "$(ProjectDir)YourTemplate.tt"
p.s. The only solution that worked for me.
p.s.s. Change path to your template if it's located not in root project directory.
In Visual Studio 2013, I was able to get the .tt files to regenerate their targets by just adding these lines to the .csproj file:
<PropertyGroup>
<!-- Get the Visual Studio version – defaults to 10: -->
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<!-- Keep the next element all on one line: -->
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
<!-- To enable build tasks on your development computer, install Modeling SDK for Visual Studio. https://www.microsoft.com/en-us/download/details.aspx?id=40754 -->
<Import Project="$(VSToolsPath)\TextTemplating\Microsoft.TextTemplating.targets" />
<!-- Run the Transform task at the start of every build -->
<PropertyGroup>
<TransformOnBuild>true</TransformOnBuild>
</PropertyGroup>
<!-- Overwrite files that are read-only, for example because they are not checked out -->
<PropertyGroup>
<OverwriteReadOnlyOutputFiles>true</OverwriteReadOnlyOutputFiles>
</PropertyGroup>
<!-- Transform every template every time -->
<PropertyGroup>
<TransformOutOfDateOnly>false</TransformOutOfDateOnly>
</PropertyGroup>
However, for this to work, you'll need to have installed the Modeling SDK for Visual Studio. I found all of this information, along with a more complete description of the options available, on this page: Code Generation in a Build Process.