An error dialog pops up when creating the .Net Core project with the latest .NET SDK 6.0

[Zheng-Li01]

More info:

1. This is a regression issue, can't reproduce on .NET SDK 6.0.100-preview.5.21255.24-win-x64.
2. The issue can reproduce more types core project, such as winforms, wpf. console etc.

Version info:
NET SDK 6.0.100-preview.5.21257.10-win-x64.

Repro Steps:

1. Install the latest .Net 6.0 from https://github.com/dotnet/core-sdk.
2. Try to create .Net Core project.

Actual Results:
An error dialog pops up.

Expected Results:
Creating the .Net Core project with the latest .Net 6.0 successfully.

[dotnet-issue-labeler]

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.

[Zheng-Li01]

More info:
The project can be create/built/run successfully by using Command. However an error dialog pops up when trying to open it by using VS.

[davidfowl]

+1 nothing works after I upgrade

[dsplaisted]

@Zheng-Li01 What version of Visual Studio is this happening with?

[benaadams]

I get it in 16.10.0 Preview 2.1

[dsplaisted]

Can you try setting MSBuildEnableWorkloadResolver to false and see if that fixes the problems?

(You don't want to leave this permanently on, as it will disable any workloads, which in .NET 6 will include ios, android, and Blazor AOT support.)

[benaadams]

Nope

[dsplaisted]

@dotnet/templating-engine-maintainers @wli3 @marcpopMSFT This looks like it may be a separate issue from what #17536 is trying to fix. It looks like maybe the workload template resolver hasn't been updated to handle the manifest schema change. What's the process for updating that? Is it supposed to happen with normal .NET SDK insertions or what?

[DavidKarlas]

@phenning Where is logic for VS sync with optional workload templates, sounds like it needs updating?

[dsplaisted]

Specifically, I think that the template engine needs to use a version of the workload manifest reader with this change: #17329

[davidfowl]

If this requires a VS change to function, what does that mean for using nightly builds?

[dsplaisted]

I think it may mean you need to create projects from the command line.

You could also delete or rename the SDK manifests folder: C:\Program Files\dotnet\sdk-manifests. That would break iOS, Android, and Blazor AoT though.

[davidfowl]

So nobody can update the sdk? Can we turn off the workload thing by default until there's a version of vs that works ?

[dsplaisted]

This is different from the workload resolvers where there was a flag to turn it on or off. It's in the template engine, and I don't think there's a way to turn it off. It ships in VS, so even if we wanted to turn it off we'd have to put the change in 16.10, so I think what we need to do is just fix the template engine in 16.10.

We could remove the workload manifests from the SDK, but that would break a bunch of ios, android, and Blazor AoT scenarios.

[davidfowl]

We need to remove it until there's something public and workable. I don't think it's reasonable to break like that without an ETA for when it gets resolved. Of course we have these cut over points where VS needs to be updated but this is a hard break...

[phenning]

@davidfowl this shouldn't require a template engine change unless there is something broken with the API surface. SDK needs to insert a new manifest reader. We just call the API.

[phenning]

FYI, the only thing we call on the locator are the following two methods:

   TemplateLocator.GetDotnetSdkTemplatePackages(sdkVersion, dotnetRootPath);
   TemplateLocator.TryGetDotnetSdkVersionUsedInVs(vsVersion, out sdkVersion);

[phenning]

Although I don't understand why the error happens so late, this error should happen when we go to display the available templates, not when we try to create one. We don't even call into the resolver at creation, and the version of template engine itself that is shipped with Visual Studio doesn't know anything about the optional workloads (it is the 3.x version of TE). We just have the layer in WebTools that grabs the template paths from the template locator and installs them into the template engine VS hive.

[phenning]

OK, I see why this only seems to be happening on Create, - it actually is also happening on the enumeration of the templates as well, except NPD is handling the exception being thrown by the locator so that there isn't a problem with the template list. This is resulting in a fallback to the pre 16.9 behavior where we just see the vstemplate versions of the .net core templates - notice the (.NET Core) in the template name in the screenshot. Then when you try to create, we try to refresh the templates (since we failed earlier) and this time the exception is not caught by NPD.

Separate from a fix in the TemplateLocator, I think I (VS) needs to harden the where we call into the template locator in visual studio, catching any exceptions and logging them to the activity log. By doing this, at least we'd still have the core non-optional templates available and we'd only see the templates from the optional workload not be shown.

[dsplaisted]

OK, it turns out that the change in #17329 isn't in VS 16.10 yet, but it will be there before the GA release. Until 16.10 GA, here are the workarounds you can use:

• Use .NET 6 Preview 4 instead of Preview 5
• Create projects using the command line (dotnet new) instead of from within Visual Studio
• Delete or rename the C:\Program Files\dotnet\sdk-manifests folder (note that this will break iOS, Android, and Blazor AOT)
• Build the release/5.0.0xx branch of the dotnet/sdk repo. Copy the file artifacts\bin\Microsoft.DotNet.TemplateLocator\Debug\net472\Microsoft.DotNet.SdkResolver.dll to the Visual Studio PrivateAssemblies folder (with a path similar to C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\IDE\PrivateAssemblies)

[Zheng-Li01]

Verified the issue with latest 6.0.100-preview.5.21263.57, for now the project can be created successfully. so closed it.

[benaadams]

Still broken in latest nightly 6.0.100-preview.5.21264.2

OK, it turns out that the change in #17329 isn't in VS 16.10 yet, but it will be there before the GA release. Until 16.10 GA, here are the workarounds you can use:

Don't think VS 16.10 is a solution if installing the sdk breaks previous VS before even asking what version of .NET to use (e.g. this isn't trying to create a .NET6.0 app)

[davidfowl]

Delete or rename the C:\Program Files\dotnet\sdk-manifests folder (note that this will break iOS, Android, and Blazor AOT)

Since this the only reasonable workaround, remember to undo this when you install a new version (if you did a rename), or the new installer won't remove it during the previous version uninstall.

[marcpopMSFT]

16.10 preview 4 will include the fix for this and the SDK will not load into 16.9 as we've updated the minimum required version for .NET 6 with preview 4 and newer.