Suggestion: location of global.json (and like files), should they move to a .dotnet subfolder?

[smoothdeveloper]

Asking if global.json (and other similar files) could be resolved from a .dotnet subfolder rather than at the root of repository.

Motives:

1. root folder is a crowded place
2. global.json is to generic of a name, doesn't convey anything related to dotnet, moving it to a folder, and maybe renaming it?

Sorry if this issue has been brought up, tried to search, and it has been bothering me due to point 1.

[livarcocc]

@KathleenDollard

[KathleenDollard]

Let's get this in our backlog, as part of the global.json replacement.

@smoothdeveloper what else would you want in this folder? We would be rather lonely as the only file there

[tebeco]

local tools ?
global.json having an entry key to, for example a ps1 (because xplat / powershell core is a dotnet tool)
that way "dotnet tool restore" would run something like a "post tool restore"

that would replace the restore.cmd that is used by dotnet/arcade

goal :

git clone foo
cd foo
dotnet tool restore
dotnet build

having options near the sdk like "install locally if sdk not detected" (by default not visible/false)

would allow ANY dotnet invocation in the repo to check that sdk / download it / put it in .dotnet repo folder
that would use the dotnet-install.ps1 (again powershell core or directly coded in the cli)

that would unlock things like

dotnet sdk update <== on long running build agent
dotnet sdk update --local/global

[smoothdeveloper]

@KathleenDollard thanks for your feedback.

Let's get this in our backlog, as part of the global.json replacement.

Can I have a pointer to what this is about?

@smoothdeveloper what else would you want in this folder? We would be rather lonely as the only file there

I'm not aware of additional files (not using dotnet core sdk extensively yet) but I can foresee more will eventually come, in which case, it would be neat for some of the considerations in the issue to be taken in account.

[KathleenDollard]

@smoothdeveloper I agree with you about global.json being a poor name, and we have an item on our backlog to look at modifying our approach to SDK selection. The primary driver for renaming/possibly moving/ etc is that we have an issue with how fallback occurs that we can't solve without a breaking change. Not meaning to be vague, .NET looks up the tree until it finds a global.json file. Since there are orthogonal items in global.json, you might have a file intended for one purpose, block one intended for another purpose.

[RehanSaeed]

I suppose the dotnet tool manifest files dotnet-tools.json file could also go in there.

[tebeco]

Taking the opportunity to bump that @KathleenDollard

If you attempt to install a new computer with only dotnet 6.0

git clone https://github.com/dotnet/sdk
restore.cmd
build.cmd

previously we were supposed to do things like:

$env:DOTNET_SKIP_FIRST_TIME_EXPERIENCE=1
$env:DOTNET_MULTILEVEL_LOOKUP=0

$env:DOTNET_ROOT=$env:DOTNET_INSTALL_DIR
$env:DOTNET_MSBUILD_SDK_RESOLVER_CLI_DIR=$env:DOTNET_INSTALL_DIR

$env:PATH=$env:DOTNET_INSTALL_DIR;$env:PATH
$env:NUGET_PACKAGES=...........

issue being that the main branch is on dotnet 7.0.100-xxxxx-alpha which is not installed with an MSI
Currently Vs2022 preview don't seems to use these variable anymore, leading into the impossibility to open the main branch without manually installing the dotnet-sdk-7.xx.msi

That also mean that it will possibly break dotnet/arcade startvs.cmd that are used in dotnet/aspnetcore etc ...

It would be great if the .dotnet folder would be automatically used as a location to look at for possible SDK match

Bonus:

• dotnet sdk as a dotnet tool
  • would allow to version
  • restore from single CLI command
• would need few change to forward call like dotnet build to the dotnet.dll from that folder location