New project "Console App" is not clear, should be in line with C# New Project dialog options

[abelbraaksma]

In recent versions of Visual Studio 2017 I find myself reading over the options in the "New Project" dialog and seeing "Console application (.NET Core)", then "Console application (.NET Standard)". My mind than expects "Console application (.NET Framework)", but it isn't there.

I actually started out writing the original issue thinking it completely disappeared, but it just takes a moment to see that the options are well specified and you should just try them out. It then turns out that the option without any affix, is the .NET Framework option.

This is what C# shows:

And this is what F# shows:

Expected behavior

I think it suffices if we just add the suffix "(.NET Framework)" where applicable.

Related information

Seen in VS2017 with recent updates, Professional edition and Preview editions.

[matthid]

An easier workaround might be (without actually testing anything). Creating a netstandard class library and changing <TargetFramework>netstandard20</TargetFramework> to the framework you need.

[abelbraaksma]

@matthid that is a good tip, thanks:+1:

[charlesroddie]

Adding (.NET Framework) as in the C# projects would make sense. A more radical approach would be to remove the .Net Framework ones. It's rare now for those to be needed or preferable. And beginners would be confused by having to make a choice. Even many professional .Net developers I meet don't understand Framework/Core/Standard.

[cartermp]

Eventually, I’m thinking we’ll label those as “(Legacy)” and have new templates use the .NET SDK, labeled appropriately for Core/Standard/Framework.

[abelbraaksma]

@cartermp: I think there are two things here. One is to be clear to users in the present situation, which means aligning naming to the C# naming, which seems pretty unambiguous (were ours isn't).

The second being to improve on this, i.e., calling things Legacy or something. For me, that sound too strong, since .NET Framework has a massive existing user base and using the word "Legacy" may cause ringing of all kinds of alarm bells with people thinking their chosen platform is out of the support window (end-of-life or how do we call that). I doubt that is the case anytime soon. I for one have dozens of projects that are now in, and will continue to be in, .NET Framework.

Labeling this vFuture may lead the simple thing, renaming the labels in the resource files, to be postponed. I think that should be something that needs fixing asap, esp. wrt new users. If that could be done in 15.7 or 15.8 that would be great.

The rest (rethinking the naming altogether, or the availability of templates in each and every framework) could then be vFuture, wouldn't you agree? ;)

A more radical approach would be to remove the .Net Framework ones. It's rare now for those to be needed or preferable.

@charlesroddie: could you define or substantiate "rare"? Since I rarely see projects in the new frameworks, often simply because dependencies, or existing web or app frameworks, haven't moved on yet. For anything non-dependent and entirely new, that may be true though.

[cartermp]

This is something we can consider for 15.8, but not for 15.7. Let me take a look

[cartermp]

Long-term naming is long-term, though. And I do indeed intend on making "Legacy" the moniker, and hidden behind a folder, because the intention is to replace all .NET Framework-related templates today with .NET SDK-style templates which target .NET Framework. That is, something to the extent of:

Console Application (.NET Core)
Console Application (.NET Framework)
Library (.NET Standard)
Library (.NET Framework)
/Legacy/Console Application
/Legacy/Library

etc, all using the .NET SDK

[charlesroddie]

@abelbraaksma could you define or substantiate "rare"? Since I rarely see projects in the new frameworks, often simply because dependencies, or existing web or app frameworks, haven't moved on yet. For anything non-dependent and entirely new, that may be true though.

The argument would be that existing .Net Framework projects can use .Net Standard libraries and the need to create .Net Framework libraries would therefore be rare. And new console applications would be non-dependent. However your original suggestion makes sense, together with updating the Framework projects to the .NET SDK.

[cartermp]

@abelbraaksma in #4977

[abelbraaksma]

@cartermp that looks already much better. Maybe you can align the names as well? Library vs Class Library and Console App vs Console Application? In C# these are also aligned. And I miss some variants. There should be three of each, right?

[cartermp]

What variants?

[abelbraaksma]

@cartermp: 3 + 3 = 6, I see 4. I mean, I'd suggest something like this:

• Console App (.NET Core)
• Console App (.NET Standard)
• Console App (.NET Framework)
• Class Library (.NET Core)
• Class Library (.NET Standard)
• Class Library (.NET Framework)
• Tutorial (.NET Framework)

Instead of "Class Library", which is C# naming, there's nothing wrong with the more generic "Library", as libraries in F# can be class libraries, function libraries etc.

[cartermp]

The most possible for F# in VS today is 10 (assuming the addition of the tutorial project the .NET SDK):

• Console App (.NET Core)
• Console App (.NET Framework)
• Class Library (.NET Standard)
• Class Library (.NET Core)
• Class Library (.NET Framework)
• Tutorial (.NET Core)
• Tutorial (.NET Framework)
• ASP.NET Core Web Application
• MSTest Test Project (.NET Core)
• xUnit Test Project (.NET Core)

However, we've seen considerable confusion about Class Library (.NET Core) from customers on the C# side, despite it being a valid way to do things, just because it wasn't clear what the difference between that and .NET Standard was. And given that .NET Standard is the mainline option for libraries, I'd rather not give F# customers that confusion. So, assuming .NET SDK changes in addition to those in #4977, the list would look like this:

• Console App (.NET Core)
• Console App (.NET Framework)
• Class Library (.NET Standard)
• Class Library (.NET Framework)
• Tutorial (.NET Core)
• Tutorial (.NET Framework)
• ASP.NET Core Web Application
• MSTest Test Project (.NET Core)
• xUnit Test Project (.NET Core)

Unfortunately, adding things into this dialog is anything but straightforward. The infrastructure does not lend itself well to the problem of, "I want to define a template to be available under N areas, where N > 0, and also have that template appear in M parent views, where M > 0". In short, things get duplicated and it's a mess when that happens. I think that the above list can be seen as a reasonably accomplishable aspiration, where the (.NET Framework) moniker is applied to the appropriate templates by dev15.8, and the rest done in a future release.

[charlesroddie]

@abelbraaksma Instead of "Class Library", which is C# naming, there's nothing wrong with the more generic "Library"

Agreed

Console App (.NET Standard)

That doesn't make sense. How would you run this?

@cartermp .NET Standard is the mainline option for libraries

Agreed

Tutorial (.NET Core), Tutorial (.NET Framework)

We shouldn't present users with a confusing and irrelevant decision to make before they can load a tutorial. Especially as it will be mostly beginners looking for a Tutorial. Just choose one and name it "Tutorial".

[cartermp]

We shouldn't present users with a confusing and irrelevant decision to make before they can load a tutorial. Especially as it will be mostly beginners looking for a Tutorial. Just choose one and name it "Tutorial".

Agreed. Though we'll only be able to make one use the .NET SDK once FSI works properly with .NET Standard references.

[abelbraaksma]

This discussion has clearly shown me that I'm not aware of all the differences and limitations of the different frameworks. But I've only done serious work in .NET, I should expand my horizon. I have some reading ahead of me I think (thanks for pointing that out about Standard, @charlesroddie).

About the difficulty of maintaining templates, I thought that was something trivial to do. Apparently not, in which case I fully agree to postpone that to some future release.

[cartermp]

Closing this, as the confusing piece has been addressed.

I've created #5155 to track templates for dev16/Visual Studio 2019, where some of this discussion has been heading.