Developing a shared framework requires admin rights
See original GitHub issueWe 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 becauseC:\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
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:43 (42 by maintainers)
I think this sounds reasonable. To make the behavior predictable I would add:
.runtimeconfig.json
can specify this value. Values specified in framework.runtimeconfig.json
will be ignored..runtimeconfig.dev.json
. If the value is in both, the lists will be merged.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.