I'm trying to build a docker image to setup CI/CD for a project of my organization.
The project is mostly Windows C++ (MFC), but has some components in C#.
Storically the projects were all managed by hand but I'm in the process of migrating to CMake and automate the build process.
Locally everything works fine but when building on the CI/CD server, CMake says that No CMAKE_CSharp_COMPILER could be found.
The docker image I'm building is based on mcr.microsoft.com/windows/servercore:ltsc2019 and I installed, using the Visual Studio Build Tools installer, the following workloads:
Microsoft.VisualStudio.Workload.MSBuildTools
Microsoft.VisualStudio.Workload.ManagedDesktopBuildTools
Microsoft.VisualStudio.Workload.VCTools
Microsoft.VisualStudio.Component.Windows10SDK.17763
I can provide the full Dockerfile if necessary.
Anyway, testing the built image I can find both msbuild and csc compilers, CMake can't.
Any idea on what could be the problem?
Looks like I was missing a Visual Studio component, specifically Microsoft.Net.Component.4.TargetingPack.
To detect the correct C# compiler, CMake compiles a little source code. This compilation targets .NET Framework v4, which I was missing.
Whenever I try to build any documentation using docfx, I get the following error in the metadata build step that uses msbuild to analyze the xml comments in the code of the csprojs:
Warning:MetadataCommand.ExtractMetadataWorkspace failed with: [Failure] Msbuild failed when processing the file 'C:\temp\docfxtest\docfx_project\src\src.csproj' with message: Could not load SDK Resolver. A manifest file exists, but the path to the SDK Resolver DLL file could not be found. Manifest file path 'C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\SdkResolvers\Microsoft.Build.NuGetSdkResolver\Microsoft.Build.NuGetSdkResolver.xml'. SDK resolver path: C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\CommonExtensions\Microsoft\NuGet\Microsoft.Build.NuGetSdkResolver.dll C:\temp\docfxtest\docfx_project\src\src.csproj
It seems that msbuild cannot be correctly resolved by docfx. Any idea how I could fix this?
Im using docfx version 2.56.5.0 on Windows and I also have VS Enterprise 2019 (16.8.2) and VS Build Tools 2017 (15.9.29) installed:
UPDATE:
I have now uninstalled the VS 2017 build tools completely and repaired the VS 2019 installation using the installer. I now get a different error when I run docfx. It seems that it can't find msbuild at all anymore.
Warning:MetadataCommand.ExtractMetadataWorkspace failed with: [Failure] Msbuild failed when processing the file 'C:\temp\docfxtest\docfx_project\src\src.csproj' with message: The SDK 'Microsoft.NET.Sdk' specified could not be found. C:\temp\docfxtest\docfx_project\src\src.csproj
Running msbuild -t:restore,build also shows that it can't find msbuild
'msbuild' is not recognized as an internal or external command
The targets are isntalled:
And so is the .NET Core workload:
Your Build Tool for VS2017 might have some problems due to some issues. The most issue is this:
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\CommonExtensions\Microsoft\NuGet\Microsoft.Build.NuGetSdkResolver.dll
Either you lost the dll or the dll is damaged.
Update
1) First, you should check whether you have installed NuGet targets and build tasks workload and net core build tools workload. If not, please install it.
2) Second, please delete bin and obj folder of your project and then try again.
You should use msbuild -t:restore,build to build your project.
3) Third, try to Repair from vs_installer for your build tool. It will repair the related dll. And then delete bin and obj folder, use build tool to test your project again.
Important:
VS2017 does not support net core 3.1. You should note that. It supports <=net core 2.1.
So if you still want to use Build Tool of VS2017 for your net core project, you should try the the above three steps and then target your project to net core 2.1.
Besides, if you start msbuild by CMD, I think you should check your environment variable PATH and check whether you have configured the msbuild.exe from Build Tool of VS2017 on it. Instead, you could add C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\MSBuild.exe. This way is for VS2019.
=================================================
Update 1
The problem is that you have already installed a docfx tool by choco command line.
At the beginning, I always thought that you used docfx.console nuget package on your project and just invoke docfx.exe from C:\Users\xxx\.nuget\packages\docfx.console\2.56.5\tools\docfx.exe under command line.
Regardless of the installation of docfx.console package on your project, if you installed docfx tool by choco command and then just invoke docfx.exe on command line, it used the local docfx.exe under C:\ProgramData\chocolatey\lib\docfx\tools\docfx.exe rather than the nuget package.
So the issue is that your local docfx.exe has some errors due to some issues. You should reinstall the docfx.exe by choco command choco uninstall docfx; choco install docfx.
Actually, directly use docfx.console nuget package on your project might be easier. From this link.
It already contains the generation step of the documentation by docfx.exe(from C:\Users\xxx\.nuget\packages\docfx.console\2.56.5\tools\docfx.exe) and will execute it automatically rather than run docfx.exe again manually.
I have completely uninstalled docfx using chocolatey (choco uninstall docfx) removed every folder named docfxfrom c:\ProgramData\chocolatey\.chocolatey\ and then reinstalled it (choco install docfx). After that, everything worked fine again. The file c:\ProgramData\chocolatey\lib\docfx\tools\docfx.exe.config contains a lot of msbuild related configuration. Maybe something was messed up there.
I'm trying to build a solution using msbuild command line and I keep getting this error:
error MSB4236: The SDK 'Microsoft.NET.Sdk' specified could not be found.
The version of msbuild is the latest from microsoft visual studio 2017 tools. I'm using Windows Server 2012 R2 and the project uses .NET Core 2.0.
This is the command that I'm using:
msbuild.exe /p:Configuration=Release /t:restore C:\Projects\MyProject.sln
Complete log:
Microsoft (R) Build Engine version 15.3.409.57025 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
Build started 9/16/2017 3:09:03 PM.
Project "C:\Projects\MyProject.sln" on node 1 (restore target(s)).
ValidateSolutionConfiguration:
Building solution configuration "Release|Any CPU".
Project "C:\Projects\MyProject.sln" (1) is building "C:\Projects\Kernel\Kernel.csproj" (2) on node 1 (restore target(s)).
C:\Projects\MyProject.sln" (1) is building "C:\Projects\Kernel\Kernel.csproj : error MSB4236: The SDK 'Microsoft.NET.Sdk' specified could not be found.
Done Building Project "C:\Projects\MyProject.sln" (1) is building "C:\Projects\Kernel\Kernel.csproj" (restore target(s)) -- FAILED.
Build FAILED.
"C:\Projects\MyProject.sln" (restore target) (1) ->
"C:\Projects\Kernel\Kernel.csproj" (restore target) (2) ->
C:\Projects\Kernel\Kernel.csproj : error MSB4236: The SDK 'Microsoft.NET.Sdk' specified could not be found.
0 Warning(s)
11 Error(s)
I encountered this error after playing around with .Net Core 2.0 installation and seemingly messing it up. I would get this same error for dotnet restore, dotnet build or dotnet msbuild. Essentially, anything involving .Net Core and msbuild.
The error occurred because the MSBuildSDKsPath environment variable was still pointing to the old .Net Core 1.1 SDK.
To fix the problem, I manually set the MSBuildSDKsPath environment variable to point to 2.0.0's SDK path, which, for me with x64, this was at: C:\Program Files\dotnet\sdk\2.0.0\Sdks.
Basically, if you have Sdk="Microsoft.NET.Sdk" in your .csproj, then a folder with the same name should exist at your MSBuildSDKsPath location.
You were probably missing some components when you installed the VS tools
Download and run Build Tools for Visual Studio 2019. (On the VS download page, go to Tools for Visual Studio 2019 and then click download Build Tools for Visual Studio 2019)
Select Modify on Visual Studio Build Tools 2019 or your instance.
Select tab Individual components and check .NET Core SDK component
for me the solution was to set the sdk version in the global.json file:
and specify the correct version which exists in the C:\Program Files\dotnet\sdk folder. The VS installer uninstalled the previous version of .NET Core 3.0.100 and installed new one 3.1.100 so I had to change it from:
{ "sdk": { "version": "3.0.100" }}
to
{ "sdk": { "version": "3.1.100" }}
For me updating Visual Studio Build Tools resulted in the 'SDK not found' error.
The solution: run Visual Studio Installer, modify the Visual Studio (Build Tools) installation, and make sure the following workload is selected:
I got this issue in Mac OS and while using docker container and Azure this occurs because docker bash overrides MSBuildSDKsPath so don't
change any code just quit and restart your IDE (visual studio Mac) and run it again
I got the same issue when I tried to install x64 .Net Core SDK installer. Even the following dotnet --info command shows me that no SDK is found.
So, try to install x86 .Net Core SDK installer. That can help you.
I had the same problem and found solution here:
https://github.com/aspnet/AspNetCore/issues/3624
Solution is to just have x64 or x86 version of sdk/runtime/hosting.
If you have both and if you use for example x86 version of dotnet.exe it won't see x64 versions of SDK installed.
Problem usually occures when you install hosting bundle because it includes both x86 and x64. Just uninstall one you don't use.
To anyone that, like me, run into this issue on Linux and found this thread:
This problem occurs, because your .bashrc config overrides MSBuildSDKsPath environment variable with outdated value (most likely it's a leftover after dotnet package update). To solve this:
Edit ~/.bashrc
Remove the line with MSBuildSDKsPath variable initialization, e.g.
export MSBuildSDKsPath="/opt/dotnet/sdk/2.2.108/Sdks/"
If you have previously worked with C# and it somehow stopped working:
For me updating to the latest version (probably of the build tools) with the "Visual Studio Installer" solved the problem.
I started getting this error after installing Visual Studio 2022 in Windows 10, when I opened up my solution. The solution contains a mix of .NET Framework 4.8 and .NET Standard 2.0 projects, and the error was on the .NET Standard 2.0 projects. I had previously Visual Studio 2019 and 2019 Build Tools installed.
The problem was that I had both x86 and x64 of dotnet installed, and both was in my systems PATH environment variable:
C:\Program Files (x86)\dotnet
C:\Program Files\dotnet
I did the following steps to fix this error:
Uninstalled VS2019
Uninstalled VS2019 Build Tools
Removed the x86 path from the environment variable
Removed the folder "C:\Program Files (x86)\dotnet" from my computer
Restarted VS2022
I think that the important part was to remove x86 from the environment variable. The other steps was just to "clean up".
I resolve the issue by installing the package directly form the Package Manager Console:
Install-Package NETStandard.Library -Version 2.0.3
Maybe you encountered the error after installing .NET core SDK 3.0. You have to check the environment variable MSBuildSDKsPath after every install of a new SDK. It must target the SDK you use to create your project. I use VS2017 with Windows 10.
For 2.2 SDK:
C:\Program Files\dotnet\sdk\2.2.104\Sdks
For 3.0 preview :
C:\Program Files\dotnet\sdk\3.0.100-preview3-010431\Sdks
The issue was occuring for me only when I tried to build the project with
dotnet build using VS2022 .
MsBuild on the same project was working fine.
What I did was:
restore the .net core runtime sdk - I was using 3.1 at the time.
Add both sdk paths in both Path vars, for the user and system, in that order:
Delete the MSBuildSDKsPath
P.s. I had this error while trying to run the coverlet coverage analysis
Had the same issue after I updated (snip) all VS installations on my windows machine a while ago. A restart of my PC resolved the issue.
I had this same issue, and it turned out the resolution for me was none of the above for me.
I was running the VS preview version with an older version of VS. I removed the Preview VS and then had to remove each of the environment variables by hand (i.e ANDRIOD_HOME, and .Net Maui vars, etc) and was back in business. Hope this helps someone out there who has installed VS Preview only to break the dev build environment.
Cause I had a lot of diffeculties finding the url for build tools, here it is :
https://aka.ms/vs/16/release/vs_buildtools.exe
Documenantion :
https://learn.microsoft.com/en-us/visualstudio/install/create-an-offline-installation-of-visual-studio?view=vs-2019
I encountered the same error and to fix it I installed .NET 6.0 SDK.
https://dotnet.microsoft.com/en-us/download/visual-studio-sdks
I only had .NET 7.0 SDK installed, and for whatever reason the project I was trying to use needed .NET 6.0 SDK.
I ran into this issue after installing .NET 7 to work with gRPC. After uninstalling .NET 7 the IDE was still looking for it. I deleted the empty C:\Program Files\dotnet\sdk\7 folder. I closed an opened the project it found the lastest .NET 6 installation.
Recently, I converted an Azure Function that used a C# script (*.csx) to a pre-complied class library using the Visual Studio Studio Tools for Azure Functions. It builds successfully in Visual Studio 2017 (as well as running and debugging too).
I'd like to build this AF library via our CI process. However, when I run the command dotnet build locally it fails with the following error:
C:\Users\ray\.nuget\packages\microsoft.net.sdk.functions\1.0.2\build\netstandard1.0\Microsoft.NET.Sdk.Functions.Build.targets(31,5): error : Could not load file or assembly 'Microsoft.Azure.WebJobs.Host, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.
The same error also occurs in our CI build.
Not sure why this error is occurring and how to resolve it. Is it the version of the dotnet CLI (I'm using v1.1)? Is it something else?
UPDATE 2018-01-08
According to a new answer by #theGRS https://stackoverflow.com/a/48156446/621827 this has been resolved.
Previous Answer
Here's what I've found.
dotnet msbuild uses the Microsoft.NET.Sdk.Functions .NETStandard 1.5 library which if you look at the dependencies on NuGet it doesn't use Microsoft.Azure.WebJobs
But if you use the Visual Studio 2017 msbuild it will use the .NETFramework 4.6 version of the library which includes Microsoft.Azure.WebJobs.
My suggestion is to use MSBuild for now.
I was having the same issue as well when running dotnet build, but no longer have this issue after updating Microsoft.NET.Sdk.Functions from 1.0.2 to 1.0.7.
Update to the latest version of this package in your Nuget package manaager and you should be able to run dotnet build again.
On my Jenkins Slave I am trying to get Visual Studio 2012 and Visual Studio 2015 to peacefully coexist but don't understand why it isn't working. Under my Jenkins Configuration I have TWO MSBuild installations defined as follows:
Name: .NET 4.0
Path to MSBuild: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe
Default parameters: /nologo /target:Build /consoleloggerparameters:PerformanceSummary;ShowCommandLine;ShowTimestamp
Name: .NET 4.6
Path to MSBuild: C:\Program Files (x86)\MSBuild\14.0\bin\MSBuild.exe
Default parameters: /p:VisualStudioVersion=15.0 /nologo /target:Build /consoleloggerparameters:PerformanceSummary;ShowCommandLine;ShowTimestamp
As you can see VS2015 Msbuild is now in a separate directory under C:\Program Files (x86)\MSBuild\14.0\bin\MSBuild.exe, the old one (VS2012) located at C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe.
In my Jenkins Job I have configured it to use the VS2015 MSBUILD (.NET 4.6) but when it builds it is using the VS2012 (.NET 4.0) MSBUILD.
So how do I call the VS2015 compiler from any of my jenkins jobs? Is there some undocumented magic with msbuild to support 2 different sets of tools (they’re both installed on my build vm in different paths)? Is this something that will have to be defined as a property in all project files? Since the builds are calling msbuild, I can't run something like vcvars to set paths since there’s no persistence between windows ’spawn’ calls / jenkins build steps and since the jenkins slave is a service can’t just ‘restart’ with each build. I've unsuccessfully tried to inject variables into the build via an external file as well.
Ideas from you out in the field?