dotnet config

[richlander]

Add global user configuration

It happened! We just past that moment where we absolutely need dotnet config. It's time to go build it, I propose for 3.0.

The key scenario that affects a lot of people is installing .NET Core preview SDKs. They are very hard to manage.

Git has git config as documented at git config. We need something kinda/sorta the same.

global.json would still override these settings, where there is overlap.

Basic Scenarios

• [bool] Use previews by default
• [string] Use this SDK version (same concept as global.json) -- need more options on min and ranges and such.
• [string] Use this --framework as the default for dotnet new (for example, netcoreapp2.2). This one might need both a default and a way to say "Oh, I want netstandard2.0 for the classlib template). latest-stable would be an awesome durable default.

Some folks would want to opt out of previews by default. Others would want the SDK preview, but want to default new projects to stay with the stable runtime/TFM. Those are both valid lifestyle options. I would choose the second choice, but I more people to choose the former.

Advanced Scenarios

• [string] Use this --configuration by default (for example release, debug), potentially with different values for run, build, publish and pack. For example, I'd set release for publish and pack and go with the default for other scenarios.

More ideas, requiring more thought

• [string] Use this --framework as the default for dotnet run -- useful for multi-targeted projects.
• [array of strings] Use these flags for dotnet test by default (like the logger)
• [array of strings] Use these flags for dotnet publish by default (like self-contained of cross-gen)
• [array of strings] Always build for these RIDs
• [array of key/values] Environment variables to set at dotnet run process launch

[NickCraver]

I'm unclear how --framework specifically would work since we'd be configuring possibly outside the subset of available options for any given project (or even projects in the same solution). What happens when it's not one of the values? Or when it's just 1 of 3? Seems like that could get confusing and needs a lot of thought. The rest looks very appealing though, especially the global SDK defaults and preview control.

Looking forward to this!

[richlander]

I'm unclear how --framework specifically would work since ...

Yes, I thought of that. --framework for dotnet new is a slam dunk. It is harder for run for exactly the reasons you raise. I wanted to offer a range of ideas and see if there are people that have a lot of projects that have the same frameworks specified. This idea would be a benefit for that case. I doubt we'd implement this particular idea in the first round.

Keep the feedback coming!

[normj]

Like the idea of this feature. Here are some suggestions to add to the config list.

• Ability to configure additional package store directories. I think custom package stores are going to become a big deal for us.
• Ability to configure the .NET Global Tools install folder. This could be useful in a build environment where a build script could set this to a folder in the workspace. Then the build script could install a tool without worry of making a change that could affect other build scripts. I would also have helped me during tool development not affecting my normal non-tool development.
• Ability to set the RID for the machine. This could be helpful for distributions that don't report their RID in the standard way .NET Core looks for. This is the case for Amazon Linux.

[richlander]

@normj -- Great feedback ...

configure additional package store directories ...

Is startup hook an option to replace that?

Ability to configure the .NET Global Tools install folder

are you referring to --tool-path for your second path?

[array of strings] Always build for these RIDs

This is the same as your third point, yes?

[normj]

Startup hook looks really interesting and I need more time to digest it but I don't see how it would be able to adjust the additional probing path for the started process when the hook has been called and I don't want to get in the business of recreating the .NET Core dependency look up path.

I had forgot about --tool-path, that does solve that config need.

What I was looking for in the config for RID was not telling what RID to build for but override the .NET Core logic to determine what the current OS's RID is and use this config setting.

[livarcocc]

cc @nguerrera @johnbeisner

It was considered for 3.0 but considered below the cut line by the directors. Given all the work that we already have for the release, I don't believe we can properly fund it.

Also, I believe @KathleenDollard already did a write up for this somewhere. Maybe she can share that here.

[clairernovotny]

One initial thought

• would dotnet config be for the user profile or for a project/directory? If for the user profile, then my concern is differences between machines (works on my machine, breaks elsewhere, etc). While global.json would override, for some things that seems too subtle.

[nguerrera]

When discussing this before, we imagined a configuration hierarchy of repo > user >system. Just like git config vs git config --global vs. git config --system

It's conceivable that global.json could be replaced entirely by this new store of configuration with SDK version selection just one of its options.

That said, one thing that significantly impacts the design and implementation challenge here is that we need to read the SDK selection options in native code before any managed code in the SDK can run.

[clairernovotny]

I think one difference between git and dotnet is one affects how code is checked out/in, while the other affects build.

I think it's okay to put options for default new templates at the user/system level, but I would be worried about putting SDK/preview things at that level for fear of different builds per machine. I think certain settings should only be repo level, the ones that affect build/runtime behavior.

[nguerrera]

We could think about certain options being repo-only, but that feels too rigid to me. I think I'd prefer a way to opt out of any global configuration in the repo configuration.

Returning to this:

That said, one thing that significantly impacts the design and implementation challenge here is that we need to read the SDK selection options in native code before any managed code in the SDK can run

I just want to make it clear that the first two basic scenarios in this issue description are impacted by that. The code to honour those needs to live in native code in dotnet/core-setup.

[wli3]

but that feels too rigid to me. I think I'd prefer a way to opt out of any global configuration in the repo configuration.

One example of this scheme is requiring signing for packages used. It should be a global flag. And you can optout per repo (although this config is in nuget)

[swaroop-sridhar]

configure additional package store directories ...
Is startup hook an option to replace that?

My understanding is that @normj is only asking for a new way to use an existing feature.
That is, the CLI already supports additionalProbingPaths in rutimeconfig.json and dotnet exec –additionalProbingPaths … switch. The request is to add dotnet config additionalProbingPaths. Seems like a reasonable option to add to dotnet config

The use case described by @normj is simple -- the additional directories to probe is known statically before the app starts, and doesn’t change. If we learn more complex/dynamic use-cases, we can provide samples for solving them using more powerful tools like startup-hook, AssemblyLoadContexts, NativeLibrary APIs, etc.

CC: @richlander

[vitek-karas]

There's a related discussion in dotnet/core-setup#4809.
That one is about VS using the dotnet.exe from global location always - so we could use global.json (and/or the higher lever configs) to tell dotnet.exe where to look for frameworks/SDKs.

Regarding the need for this to be implemented in native code: yes that is absolutely true, most of these options would affect the algorithms which are in either dotnet.exe, hostfxr or hostpolicy. The good news is that hostfxr and hostpolicy already have JSON parsing capabilities, in fact they already parser global.json. The bad news is that for some of these features to work we would need to add JSON parsing capability (and global.json parsing) into dotnet.exe as well. Technically this is not that hard. The tricky bit is actually updating dotnet.exe, so far we've never done that as far as I know.

[vitek-karas]

Other related issues:
dotnet/core-setup#3623 - ability to ask for stable-only versions of SDK in global.json
dotnet/core-setup#679 - ability to specify version ranges for SDK in global.json

[wli3]

More ideas, requiring more thought

[string] Use this --framework as the default for dotnet run -- useful for multi-targeted projects.
[array of strings] Use these flags for dotnet test by default (like the logger)
[array of strings] Use these flags for dotnet publish by default (like self-contained of cross-gen)
[array of strings] Always build for these RIDs
[array of key/values] Environment variables to set at dotnet run process launch

1. I don't like the dotnet config to enable more knobs. We could make existing environment variable to be config. But we should be very conscious for every single new config. Flags does not compose and it will potentially double the test matrix. String and "programmable" configs are even worse. And next step we would need to build tooling around a tool config.

2. Most of the above "config" can be done by customize msbuild in csproj. We should have only one place to do it. If it is hard to do so, we should put effort to make it easy.