Sdk: Support changing the default language

[isaacabraham]

I would like to be able to default the dotnet sdk language to F#. Currently we have to remember to put -lang F# with all standard project templates. I would like to be able to set a global flag that changes the default to F#.

[aspnetde]

Yes, please!

[baronfel]

Earlier in the dotnet SDK lifecycle this was supported, and it was wonderful. This is one of those death-by-1000-cuts issues that don't impact the mainstream but when they do hit are very annoying.

[TimurZanagar]

Would be great!

[eiriktsarpalis]

Would be nice to see this added back.

[jdh30]

Yes.

[uzochiapa]

Yes. This will be awesome.

[LukeBurgessYeo]

Yes please.

[forki]

A recommendation from Twitter was to use global.json. That file is already used to determine the sdk version and you can put it in the root of your or in the root of a project.

[avestura]

I barely create new C# projects nowadays and all my new dotnet projects are in F#. Yes please, I want this!

[forki]

As a follow up from the Twitter discussion. So far the global.json is only read in the step that decides which sdk version to use. Not in the dotnet new command itself. Maybe it would be possible to convert such values in global.json into environment variables for the spawned processes. So dotnet new and all other commands would not need to read the global.json again.

[dasMulli]

Local tools use a .config/dotnet-tools.json. There could be a .config/dotnet-new.json which could then be recursively searched.

do note that MSbuild also alreeady used global.json for other things (MSBuild SDK versionos) which also affects VS for non-.net core projects so the ideaof having it for SDK resolution only was already made impossible.

[enricosada]

Another option (smaller implementation but more specific, less bikeshedding) is to use an env var.

That allow a global per user configuration.

I think the dotnet new is something really useful for developers as cli.
IDE/editor have their way to specify a default preference.
To be scripted programmatically the -lang param should be always passed to be safe

A possible implementation (require rebase) is done in an old PR https://github.com/dotnet/cli/pull/5679

Having that env var doesn’t prevent a more comprensive .netconfig file later, when there is an agreement on this bigger scope

Using current global.json I think is not correct, because current behavior is to stop at first found, so cannot do a shared per user atm.
Another option is allow a per user global.json where I can specify that preference and is always loaded (overrriden by repo specific global.json).
Like other tools, a config file in user folder. Maybe call it .net :)

[toburger]

+1 for the env var

[khellang]

I remember filing this issue a few years ago... 🙈 https://github.com/dotnet/sdk/issues/4950

[enricosada]

I remember implementing it twice few years ago, one for project.json dotnet new ( sdk < 1.0) and one for dotnet new based on .NET Templating ( sdk >= 1.0 ) who were based on different templating engines.

It got sidetracked waiting for the user config file (and the inevitable bikeshedding) :( but that's something understandable who happen in development often

Anyway, i rebased and sent the PR https://github.com/dotnet/sdk/pull/10666 here targeting latest master
But i think this repo mean sdk 5.x

It will be awesome if we can have it in the LTS also, so next sdk 3.1.200.
So i sent also PR https://github.com/dotnet/cli/pull/13237 to pull it in .NET Core Sdk 3.1.2xx
I think dotnet/cli it's the right repo for 3.1.2xx released but dunno with dotnet/toolset and dotnet/sdk, so happy to rebase as needed

As a note, the env var can be temporary, until a config file or whatever exists.
To continue having the env var after the config file exists, is not that much maintenance either, so low risk

[dasMulli]

If only we had a config system that could pull values from ENV but also would be able to use files as well.. oh yeah Microsoft.Extensions.Configuration 😄

if a .netconfig or similar is going to happen, i'd be all for a way to specify various SDK / CLI / * configs in a way that would be simlar to ASP.NET Core configuration. While i'm not such a huge fan of the syntax, something like NETSDK_Templating:DefaultLanguage (or __ instead of :) would feel naturally in the m.e.configuration world and we would all know (or be able to learn) what the JSON / XML / * equivalent would be.

[cartermp]

Just to communicate a discussion that we had about this:

The proposed solution by @enricosada is good for now. We do want to design and build a long-term configuration solution that won't rely on environment variables (which @enricosada mentions!). We can't guarantee that it would make it for .NET 5, so we'll try to move forward with the environment variable in the interim. Once there is a long-term solution in place, we'll ask folks to use that instead, and we'll cease support for the environment variable (even though it may continue to work in the future).

Thanks @enricosada for the proposed change 🙂

[enricosada]

the DOTNET_NEW_PREFERRED_LANG=F# env var is supported in the latest released .net 5 sdk preview3 ( 5.0.100-preview.3.20216.6 )

C:\temp5>dotnet --version
5.0.100-preview.3.20216.6

C:\temp5>set DOTNET_NEW_PREFERRED_LANG=F#

C:\temp5\5_p3>dotnet new lib -n l1
The template "Class library" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on l1\l1.fsproj...
  Determining projects to restore...
  Restored C:\temp5\5_p3\l1\l1.fsproj (in 106 ms).

Restore succeeded.

[cartermp]

I'll close this one out. Thanks @enricosada!

[enricosada]

Thanks @cartermp !

As a note, the env var should also be supported in the next .NET Core Sdk LTS 3.1.3xx .
I'll double check when that sdk is released, but is already merged.