I am trying to build a dotnet core web app on a build server that has MsBuild, but not Visual Studio, installed. I cannot get around the message error MSB4236: The SDK 'Microsoft.NET.Sdk.Web' specified could not be found.
The command dotnet --info shows Microsoft.NETCore.App 3.1.0 installed, just as on my development machine where the project builds. The contents of C:\Program Files\dotnet\sdk\3.1.100 appear to match between the two machines. Global.json points to the 3.1.0 version.
Is Microsoft.NET.Sdk.Web a separately-installed thing? I see what look like separate packages, now deprecated, on NuGet, and I'm guessing this is now baked into the base .NET SDK?
Where should I be looking for differences to try to find the missing pieces?
Solved the problem by (1) running vs-buildtools installer to put some additional pieces in place, and (2) adding some NuGet packages for web component.
Related
I have installed the Visual Studio 2019 community version 16.4.4 on a brand new laptop
OS:- Windows 10 Home Single Language
The following are the .NET Core SDKS installed in my laptop
The command dotnet --info gave me the following details
I created a Azure function with V3 template
The project settings are given below
When I try to debug , i get the following error
A fatal error has occurred and debugging needs to be terminated. The debugger was configured to use the Desktop CLR (.NETFramework) Managed debugger, but the target process loaded the CoreCLR (.Net Core) runtime. To debug this project, configure it to use the 'Managed (CoreCLR)' debugger."
Tried several options like the one mentioned in the link below
https://social.msdn.microsoft.com/Forums/en-US/59f880f7-ed60-4842-bc55-a9400971c58b/problem-debugging-net-core?forum=vsdebug
EDIT: This has been fixed in the latest release of Visual Studio v16.4.5
The problem seems to be a mismatch in the version of the Azure Functions CLI. As a workaround, you can do this:
Install the latest Azure Functions CLI, from the command line run:
npm i -g azure-functions-core-tools#3 --unsafe-perm true
or if you are using Chocolatey:
choco install azure-functions-core-tools
Restart Visual Studio.
I still have this issue after reinstalling my VS2019, downloading the latest sdk and downloading the core tools multiple times. Seems like the only way for now is to run without using the debugger (Ctrl + F5). Sometimes I downgrade the function to v2.1 for this only happens on v3 functions.
Edit: I got this fixed when I updated my VS to 16.5.1
It looks like one similar issue which has been reported to DC forum. However it works well in my side with same 16.4.4 version. Since I didn't reproduce same issue, I can't provide a direct answer.
Here're some possible workarounds which may help:
Repair VS and go Tools=>Import and Export Settings=>Reset all settings=>No,just reset, overwrite... (Since my same version works well)
Hint from this one, you may backup the launchsettings.json in project and then delete it, rebuild and debug(F5) it again.
And if the issue persists, you can try installing .net core 3.0 sdk and recreate a new project to check if it helps.(I have both .net core 3.0 and 3.1 installed, but by default it picks .net core 3.0 when I create the project, not sure if it makes any difference.)
Hope it helps :)
Update:
Sorry for not noticing that the solution will not work for you. Since the solution doesn't work, you can choose another way. As the error says, you need to
configure it to use the 'Managed (CoreCLR)' debugger."
So, try to configure on hand, Select 'Debug' above the VS 2019 tab, then
Original Answer:
I faced exactly the same error before and solved it with below solution, it works well.
Solution:
Just enable the native code debuging.
Right click your project > properties > Debug. Tick 'enable the native code debugging' like this:
I have the same issue, I have upgraded visual studio 2019 to 16.4.4 and it resolved my issue. that was the bug by visual studio 2019 in 16.3 versions. please upgrade visual studio. it will definitely resolve your issue.
Issue was resolved with the next upgrade of Visual Studio 2019
Trying Install the v3.x Core Tools package from the command line run npm install -g azure-functions-core-tools#3.
Reference: Use npm to install Core Tools on Windows
I'm trying to set up a build configuration for an ASP.NET Core (built on .NET full framework 4.6.2) project.
I'm Using TeamCity Enterprise 2017.2.3 (build 51047)
The .NET Core SDK is installed on the build server, along with 4.6.2 of the .NET Framework.
I am getting the following Build Error Message:
... This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\packages\NETStandard.Library.2.0.3\build\netstandard2.0\NETStandard.Library.targets.
Anyone come across this error before?
I added the latest recommended Nuget exe (4.6.2) as well.
The build step upon which it is failing is a .NET CLI (dotnet) step.
I've set the Command to build
and the Projects to the Solution file.
Dotnet CLI is definitely installed and is version 2.1.300
Yeah update the build tools on the TeamCity server, you're probably using the latest Visual Studio version on your local machine but your build tools on the build server are slightly out of date, probably earlier than v15.5.
https://www.visualstudio.com/thank-you-downloading-visual-studio/?sku=BuildTools&rel=15
Also ensure that you have selected to add the .NET Core 2(+) build tools as they include the .NETStandard and aren't selected by default. See https://github.com/dotnet/standard/issues/458#issuecomment-323845208
I am using Visual Studio 2015 (Pre), Framework 4.5.2
I have the folowing project structure
StorageProject
nuget package Microsoft.WidowsAzure.Storage is installed
This Nuget package has (among others) dependencies on Microsoft.Data.OData, wich is also installed
AnotherProject
Has a refernce on StorageProject
Does not have any nuget package or other refernces (except default references on the framework)
Here is the list of the packages installed in StorageProject
WindowsAzure.Storage 4.3.0
Microsoft.WindowsAzure.ConfigurationManager 3.1.0
System.Spatial 4.3.0
Microsoft.Data.Edm 5.6.4
Microsoft.Data.OData 5.6.4
Microsoft.Data.Services.Client 5.6.4
These are all dependencies of WindowsAzure.Storage, latest versions.
There is no other version of these packages installed anywhere on the solution.
I will focus on Microsoft.Data.OData, but the same problem occurs with Microsoft.Data.Edm and Microsoft.Data.Services.Client 5.6.4
When building StorageProject, the correct version of these dll (5.6.4) ends up in the bin folder of the project.
But when building AnotherProject, the bin folder contains version 5.6.2 of the dll.
Now I passed all day trying to figure out where these dlls come from.
There is a version 5.0.0.0 in the GAC, wich I cannot uninstall. (gacutil yields it is used by something).
I did a file search on C:\ to find that the only place where this version of the dll is (beside the bin folder of my project) is in C:\Program Files (x86)\Microsoft WCF Data Services\5.6.2. If I delete (move) this folder, my project builds "normally" and everything is fine. In fact, in this case OData is not in the bin folder at all. And as far as I am concerned, that's ok this way.
Now the real question(s) :
Why is it the version from Microsoft WCF Data Services that ends up in the bin, instead of the version actually installed in the referenced project?
Where does Microsoft WCF Data Services comes from ? I don't remember installing it at all, maybe it comes with a version on Visual Studio? (I have 2012, 2013 and 2015 installed)
Can I uninstall it? I don't see it in Windows' control panel.
•Why is it the version from Microsoft WCF Data Services that ends up in the bin, instead of the version actually installed in the referenced project?
This could be due to the fact that the storage client does not depend on a specific version of the Data Service Client. Since Specific Version is set to false, the GAC will be searched first during compilation, any version will be considered "acceptable", and no other version will be exported.
•Where does Microsoft WCF Data Services comes from ? I don't remember installing it at all, maybe it comes with a version on Visual Studio? (I have 2012, 2013 and 2015 installed)
It could be installed due to a variety of reasons. The Azure SDK contains this as well. So if you ever installed the Azure SDK, it could have come with that.
•Can I uninstall it? I don't see it in Windows' control panel.
Looks like this is only possible by uninstalling the MSI package that installed the assembly via Add/Remove programs. For that, you would have to again figure out which installation brought this assembly with it and check whether that is needed or not.
I recently upgraded to TeamCity 9, at first everything was okay. Then, for some unknown reason, I was unable to get a full list of available packages via the NuGet GUI. At first it appeared that all the portable class libraries where missing, then all of them went missing.
What I've tried:
I've removed all old artifacts from TeamCity,
I've deleted and reset TeamCity's cache
I've restarted TeamCity and its NuGet v1 service
I've rebuilt some basic class libries (PCL) with no dependencies.
I've cleared NuGet cache in my Visual Studio options.
I've ran VS as admin.
When I click on my TeamCity Feed in the package manager, it immediately returns no results with a very brief flash of "retrieving result".
Okay so the very odd thing is I can manually list (and install) my packages via the console:
PM> Get-Package -ListAvailable
Id Version Description/Release Notes
-- ------- -------------------------
RobGeoLtd.Core 1.0.2 Core Framework Portable Class Library
RobGeoLtd.Measurement 0.1.36 Defines units of measurement and conversion methods between them
PM> Install-Package RobGeoLtd.Core
Installing 'RobGeoLtd.Core 1.0.2'.
Successfully installed 'RobGeoLtd.Core 1.0.2'.
Adding 'RobGeoLtd.Core 1.0.2' to Logger.
Successfully added 'RobGeoLtd.Core 1.0.2' to Logger.
PM>
So yeah, I'm at a loss. NuGet bug? I'm all up-to-date as far as I can tell. :/
For anyone experiencing a similar issue:
I also tried all of the above. It turned out that my built packages were targeting .NET 4.5.2 and my project was targeting .NET 4.5.
It would appear to be a TeamCity issue. I reverted to a back up of the CI server running 8.1.4 and the old feed items have returned. I will attempt the upgrade again.
Update: Yup, its defiantly the upgrade from 8.1.4 to 9.0.3 that caused it. Will file a bug. https://youtrack.jetbrains.com/issue/TW-40589
I'm having a problem on my TeamCity CI build server where during compilation I get the following error:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2342, 9): error MSB3086: Task could not find "AL.exe" using the SdkToolsPath "" or the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A". Make sure the SdkToolsPath is set and the tool exists in the correct processor specific location under the SdkToolsPath and that the Microsoft Windows SDK is installed
I've found similar reports from a year ago when people were upgrading to .NET 3.5, for example this one. In that case, installing the latest SDK solved the issue, however I have already installed the latest SDK (Microsoft Windows SDK for Windows 7 and .NET Framework 4) on my build server. The MSBuild tools are all there on the server, in a folder called
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319
and AL.exe exists in
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools
However the registry key mentioned in the error message does not exist. So, it seems like there is something wrong with the installation/configuration of MSBuild. This error only happens for projects that have embedded resources, which require AL.exe.
As you have install the latest SDK (I'm assuming that's v7.1)
Go to "Microsoft Windows SDK v7.1" from the Start menu
Select "Windows SDK 7.1 Command Prompt" and enter
cd Setup
WindowsSdkVer -version:v7.1
This will tell msbuild to use that version of the tools without needing to do any scary registry editing.
Even though the question is quite old but it still appears in the top of google search results so I decided to post my solution as well. I have trapped into same issue while during TeamCity setup on Windows Server 2016 and Windows 10 Pro.
I have installed Microsoft Build Tools 2015 and Windows 10 SDK (Only tools for .NET 4.6.2) and got the error from question.
The missing puzzle was to set environment variable: TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools.
After setting environment variable MSBuild was able to resolve all needed tools including AL.exe and build succeeded.
Please let me know if same can be achieved by setting values in registry, but otherwise environment variables also works very well in this case and no installation of VS is needed.
You also need to apply the following registry fix to update msbuild to point to the V7.1 sdk values.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0]
"MSBuildToolsPath"="C:\\WINDOWS\\Microsoft.NET\\Framework\\v4.0.30319\\"
"MSBuildToolsRoot"="C:\\WINDOWS\\Microsoft.NET\\Framework\\"
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1#InstallationFolder)"
"MSBuildRuntimeVersion"="4.0.30319"
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\WinSDK-NetFx40Tools-x86#InstallationFolder)"
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\WinSDKNetFx35Tools#InstallationFolder)"
"MSBuildToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MSBuild\\ToolsVersions\\4.0#MSBuildToolsPath)"
I had the same problem there, here's my simple answer to this.
After you have installed the Microsoft Windows SDK 7.1 on the TeamCity Server.
In Regedit Change this key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\SDK40ToolsPath
to
$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx40Tools-x86#InstallationFolder)
Follow the below steps. This worked perfectly to me. Saved my time.
1- Right-click the My Computer icon and choose Properties, or in Windows Control Panel, choose System.
2- Choose Advanced system settings.
3- On the Advanced tab, click Environment Variables.
4- Click New to create a new environment variable under User variable section.
5- Variable name: TargetFrameworkSDKToolsDirectory
6- Variable value: TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools
Variable value depends on your SDK installation path.
7- Click OK and Save all windows.
8- Restart Visual Studio.
I have a simple, effective fix.
The problem seems to be that the tools version delivered with Visual Studio is version 7.0A, while the version delivered with the Windows SDK is version 7.1. That's all very well, but MSBuild.exe is still looking for the version 7.0A registry keys, which don't exist. This has to be a bug!
Looking in my registry, all the information for V6.0 and V7.1 is present and correct. So my solution is simple. I created a registry link that makes an alias of the 7.1 keys.
It's not possible to create registry links using the built-in tools, so I downloaded a little utility called 'regln' from here.
C:>regln-x86.exe "\Registry\Machine\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A" "\Registry
\Machine\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1"
Job done. MSBuild now works perfectly on the TeamCity server.
Add a system env variable TargetFrameworkSDKToolsDirectory
like this:
TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools
restart VS
Ran into the same issue setting up a new build server on Windows 10.
Found and installed the latest (at the time) Microsoft Windows SDK for Windows 7 and .NET Framework 4 and that solved the problem.
We recently had this problem trying to get our .Net 4.0 builds working. We found that the location of al.exe had changed between where the original MSBuild that came with .Net 4.0 looks, and the Visual Studio SDK for .Net 4.0 (which was released later).
Since the only standalone installation of the SDK tools available is the one we had already installed without success (the one you mentioned), the only solution we could think of was to install Visual Studio on the build agents. We put Visual Studio 2010 Express (to keep the installation as lightweight as possible) on there and the problem went away. Not a pretty solution, but it did work - installing VS2010 also installs the SDK tools of the specific version that MSBuild appears to be looking for.
This is a problem that really shouldn't happen, but there didn't seem to be a way of making MSBuild look in the correct place for the tools, even hacking around in the registry.