VS is buggy when there is a problem with "framework" parameter

[YegorStepanov]

Bug 1

When the framework parameter is string, the templates are not shown. Only in this repository I find that framework must be a choice.

Bug 2

If we delete/rename a string framework parameter, build and publish a template, add it to the CLI, and open VS, the working template will be shown. If then we close VS, revert deleted lines in the template, update the template in the CLI, and close & open VS, the template will be shown, but it's broken: if we create a project via this template, the empty broken solution with one file( .sln ) will be created (also, there is no screen to set up the template's parameters).

The broken templates are shown in 17.6.2 and 17.6.3, but not in 17.7.0 preview 2.0.

Bug 3

When framework is a choice, but no one desired framework is installed. VS display an empty screen:

Bug 3.1

BenchmarkDotNet works with almost all frameworks. Should they all be added to the framework? In this case, help is very verbosity (I've added a bit). Maybe help can be overridden?:

Bug 3.2

What about platform-specific TFM, like net6.0-windows? No way to add them? (From the CLI, the user should still use -f net6.0-windows (backwards compatibility)).

Will these issues be fixed soon, or will we have to disallow templates to set platform-specific TFM? (Indeed, it's not a big problem)

[Edit] Maybe you will allow this parameter to be a string, and until then it's ok that BDN templates are broken in VS?

[Edit2]

FYI Rider behavior

for the string framework, it displays an inactive dropdown menu, and after building the project, it crashes :)

for the "Bug 3" case, all monikers are displayed, but after solution is created, an error is displayed that the framework is not installed (IMO it's a correct behavior).

[sayedihashimi]

We have special support for the framework parameter and I believe it needs to be a choice. For your case it sounds like you just want the standard support and not the special case support that we've built. I think you could change the name of the parameter to something like 'targetFramework' and that should avoid the special case logic. Will that work for you?

cc @phenning

[YegorStepanov]

@sayedihashimi

BenchmarkDotNet has had templates for several years now, we can't rename the parameter.

Currently, the parameter behaves the same as dotnet console:

dotnet new console -f net7.0
dotnet new benchmark -f net7.0

dotnet new console -f net7.0-windows-12345
dotnet new benchmark -f net7.0-windows-12345

[sayedihashimi]

@YegorStepanov as far as I know the support for the framework parameter has always been like this. Is the behavior you're seeing in VS a regression?

[YegorStepanov]

@sayedihashimi I didn't find a note in the documentation that the framework should be a choice, only in your repository (although not in README, but in #8 🙂)

In 2017, .NET templating was added. In 2020, VS started to understand this format. Looks like the support was not fully done as the template doesn't appear in VS. Showing a blank screen to a user who doesn't have the required frameworks installed also looks like a bug, since .NET has good backwards compatibility (especially in simple projects like templates).

I think many templates may need post-processing depending on the framework. Otherwise, some templates will only work from the command line (as it is now).

[YegorStepanov]

I suggest doing it like in Rider but without crash:
If there is no suitable framework, display disabled dropdown for framework with default value.
If framework is a string then display disabled dropdown with default value.
And add docs that framework should be a choice.

[phenning]

For Bug 2, I believe that is happening because Visual Studio maintains a cache of the template metadata to show on the new project dialog, this only gets invalidated when templates are installed or uninstalled and new project dialog is opened. I'll concede that this is suboptimal.

To see changes to the template parameters in a template dev scenario, you need to uninstall the template, launch new project dialog, then make changes, install and relaunch the dialog.

For updating content, this is not necessary.

For Bug 3, we will need to investigate. Could you share the template.json you used to get into this state?

net6.0-windows should work, looking at the code, we do handle this, did you try having this as your choice parameter? I can take another look.

One thing you may want to do to make sure you are getting up to date metadata (this should help with Bug 2, above) is to remove the following folder and file:

file: %localappdata%\Microsoft\VisualStudio\17.0_f100f560\NpdProjectTemplateCache_en-US
folder: %localappdata%\Microsoft\VisualStudio\17.0_f100f560\TemplateEngineHost

Where the Visual Studio instance id listed there can be obtained from the devenv.isolation.ini file in your Common7\IDE folder.

I did take a look through the code and allowing Framework to be just another string parameter is doable, but not at all a trivial change.

[YegorStepanov]

VS correctly displays platform TFM (albeit with a preview mark):

Ah, sorry, platform-specific TFM is not supported by the console, so we don't need to handle such cases:

In this case, we will add all .NET versions that have not expired end-of-life:

Blank screen

If I delete the VS cache and then add only .NET 5 to framework (I don't have .NET 5), the template will not be displayed.
But if I delete the VS cache, add .NET 5 and .NET 6 (I have .NET 6), the template will be displayed. Then if I remove .NET 6 from framework and reinstall the template and try to create it, a blank screen is displayed.

If you can't reproduce, I will send you the template.

I think the user may encounter this bug if they upgrade the .NET version to 7 and delete .NET 6.
The workaround for template authors is to add the .NET Framework version, which is always installed with VS.
But the behavior of VS is very obscure. It would be cool to make it more clear.

In any case, I think it's best to always display the template in VS, even if it can't be created correctly (like Rider does).
If there is an error in the template, Rider will create the template, but not replace the strings in the .csproj/cs files