Figure out how to use the runtime output directly as the test shared framework

[weshaggard]

Today we have a runtime output "bin\runtime\netcoreapp-Windows_NT-Debug-x64" and we have a runtime folder "testhost\netcoreapp-Windows_NT-Debug-x64\shared\Microsoft.NETCore.App\9.9.9" output so that we can run our tests as a shared application. The contents of those 2 directories are currently duplicated. We should figure out a way to hard-link the entire directory (not just the individual files) or a way to configure dotnet.exe such that we can tell it to use our runtime output path as the shared framework.

cc @karajas

@gkhanna79 do you know if there is any way to configure dotnet.exe to use a particular folder as the shared framework? If not do you think that is a feature request that might be doable?

[gkhanna79]

Currently, there is not a way to specify that since the host has bunch of invariants built around it being next to shared folder.

Is there a reason you cannot use the dotnet.exe from the second location above?

[weshaggard]

Is there a reason you cannot use the dotnet.exe from the second location above?

If we do that how can we specify the additional test directory. We essentially have the shared framework and test output directory we need to be able to resolve from both.

[gkhanna79]

Are the additional test artifacts to be consumed part of the app.deps.json?

[weshaggard]

No they aren't part of the app.deps.json file. The deps file we have today only contains bits from the shared runtime folder. We don't generate a unique deps file for each test project, we could potentially consider doing that if necessary but I would prefer it if we don't need to.

[ViktorHofer]

related to enabling VS Test Explorer where we could also specify a custom shared runtime folder instead of directing to our dotnet.exe in corefx. But I think there is a lot of value in fixing the original issue itself as the current duplication of the testhost folder is unfortunate.

@danmosemsft who is currently the right person to contact for such a feature addition to dotnet.exe?

[danmoseley]

@ViktorHofer it comes from the core-setup repo, so probably would be an issue there. @steveharter would be a good person to talk to about it.

[ViktorHofer]

@ericstj do you have an idea how to proceed here? Ideally I would like to get rid of the custom dotnet in the testhost folder and just use the dotnet in /.dotnet together with the runtime folder which is currently deeply nested in shared/Microsoft.NetCore.App/9.9.9/. Does it make sense to meet with the core-setup team to discuss what can be done here?

[ericstj]

Yeah, I just hit this yesterday when trying to remove buildtools and ran into the deps.json generation task which is another ugly symptom of this problem. Let's meet with @jeffschwMSFT and @vitek-karas to discuss.

Do you think you could write up a) our key requirements b) problems with current approach?

[ViktorHofer]

Sure, will put that on my agenda for today.

[wtgodbe]

@ericstj @ViktorHofer was there any update here?

[ViktorHofer]

For getting rid of the dotnet in the testhost folder I opened https://github.com/dotnet/core-setup/issues/4915. Getting rid of the runtime directory is to-do and is tracked by this issue. @wtgodbe do you want to pick that issue? The goal is to get rid of the runtime directory (disabled the binplacing into it) and just have the testhost directory.

[wtgodbe]

Sure thing, I'll look into it when I get a chance.

[ViktorHofer]

@wtgodbe I took care of this in dotnet/corefx@b1619b1, I hope you don't mind.

[ViktorHofer]

A possible solution for this is tracked in https://github.com/dotnet/core-setup/issues/4809