Developing a shared framework requires admin rights

We develop the Microsoft.AspNetCore.App shared framework in https://github.com/aspnet/AspNetCore, and it is currently difficult for our contributors to actually run tests against the shared framework. Corehost only resolves shared frameworks from $DOTNET_ROOT/shared/Microsoft.AspNetCore.App/ or the global location, which means there are basically two options for our contributors:

• Install a copy of the .NET Core SDK and runtimes in $repoRoot/.dotnet. This is less than ideal because Visual Studio won’t find the runtime because C:\Program Files\dotnet\dotnet.exe is typically on PATH first.
• Build the shared framework locally an install in to $DOTNET_ROOT. This is also less than ideal because it pollutes the .NET Core installation with an un-released runtime, and either requires admin rights to C:\Program Files\ or requires you to configure a machine to use dotnet.exe from a user-writable location. (Again, also difficult if you don’t have admin privileges).

Request Is there way we could have corehost resolve shared frameworks from a local directory? For example, could we add a shared framework probing path in runtimeconfig.dev.json?

Ideally, I’d love for Visual Studio to pick up the local builds of our shared framework without needing administrative access to a machine, and overriding a handful of environment variables.

cc @davidfowl

[vitek-karas]

I think this sounds reasonable. To make the behavior predictable I would add:

• Only the application’s .runtimeconfig.json can specify this value. Values specified in framework .runtimeconfig.json will be ignored.
• For simplicity the option would also be supported in .runtimeconfig.dev.json. If the value is in both, the lists will be merged.

[vitek-karas]

I personally think that this is something which VS should have an option for, ideally as an MSBuild property (but then it’s a chicken and egg problem I guess). The fact the VS forces the use of the same dotnet on all projects in it feels wrong.

I think that if the runtime would be to support this, then the right place would be the global.json as it already handles a similar concern for SDK. Unfortunately implementing this could be relatively ugly. I would have to look into this some more.