Folks I've a set of services first created in 2012, which - down the years - have seamlessly built with Vs2010, Vs2013 & Vs2015.
When I try to build with Vs2017 I get
The MSBuild.Community.Tasks.Attrib task could not be loaded from the assembly
The assembly lives under the C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\MSBuildCommunityTasks folder, however there is no MSBuildCommunityTasks folder under the \2017\Professional\MSBuild folder.
Here's the full error
C:\working\MySolution\build\Build.proj" (default target) (1) ->
(SetAssemblyVersion target) ->
C:\working\MySolution\build\Build.proj(100,5): error MSB4062: The "MSBuild.Community.Tasks.Attrib" task could not be loaded from the assembly C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\MSBuildCommunityTasks\MSBuild.Community.Tasks.dll.
Could not load file or assembly 'file:///C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\MSBuildCommunityTasks\MSBuild.Community.Tasks.dll' or one of its dependencies.
The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
What changed between Vs2015 and Vs2017?
What do I need to do to fix this?
Explicitly setting the MSBuildCommunityTasksPath property gets past the problem.
I do this at the top of my build.proj file.
(For historic reasons we keep the community build tasks in our repo, which is why it's set to a location under trunk)
<MSBuildCommunityTasksPath>$(trunk)\Ref\Build\MSBuildCommunityTasks</MSBuildCommunityTasksPath>
The extensions are most likely installed in 'C:\Program Files (x86)\MSBuild'. So I currently set the variable explicitly in my proj as a workaround.
<MSBuildExtensionsPath>C:\Program Files (x86)\MSBuild</MSBuildExtensionsPath>
Installing .Net Framework 3.5 development tools in VS2017 individual components section fixed my build.
Related
I am setting up a new TeamCity build agent. Several build configurations that run perfectly well on the existing agent are failing on the new agent, with errors like this (whitespace added for clarity):
[22:14:32][someproject.vbproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\bin\Microsoft.VisualBasic.CurrentVersion.targets(322, 5):
error MSB4019: The imported project
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\bin\Roslyn\Microsoft.VisualBasic.Core.targets"
was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Note the path on line three after "The imported project". The error is correct; the folder does exist but the file does not exist there. However the Microsoft.VisualBasic.Core.targets file does exist at a slightly different path
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\Roslyn\Microsoft.VisualBasic.Core.targets
Is there an easy fix for this, perhaps a registry entry telling MSBuild where to look?
Cause
On your machine, there are two copies of VS 2017 installed, Professional edition and the raw Build Tools.
You didn't install VB bits for Professional, while did that for Build Tools.
TeamCity prefers MSBuild from Professional edition.
Combine all above, the issue happened.
Fix
You should either force TeamCity to use MSBuild from Build Tools, or add VB to your VS Pro installation.
Reference
https://blog.lextudio.com/the-rough-history-of-msbuild-cc72a217fa98
I am using VS2017, MSBuild version 15.0. I have been installing taichi(https://github.com/yuanming-hu/taichi) .I have been facing lots of errors and trying to solve each step by step and now I am stuck with the following error. I have MSbuid 15.0 but it is looking for version 4.0 .
Build FAILED.
"C:\Users\5000\Documents\spgrid_topo_opt-master\taichi-master\build\taichi.sln" (default target) (1) ->
"C:\Users\5000\Documents\spgrid_topo_opt-master\taichi-master\build\ZERO_CHECK.vcxproj" (default target) (2) ->
(SetTelemetryEnvironmentVariables target) ->
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets\Microsoft.Cpp.DesignTi
me.targets(491,5): error MSB4062: The "SetEnv" task could not be loaded from the assembly C:\Program Files (x86)
\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets\Microsoft.Build.CppTasks.Common.dll. Could not
load file or assembly 'Microsoft.Build.Utilities.Core, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f
7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask>
declaration is correct, that the assembly and all its dependencies are available, and that the task contains a p
ublic class that implements Microsoft.Build.Framework.ITask. [C:\Users\5000\Documents\spgrid_topo_opt-master\tai
chi-master\build\ZERO_CHECK.vcxproj]
0 Warning(s)
1 Error(s)
1.Please open Developer Command Prompt for VS2017(come with build tools) and type the build command like: msbuild ZERO_CHECK.vcxproj
2.Check if it makes any difference,if same issue persists open vs installer and update the build tools to latest version. Then build the C++ project to check if it helps
I configured the similar environment like yours. And use the SetEnv task in .vcxproj file. But all works well when building the project.
So if all above can't work to resolve the issue: There is possibility that you call msbuild programmatically in code. If so, maybe you can get some help from this issue:
Try binding redirection, thanks to Nicolas.
Also, you can check this thread.
Any update feel free to contact me:)
Edit your PATH environment variable to ensure the first path to a directory containing msbuild.exe is the one included with Visual Studio 2017. This may be one of the following paths, depending on the edition you have and whether you installed it to the default location.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\
How do I target MSBuild 15.0 on my server? I have 15.0 installed on the server but my project is still building with 14.0. I know that Microsoft has made some changes to the directory locations and no longer uses the registry values with 15.0.
I found 15.0 installed in the following locations:
C:\Program Files (x86)\MSBuild\15.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild
And I have the .Net framework 4.6.2 installed here:
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319"
Thanks!
Product: BuildMaster
Version: 5.7.2
Update 1:
Responding to #emiel-koning, I tried to specify $MSBuildToolsPath in the build step using:
set $MSBuildToolsPath = C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin;
But I get this error:
error MSB4226: The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\WebApplications\Microsoft.WebApplication.targets" was not found. Also, tried to find "WebApplications\Microsoft.WebApplication.targets" in the fallback search path(s) for $(VSToolsPath) - "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v15.0" . These search paths are defined in "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\msbuild.exe.Config". Confirm that the path in the declaration is correct, and that the file exists on disk in one of the search paths.
Update 2:
Could I be missing something installed on my build server? I installed Visual Studio Build Tools which gave me the MSBuild 15.0 but not the WebApplication.targets file from the error above
SOLUTION
I fix my issues by also installing "Web development build tools" component. I also set the $MSBuildToolsPath at the server level until I can roll out the new MSBuild globally.
In general, this is handled by the ToolsVersion attribute of the project file. This should be what is used if the below configuration is not specified.
In BuildMaster specifically, you can override this value per-server on the Administration > BuildMaster Extensions > Windows SDK > Configuration tab. Click on $MSBuildToolsPath (and optionally override at a specific scope) with a value of C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin
Response to Updates #1 & #2:
First, don't set that variable in the plan itself (otherwise you'd have to set it in every plan). Set it in the manner I described above. Personally, I always specify its value at the server level since each server may have it installed in a different location.
As for Microsoft.WebApplication.targets, I think the only supported method of building web application projects is to have Visual Studio installed on the build server; though in the past I've just copied the targets from my local installation (C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications) into the path that MSBuild is expecting them to be.
Can you use $MSBuildToolsPath to specify the correct path to MSBuild?
I try to integrate StyleCop in a Visual Studio solution. Installing StyleCop on each machine of each developer is something I would prefer to avoid. The suggestion I've seen several times (example) is to include the binaries of StyleCop within the project, storing them in version control.
I did that. It works on my machine, but fails on a different machine where StyleCop is not installed. After uninstalling StyleCop on my machine, it doesn't work there either.
The error message is the following:
Severity Code Description Project File Line
Error The "StyleCopTask" task could not be loaded from the assembly C:\Program Files (x86)\MSBuild..\StyleCop 4.7\StyleCop.dll. Could not load file or assembly 'file:///C:\Program Files (x86)\StyleCop 4.7\StyleCop.dll' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. Demo
This is what I included in every .csproj file:
<Import Project="$(SolutionDir)\externs\Microsoft.StyleCop\StyleCop.targets" />
The directory C:\demo\externs\Microsoft.StyleCop contains:
The copy of all the files from C:\Program Files (x86)\StyleCop 4.7,
The copy of C:\Program Files (x86)\MSBuild\StyleCop\v4.7\StyleCop.Targets.
What's wrong?
It appears that StyleCop.Targets contains an absolute path:
<UsingTask
AssemblyFile="$(MSBuildExtensionsPath)\..\StyleCop 4.7\StyleCop.dll"
TaskName="StyleCopTask"/>
In order to be able to use StyleCop on machines where the application is not installed, change this path to something similar to:
<UsingTask
AssemblyFile="$(SolutionDir)\externs\Microsoft.StyleCop\StyleCop.dll"
TaskName="StyleCopTask"/>
I have a old solution which worked fine with VS 2012 and now I migrate it to VS 2013.
When I try to build a configuration which involve web.config replacement i got this error:
Error 1 The "TransformXml" task could not be loaded from the assembly C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll. Could not load file or assembly 'file:///C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
What it mean is that there no build tools in my v11.0 which is right. Because I use Visual Studio 2013. (the build tool are in a folder called v12.0) One option is to just copy my build tool to the right place but im searching for a real solution.
I found in my .csproj file these config:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
But im not really understand why it then v11.0 could be. I have tried multiple things to change these like set VisualStudioVersion explicit but it changed nothing.
So my question: where the heck come these path from and where can I configure it?
Since vs2012 MS tries to keep sln file untouched if there is no reason to upgrade it (to allow opening sln in the old VS).
If you’ve upgrade from vs2012 to vs2013 there can be chance you are opening solution in vs2012 (it happen to me in many updated solutions).
Try to check beginning of the sln file
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2013
or:
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2012
If you wish to change it by VS, open sln in vs2013 and then select solution root node in solution explorer and the File > Save .sln (Ctrl+S)