search

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.75k stars 1.07k forks source link

Current 6.0 SDK building in VS errors with 'Microsoft.NET.SDK.WorkloadAutoImportPropsLocator' specified could not be found. #17461

Closed benaadams closed 3 years ago

benaadams commented 3 years ago

In VS building a mostly empty web project fails with 

1>------ Rebuild All started: Project: WebApplication1, Configuration: Release Any CPU ------
1>C:\Program Files\dotnet\sdk\6.0.100-preview.5.21255.14\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.ImportWorkloads.props(14,3):
 error : C:\Program Files\dotnet\sdk\6.0.100-preview.5.21255.14\Sdks\Microsoft.NET.SDK.WorkloadAutoImportPropsLocator\Sdk not found.
 Check that a recent enough .NET SDK is installed and/or increase the version specified in global.json.

1>C:\Program Files\dotnet\sdk\6.0.100-preview.5.21255.14\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.ImportWorkloads.props(14,38):
 error MSB4236: The SDK 'Microsoft.NET.SDK.WorkloadAutoImportPropsLocator' specified could not be found.

1>Done building project "WebApplication1.csproj" -- FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

At CLI it suceeds by has a different warning (which is https://github.com/dotnet/sdk/issues/17388)

Microsoft (R) Build Engine version 16.11.0-preview-21254-21+e73d08c28 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  Restored C:\Users\thund\source\repos\WebApplication1\WebApplication1\WebApplication1.csproj (in 62 ms).
  You are using a preview version of .NET. See: https://aka.ms/dotnet-core-preview

C:\Program Files\dotnet\sdk\6.0.100-preview.5.21255.14\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(255,5):
 warning NETSDK1048: 'AdditionalProbingPaths' were specified for GenerateRuntimeConfigurationFiles,
 but are being skipped because 'RuntimeConfigDevPath' is empty. 

[C:\Users\thund\source\repos\WebApplication1\WebApplication1\WebApplication1.csproj]
  WebApplication1 -> C:\Users\thund\source\repos\WebApplication1\WebApplication1\bin\Debug\net6.0\win-x64\WebApplication1.dll

Build succeeded.
dotnet-issue-labeler[bot] commented 3 years ago

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

benaadams commented 3 years ago

Causes all VS builds to fail including net5.0 ones.

Adding global.json does allow them to build

{
    "sdk": {
        "version": "5.0.202",
        "rollForward": "latestFeature"
    }
}
davidfowl commented 3 years ago

I'm hitting this too. I reverted my upgrade because of this

dsplaisted commented 3 years ago

The .NET 6 SDK now enables workload resolvers by default. This means when using Full Framework MSBuild (which happens in Visual Studio or when you use msbuild instead of dotnet from the command line), you need the workload resolver enabled. This is enabled by default in VS 16.10 Preview 3. For previous versions of MSBuild, you can set the MSBuildEnableWorkloadResolver environment variable to true. However, this workaround is likely to stop working in Preview 4 or Preview 5 of .NET SDK 6.0.100, as there is a change to the workload manifest schema which will cause the previous version of the resolver to fail.

In short: Update to VS 16.10 Preview 3 or later if you can, and if you can't you can try setting the MSBuildEnableWorkloadResolver environment variable to true.

davidfowl commented 3 years ago

I tried updating both VS and the .NET SDK and ASP.NET Core basically disappeared. I can't seem to make a new project (or open an existing one).

davidfowl commented 3 years ago

Actually, I can't seem to create any projects...

davidfowl commented 3 years ago

Repaired VS, still doesn't work. I'm gonna declare that there's a bug here.

benaadams commented 3 years ago

Actually, I can't seem to create any projects...

I get this when doing new project in VS https://github.com/dotnet/sdk/issues/17515 have to create a new one in cli

dsplaisted commented 3 years ago

Actually, a better workaround is probably to set MSBuildEnableWorkloadResolver to false. This should avoid the issue with the manifest schema change.

Of course, eventually after you are using an updated version of VS you'll want to unset the environment variable to allow workloads to work.

davidfowl commented 3 years ago

I'm using internal dogfood builds and its still broken in the ways expressed here.

akamud commented 3 years ago

I'm having this same issue on macOS, either on Rider or running dotnet build from the command line. .NET 6 was working a few days ago when I was using the nightly releases, stopped working when I installed Preview 4.

Tried the workaround, setting MSBuildEnableWorkloadResolver env variable to false seems to work. I was able to load and build the project now.

michaelherndon commented 3 years ago

This issue is definitely causing problems with omnisharp. No luck with the MSBuildEnableWorkloadResolver environment variable. Uninstalling the preview caused even more issues. I had to reinstall the preview and install the preview version of Visual Studio.

zivkan commented 3 years ago

Actually, a better workaround is probably to set MSBuildEnableWorkloadResolver to false. This should avoid the issue with the manifest schema change.

Can the SDK make this feature opt-in, rather than opt-out, until it's ready enough to work without such mitigations?

NuGet has a bunch of functional tests that restore various projects, and it's a bit of a burden to find all the places we need to set this. Plus we'll need to remember to remove it again in the future.

Webreaper commented 3 years ago

Seeing the same thing with .Net 6-preview-5, both with command-line builds and VS for Mac 8.10.2 (build 17). If I do:

export MSBuildEnableWorkloadResolver=false

that works around it and lets me build, both on the command-line and in VS4Mac.

slang25 commented 3 years ago

For those not wanting to remember to set this env var, you can add a Directory.Build.rsp file in the root of your repo to achieve the same thing, then once this gets fixed you can delete the file.

Example: https://github.com/slang25/JustEat.StatsD/commit/30fffb3c5cf6d94fb286642220445a95df5aa2fc

Webreaper commented 3 years ago

Just upgraded to VS for Mac 8.10.6 build 10, and .Net 6.0 preview-6, and still getting this. Any idea when it's likely to be fixed?

RussKie commented 3 years ago

Just hit this too in the latest VS: Version 17.0.0 Preview 3.0 [31516.353.main]

C:\Program Files\dotnet\sdk\6.0.100-preview.7.21358.10\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.ImportWorkloads.props(14,3): warning MSB4242: The SDK resolver "Microsoft.DotNet.MSBuildWorkloadSdkResolver" failed to run. An item with the same key has already been added. Key: Microsoft.NET.Runtime.Emscripten.Node
C:\Program Files\dotnet\sdk\6.0.100-preview.7.21358.10\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.ImportWorkloads.props(14,38): error MSB4236: The SDK 'Microsoft.NET.SDK.WorkloadAutoImportPropsLocator' specified could not be found. [C:\Development\DesignerTestHarness\WindowsFormsApp472\NetFx472.csproj]
RussKie commented 3 years ago

@dsplaisted looks like I can't use VS at all, outside projects that use local version of .dotnet...

davidfowl commented 3 years ago

When this happens I typically rename the C:\Program Files\dotnet\sdk-manifests folder, then restart VS

RussKie commented 3 years ago

When this happens I typically rename the C:\Program Files\dotnet\sdk-manifests folder, then restart VS

Thanks! That worked.

davidwengier commented 3 years ago

I just set the MSBuildEnableWorkloadResolver environment variable on all my machines to false. Looking forward to what breaks in future when I forget I've done that 😀

dsplaisted commented 3 years ago

I believe that with #18166 these error messages will get a bit more useful.

marcpopMSFT commented 3 years ago

I think the more recent issues described by Russ happens when you install preview 7 and then install VS (which has preview 6), you get mismatching manifests with emscripten and it breaks. You can repair preview 7 to work around this or delete the manifests folder as you've done. It'll get resolved once we put preview 7 in VS.

CyrusNajmabadi commented 3 years ago

So i've hit this as well. It took us almost a week to work through this. The only thing that worked was setting MSBuildEnableWorkloadResolver to false. Can fixing this be prioritized? (tagging @marcpopMSFT ). Thanks!

marcpopMSFT commented 3 years ago

The fix requires either getting preview 7 inserted into VS or going back in time and not breaking compat between preview 6 and 7. Unfortunately, the .Net build system is not conducive to created earlier signed builds and inserting to VS so typically this happens very late in each milestone. The good news is that this should be the final compat break in the workloads and so preview 7 through GA should not have the same issues.

This compat issue was communicated to tactics but we could have gone more broadly with it.

davidfowl commented 3 years ago

Feels like this has been broken for 3 previews but I'm happy it's getting fixed in preview 7

marcpopMSFT commented 3 years ago

There has been a lot of churn in the workloads (which we expected) but also churn in their names and dependencies (less expected). It should be fixed with preview 7 going forward mostly because the workload owners are done with that level of breaking change. We have a design for how to allow for smooth name changes with aliasing between different workloads but that work didn't get done for .net 6 (and was going to be a breaking change all on it's own).

Webreaper commented 3 years ago

Installed .Net 6 preview 7 this morning, and I still get the error about this workload when I launch Visual Studio for Mac, so still have to set export MSBuildEnableWorkloadResolver=false to be able to continue working. So I'm not sure this is fixed in preview 7.

slang25 commented 3 years ago

I fixed it by deleting the following folders from /usr/local/share/dotnet/sdk-manifests/6.0.100 image

I believe one of the older previews put these folders there, so it could be that it's fixed from occurring again, but with no automatic fix-up shipping in new previews.

Webreaper commented 3 years ago

Nice! Will try that later.

I had some problems with preview 7 (#19653), and when I reinstalled preview 6 they continued - in the end I had to manually delete/uninstall the preview 7 files that had been left behind. It might be useful if the folks from MSFT could add an option in the SDK installer that force-deleted all other older (and newer) previews completely, so people could ensure they were running with a clean install. Might reduce the number of false positive bug reports.

marcpopMSFT commented 3 years ago

@sfoslund for visibility as we tried to put a hack into the resolver to avoid this particular rename but it looks like that may have only applied to VS. Workloads were designed to be SxS across different feature bands but not within the same one which previews are.

Webreaper commented 3 years ago

I fixed it by deleting the following folders from /usr/local/share/dotnet/sdk-manifests/6.0.100

I tried deleting those folders, but it didn't fix the issue for me. I'm using the VS4Mac 2022 preview, and this workload issue hangs it at startup so you can't quit - the only way to solve it is force-quit. Luckily the export MSBuildEnableWorkloadResolver=false solves it in there too.

MichaelSL commented 3 years ago 
The SDK 'Microsoft.NET.SDK.WorkloadAutoImportPropsLocator' specified could not be found.  C:\Program Files\dotnet\sdk\6.0.100-preview.7.21379.14\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.ImportWorkloads.props

Setting env variable helps.

Could someone confirm that this doesn't work with preview7 for them too?

TaylorWatson commented 3 years ago

Nuking the entire /usr/local/share/dotnet/sdk-manifests/6.0.100 from orbit seems to have resolved my issues -.- This has been such a pain.

Webreaper commented 3 years ago

Nuking the entire /usr/local/share/dotnet/sdk-manifests/6.0.100 from orbit seems to have resolved my issues -.- This has been such a pain.

That did the trick. Thanks!

mhutch commented 3 years ago

For folks seeing this error, here's a summary/overview.

The error The SDK 'Microsoft.NET.SDK.WorkloadAutoImportPropsLocator' specified could not be found can be caused by several underlying issues.

It may indicate that the .NET workload resolver is not present in the MSBuild directory. This happens with versions of Visual Studio that do not support the .NET 6 previews. (It could also happen in corrupt MSBuild installations or custom MSBuild distributions, but that's an edge case.)

Otherwise, it indicates an internal error in the workload resolver, most likely when reading the workload manifests in the .NET SDK. A known case is a composition error due to stale manifests from an older .NET 6 preview, which can be fixed by removing the dotnet/sdk-manifests/6.0.100 directory from the .NET installation and reinstalling the latest .NET 6 SDK preview. If that doesn't fix it, check the MSBuild log for details of the internal error. It will be surfaced better in future.

if you can't find get to an MSBuild log in the IDE, you can invoke msbuild from the CLI. Be aware that Visual Studio includes its own copy of MSBuild, which can be invoked as follows:

slang25 commented 3 years ago

I had no idea vsmac-cli existed, that's really useful!

vova-lantsov-dev commented 3 years ago

I got this issue in a docker container running a clean installation of .NET SDKs. Here is some info: Docker: 20.x (latest) Base image: balenalib's aarch64 (arm64v8) debian bullseye .NET sdk installed in docker container: 3.1, 5, 6-rc.1 Installation instructions: here Logs: here (login as guest) Project: here (running using Nuke build automation system) Server instance: Raspberry Pi 4 Model B (8 GB RAM) How to reproduce on my server? here, then setup using internal database and add a build configuration with versioning settings: enabled pointing to my repo, TeamCity should fetch the configuration from VCS automatically

Contact me if you need more info about my case

dotMorten commented 3 years ago

I've been hitting this a lot now too. It fails with both VS2019 and 2022, provided you have .NET6-rc1 installed. The repro steps are pretty simple:

git clone https://github.com/Esri/arcgis-toolkit-dotnet
cd arcgis-toolkit-dotnet\src\Toolkit\Toolkit
msbuild /restore Esri.ArcGISRuntime.Toolkit.csproj

Output:

"e:\sources.tmp\tktest2\arcgis-toolkit-dotnet\src\Toolkit\Toolkit\Esri.ArcGISRuntime.Toolkit.csproj" (default target) (1:35) ->
"e:\sources.tmp\tktest2\arcgis-toolkit-dotnet\src\Toolkit\Toolkit\Esri.ArcGISRuntime.Toolkit.csproj" (Build target) (1:48) ->
"e:\sources.tmp\tktest2\arcgis-toolkit-dotnet\src\Toolkit\Toolkit\Esri.ArcGISRuntime.Toolkit_zk34cdww_wpftmp.csproj" (_CompileTemporaryAssembly target) (4) -> e:\sources.tmp\tktest2\arcgis-toolkit-dotnet\src\Toolkit\Toolkit\Esri.ArcGISRuntime.Toolkit_zk34cdww_wpftmp.csproj(9,31): error MSB4236: The SDK 'MSBuild.Sdk.Extras/3.0.23' specified could not be found.
Webreaper commented 3 years ago

@dotMorten Have you got any other earlier .Net 6 previews installed? I saw this frequently until preview-7, but it only went away when I physically deleted all the old previews, per @TaylorWatson's comment previously (see also here).

dotMorten commented 3 years ago

@Webreaper On one PC where I reproduce it, it's a completely fresh install. Never had anything but RC1 and VS2022P4 on it. I'm starting to think my issue is WPF specific though.

marcpopMSFT commented 3 years ago

Closing this issue out with the release of RC2 which we believe should fix most instances of this. Folks still seeing issues should try to clean out their sdks (in particular old sdk-manifests) and reinstall as many people still hitting this had leftover files from old maui-check calls. I think dotMorten's repro is a completely separate issue than this.

vova-lantsov-dev commented 3 years ago

@marcpopMSFT I still have this issue with .NET 6 rc2, my case is described a few comments above

Here is full log of build: https://tc.vova-lantsov.dev/buildConfiguration/Vlrpi_Build_CreateBuilder/402?buildTab=log (login as guest)

marcpopMSFT commented 3 years ago

@vova-lantsov-dev Was this a clean install of RC2 or did the machines used have prior versions? All situations of this we've found so far were people with older previews who upgraded or had previously used maui-check.

CC @dsplaisted

vova-lantsov-dev commented 3 years ago

@marcpopMSFT that's a clean installation inside the docker container, after docker cache was pruned.

How I install SDKs: link

marcpopMSFT commented 3 years ago

@vova-lantsov-dev so you're doing arm64 linux? @sfoslund, since many of the workloads doesn't support linux or arm64 today, do we have an issue in that package where they are not included but the sdk is looking for them anyway?

vova-lantsov-dev commented 3 years ago

@marcpopMSFT sure, arm64v8 linux docker images

sfoslund commented 3 years ago

do we have an issue in that package where they are not included but the sdk is looking for them anyway?

@marcpopMSFT I'm not following, can you clarify what you mean? We expect that if a workload isn't supported on the current OS then installing that workload will fail early (before any packs are installed) with an error message about not being supported.

marcpopMSFT commented 3 years ago

@sfoslund To clarify, I think the customer is using arm64 linux docker images, isn't trying to do workloads at all, but is getting workload failures when just using this sdk. I'm wondering if our workload fallback logic is working incorrectly here. I don't think they are doing a workload install at all from the build results. Could be something off specifically with our linux arm64 images maybe or our fallback logic

Here is full log of build: https://tc.vova-lantsov.dev/buildConfiguration/Vlrpi_Build_CreateBuilder/402?buildTab=log (login as guest)

vova-lantsov-dev commented 3 years ago

@marcpopMSFT what you mean by workload?