Write guidance on how to launch (non apphost) apps

[richlander]

There are scenarios where apps need to be launched with dotnet host. The big question is how to find the host, with the two obvious places to look being:

• PATH
• apphost configuration (DOTNET_ROOT, /etc/dotnet/install_location, ...)

I don't believe we've documented this.

This question may be similar to how one locates node from code given the use of nvm. I haven't looked at that pattern/guidance, but it seems similar.

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

There are scenarios where apps need to be launched with dotnet host. The big question is how to find the host, with the two obvious places to look being:

• PATH
• apphost configuration (DOTNET_ROOT, /etc/dotnet/install_location, ...)

I don't believe we've documented this.

This question may be similar to how one locates node from code given the use of nvm. I haven't looked at that pattern/guidance, but it seems similar.

Author:	richlander
Assignees:	-
Labels:	area-Host
Milestone:	-

[vitek-karas]

Depends where you want to do this. In a script something like which dotnet is probably a good answer.
From code you could use nethost library, it finds hostfxr for a given application and from there you can go up 2 levels where dotnet should live. nethost will look at the same things as apphost (if used correctly): https://github.com/dotnet/runtime/blob/main/docs/design/features/native-hosting.md#new-host-binary-for-finding-hostfxr

[jaredpar]

This comes up frequently in the C# compiler source code as there are a number of cases where we need to launch a managed process. Effectively we have csc.dll and need to launch it as a process but that requires us first finding a dotnet to use. The pattern for finding dotnet hasn't been documented and as a result our implementation has been derived by looking at ENV variables set by the runtime, reviewing patterns in other parts of the .NET SDK, etc ... Basically trying to draw from other examples.

There are generally two scenarios I think about in this area:

1. How the C# compiler is executed in the .NET SDK. Essentially what should be the experience when the customer types dotnet build?
2. How the C# compiler is executed within our own infrastructure. There is a strong incentive for our own infra to be able to control the dotnet that is used when running tools in the SDK. For example the runtime repo uses this to effectively dogfood the latest runtime against SDK tools. This is very valuable.

After thinking this through this morning I think the right approach going forward is to only consult $PATH. Basically find the first dotnet instance and use that. This mostly closely mirrors how a customer would run our own tooling and is most likely to line up with their expectations. Basically dotnet build uses the same host as dotnet exec csc. Further I think this should apply to any tool in the SDK, not just the compiler.

That would have the following impact on our product and testing:

1. Our product code which today consults $DOTNET_ROOT or $DOTNET_HOST_PATH for the purpose of finding dotnet should cease doing so. Instead consult $PATH only.
2. Our infra code which was trying to insert a dotnet for testing / dogfood purposes by changing values like $DOTNET_ROOT should cease doing so. Instead that specific infra run should prepend the directory that contains the recently built dotnet to $PATH

[jaredpar]

If you're asking what is $DOTNET_HOST_PATH I had the same question. In researching through our code I believe that it is effectively an arcade invention. It's a mechanism for us to control where arcade puts dotnet into our enlistments. Unfortunately this seems to have filtered into our actual production code as well. That feels wrong.

Perhaps I have the history / intent of this variable wrong and if so please correct me 😄

[vitek-karas]

I think DOTNET_HOST_PATH is something SDK uses - there are many use cases in that repo: https://github.com/search?q=repo%3Adotnet%2Fsdk%20DOTNET_HOST_PATH&type=code
I think it uses it to pass the location of the host from the parent to the child processes, so that child processes use the same SDK/runtime install which was used to run the top level command. It's possible Arcade uses it as well. But I could be wrong.
For the usage inside SDK though we might want to keep looking at DOTNET_HOST_PATH. The problematic scenario is for example:

/my/private/install/dotnet build

This should spawn the child nodes for msbuild, csc and so on using the runtime/SDK from /my/private/install and not look for it on the PATH. For example if I have only installed 7.0 globally (so it's on PATH) but then I run /my/private/8.0-preview.7/dotnet then things should just work.

Unless we also change SDK to modify PATH for its child processes.

Outside of SDK I agree that PATH is probably the best approach. Installers, scripts and users will set PATH to point to dotnet.exe because we tell them to and because they need it anyway (so that they can run dotnet build and similar). It will also be set in CI systems to point to the dotnet from the SDK they want used and so on.
DOTNET_ROOT in itself is not enough and there's much more involved algorithm how to find the runtime if that variable is not set. That's basically what nethost implements.

[jaredpar]

I think DOTNET_HOST_PATH is something SDK uses -

I 100% agree it uses it, I'm questioning why it does that. The $DOTNET_HOST_PATH does not appear to be a variable that we support as a product. The only places I can find where it is set is through arcade, not the customer facing product. As such I'm questioning whether or not those uses in the SDK are correct and at the moment I don't believe they are.

For the usage inside SDK though we might want to keep looking at DOTNET_HOST_PATH.

Why though? I'm struggling to see what value it provides vs. always using $PATH and just modifying that to use it.

If we do want a variable that special cases the SDK though then

1. We need to universally use it. Today it's hit and miss from what I can see.
2. Having it called DOTNET_ feels wrong. This is for effectively our internal testing purposes. Giving it a name like DOTNTE_ feels like we're elevating it to an actual .NET feature.

[vitek-karas]

For the usage inside SDK though we might want to keep looking at DOTNET_HOST_PATH.

Why though? I'm struggling to see what value it provides vs. always using $PATH and just modifying that to use it.

I realized this as well after I sent the response. It would be simpler if SDK just modified PATH for its child processes I assume and then everything could use `PATH.

Unfortunately PATH is not great to use - especially on Windows. Historically our guidance (given to us by other teams) was to try to not parse PATH and make sense out of it. But maybe it's OK for just spawning processes, since we can let the OS do it for us I assume.

[jaredpar]

Historically our guidance (given to us by other teams) was to try to not parse PATH and make sense out of it

Yeah I'm not really thrilled about parsing $PATH either. Ended up just stealing the code from msbuild that does it. This is essentially how our entire build tool stack works today so it seems like a good source to draw some code from.

Would be nice to have an API for FindOnPath but that seems unlikely. Also I'd still have to polyfill that for downlevel targets.

@rainersigwald, @baronfel: have you all ever considered exposing a FindToolPath on ToolTask or MSBuild APIs in general that we could use to find dotnet? That way the logic for parsing $PATH is centralized.

[rainersigwald]

It's come up before but I couldn't find an issue so dotnet/msbuild#9018.