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

CORECTION

I am finally able to get VS2022 for Mac (v17.0 - build 8989) working by setting the MSBuildEnableWorkloadResolver = false environment variable.

For those who have the same issue: Note that the most systemic way to set environment variables in MacOS is through launchctl:

 % launchctl setenv MSBuildEnableWorkloadResolver false

The old approach of systemically setting environmental variables was via ~/.MacOSX/environment.plist . However, that approach was removed in OS X Lion.

If you turn on Diagnostic log verbosity, the first thing listed in the build log will be the environment variables used for the build. Setting environment variables in the traditional Unix way (.profile, .bash_profile, .zprofile, .zshenv, etc) will not work for applications.

TO THE MAINTAINERS

I still ask that you consider reopening this issue. Several times it is stated that setting the MSBuildEnableWorkloadResolver environment variable is not necessary with more recent releases of VS2022. My experience has proven that this is not universally true.

Thank you @baskren !

‘’’ launchctl setenv MSBuildEnableWorkloadResolver false ‘’’

finally brought back my rider ide

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.

I just had this issue with Visual Studio for Mac 17.3.8 (build 5). This issue is clearly not fixed and should be reopened.

Just had this issue on VS 17.3.6 (build 20) on macOS Monterey 12.6

Wasted days before finding this “launchctl setenv MSBuildEnableWorkloadResolver false”

The issue started after installing latest Xamarin.iOS.

Seems like a lot of regression testing is left with the community.

This is still happening for me as well.

• Windows 11 Pro Workstation clean install (not upgrade)
• VS 2022 clean install, no VS 2019
• Nuke 5.3.0
• <Project Sdk="Microsoft.NET.Sdk">
• <TargetFrameworks>net6.0</TargetFrameworks>
• Don’t know what MSBuildEnableWorkloadResolver is so I assume it’s not set.

❯ nuke
PowerShell Desktop version 5.1.22000.282
Microsoft (R) .NET Core SDK version 6.0.100
Creating directory 'C:\Source\Redacted.EntityFrameworkCore\.nuke\temp'...

███╗   ██╗██╗   ██╗██╗  ██╗███████╗
████╗  ██║██║   ██║██║ ██╔╝██╔════╝
██╔██╗ ██║██║   ██║█████╔╝ █████╗
██║╚██╗██║██║   ██║██╔═██╗ ██╔══╝
██║ ╚████║╚██████╔╝██║  ██╗███████╗
╚═╝  ╚═══╝ ╚═════╝ ╚═╝  ╚═╝╚══════╝

NUKE Execution Engine version 5.3.0 (Windows,.NETCoreApp,Version=v5.0)

The SDK 'Microsoft.NET.SDK.WorkloadAutoImportPropsLocator' specified could not be found.  C:\Program Files\dotnet\sdk\6.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.ImportWorkloads.props
StackTrace:
   at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
   at Microsoft.Build.Evaluation.Evaluator`4.ExpandAndLoadImportsFromUnescapedImportExpressionConditioned(String directoryOfImportingFile, ProjectImportElement importElement, List`1& projects, SdkResult& sdkResult, Boolean throwOnFileNotExistsError)
   at Microsoft.Build.Evaluation.Evaluator`4.ExpandAndLoadImports(String directoryOfImportingFile, ProjectImportElement importElement, SdkResult& sdkResult)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.Evaluate()
   at Microsoft.Build.Evaluation.Evaluator`4.Evaluate(IEvaluatorData`4 data, ProjectRootElement root, ProjectLoadSettings loadSettings, Int32 maxNodeCount, PropertyDictionary`1 environmentProperties, ILoggingService loggingService, IItemFactory`2 itemFactory, IToolsetProvider toolsetProvider, ProjectRootElementCacheBase projectRootElementCache, BuildEventContext buildEventContext, ISdkResolverService sdkResolverService, Int32 submissionId, EvaluationContext evaluationContext, Boolean interactive)
   at Microsoft.Build.Evaluation.Project.ProjectImpl.Reevaluate(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
   at Microsoft.Build.Evaluation.Project.ProjectImpl.ReevaluateIfNecessary(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
   at Microsoft.Build.Evaluation.Project.ProjectImpl.ReevaluateIfNecessary(ILoggingService loggingServiceForEvaluation, EvaluationContext evaluationContext)
   at Microsoft.Build.Evaluation.Project.ProjectImpl.ReevaluateIfNecessary(EvaluationContext evaluationContext)
   at Microsoft.Build.Evaluation.Project.ProjectImpl.Initialize(IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
   at Microsoft.Build.Evaluation.Project..ctor(ProjectRootElement xml, IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectCollection projectCollection, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
   at Microsoft.Build.Evaluation.Project.FromProjectRootElement(ProjectRootElement rootElement, ProjectOptions options)
   at Nuke.Common.ProjectModel.ProjectModelTasks.ParseProject(String projectFile, String configuration, String targetFramework)
   at Nuke.Common.Execution.Telemetry.CheckAwareness()

This is still an issue on the release version, even on Azure pipelines.

see this build for example: https://dev.azure.com/AvaloniaUI/AvaloniaUI/_build/results?buildId=16510&view=logs&j=0da5d1d9-276d-5173-c4c4-9d4d4ed14fdb&t=5494183b-801e-5084-3b4b-5451c6a14ee1

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.

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:

• Windows: use the Developer Command Prompt shortcut matching the VS instance, and invoke msbuild from that prompt.
• Mac: install vsmac-cli and invoke vsmac msbuild from Terminal.app. If you have multiple VS instances, see vsmac --help for arguments to select a specific instance.

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 😀

@hellfirehd please read #22221 (or better visit official Nuke community in Slack to get support there)

@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.

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

Thanks! That worked.

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.

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.

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.

The ‘Microsoft.NET.SDK.WorkloadAutoImportPropsLocator’ not being found error can happen in VS Mac for different reasons. There is a recent feedback ticket where if there were old pre-release versions of .NET 7 installed then this could also happen:

https://developercommunity.visualstudio.com/t/After-updating-to-net-7-Visual-Studio-/10194756

The underlying bug, old workload was renamed in later .NET 7 SDK, was also reported for Windows - https://github.com/dotnet/sdk/issues/28947

The workaround there is to remove .NET completely and install it again. The developer community ticket gives information on how to do that.

If that does not solve the problem, then we would need the IDE log. Since the IDE log may contain personal data it would better if this was reported on Developer Community or via Report a Problem from with VS Mac itself. Thanks.

That is because monodevelop is not supported anymore I think at all.

I am also having this issue. Attempting to run my project (https://github.com/ppy/osu) in monodevelop gives me: /usr/share/dotnet/sdk/6.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.ImportWorkloads.props(38,38): Error MSB4236: The SDK 'Microsoft.NET.SDK.WorkloadAutoImportPropsLocator' specified could not be found. (MSB4236) (osu.Game) But if I run it in CLI (dotnet run --project osu.Desktop) it runs just fine. I am not sure if this is an issue relating to dotnet or monodevelop, but I read here that this is apparently an issue with dotnet, so I figured putting it here.

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"
    }
}