Add guidance for running .NET apps #346
Conversation
Co-authored-by: Jan Kotas <[email protected]>
proposed/net-app-launch.md
Outdated
| * Executable names are preserved in the command line, meaning apps can be easily recognized based on their names. | ||
| * Because the apphost is a native binary, native assets like manifests can be attached to them. | ||
|
|
||
| The apphost will generally use a global install of the .NET framework, where install locations are defined by [install locations](accepted/2021/install-location-per-architecture.md). |
There was a problem hiding this comment.
| The apphost will generally use a global install of the .NET framework, where install locations are defined by [install locations](accepted/2021/install-location-per-architecture.md). | |
| The apphost will generally use a global install of the .NET runtime, where install locations are defined by [install locations](accepted/2021/install-location-per-architecture.md). |
We should say ".NET", ".NET runtime" or ".NET Core". ".NET framework" is misleading.
proposed/net-app-launch.md
Outdated
|
|
||
| The apphost will generally use a global install of the .NET framework, where install locations are defined by [install locations](accepted/2021/install-location-per-architecture.md). | ||
|
|
||
| The .NET framework path can also be customized on a per-execution basis. The DOTNET_ROOT environment variable can be used to point to the custom location. Details for all DOTNET_ROOT configuration can also be found in [install locations](accepted/2021/install-location-per-architecture.md). |
There was a problem hiding this comment.
| The .NET framework path can also be customized on a per-execution basis. The DOTNET_ROOT environment variable can be used to point to the custom location. Details for all DOTNET_ROOT configuration can also be found in [install locations](accepted/2021/install-location-per-architecture.md). | |
| The .NET runtime path can also be customized on a per-execution basis. The DOTNET_ROOT environment variable can be used to point to the custom location. Details for all DOTNET_ROOT configuration can also be found in [install locations](accepted/2021/install-location-per-architecture.md). |
proposed/net-app-launch.md
Outdated
|
|
||
| The .NET framework path can also be customized on a per-execution basis. The DOTNET_ROOT environment variable can be used to point to the custom location. Details for all DOTNET_ROOT configuration can also be found in [install locations](accepted/2021/install-location-per-architecture.md). | ||
|
|
||
| In general, the best practice for using `DOTNET_ROOT` to set the framework location for an app is to: |
There was a problem hiding this comment.
| In general, the best practice for using `DOTNET_ROOT` to set the framework location for an app is to: | |
| In general, the best practice for using `DOTNET_ROOT` to set the runtime location for an app is to: |
|
Should this live in the official docs instead? |
I debated this. I also wonder if we should put the info in the linked install-location docs. I'd be fine with either answer. |
https://learn.microsoft.com/en-us/dotnet/core/deploying/ has similar content that has partial overlap. I think it would best to fold this content into that doc. For example, the official doc just says "You can run this executable directly instead of calling dotnet .dll, which is still an acceptable way to run the app." without explaining the tradeoff and giving a strong recommendation. |
|
|
||
| In general, the best practice for using `DOTNET_ROOT` to set the runtime location for an app is to: | ||
|
|
||
| 1. Clear DOTNET_ROOT environment variables first, meaning all environment variables that start with the text `DOTNET_ROOT`. |
There was a problem hiding this comment.
I'd link to https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-environment-variables#dotnet_root-dotnet_rootx86-dotnet_root_x86-dotnet_root_x64 since I don't think it's widely known that there are multiple variations of DOTNET_ROOT
There was a problem hiding this comment.
Agree. That adds context to why this needs to be done.
| In general, the best practice for using `DOTNET_ROOT` to set the runtime location for an app is to: | ||
|
|
||
| 1. Clear DOTNET_ROOT environment variables first, meaning all environment variables that start with the text `DOTNET_ROOT`. | ||
| 2. Set `DOTNET_ROOT`, and only `DOTNET_ROOT`, to the target path. |
There was a problem hiding this comment.
Might be worth mentioning that if you are a tool launched by dotnet or MSBuild (since 18.x), you can determine the path from DOTNET_HOST_PATH (documented at https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-environment-variables#dotnet_host_path)
There was a problem hiding this comment.
Note: that DOTNET_HOST_PATH doc is also being updated: dotnet/docs#49422
There was a problem hiding this comment.
No: DOTNET_HOST_PATH is an SDK-only property. You can only rely on it if you were launched from the SDK. Since only things which ship in the SDK can count on being launched by the SDK, this should not be a public guarantee. It is an implementation detail for SDK apps.
There was a problem hiding this comment.
Yes, I know that's SDK only property, I was just thinking it's a common scenario and might be good mentioning it here.
There was a problem hiding this comment.
It’s not a common scenario though: it’s only for Microsoft apps that ship in the sdk, or maybe for tools that people launch with MSBuild. One of those is internal-only and the other is only relevant for people who don’t have .NET globally installed.
Co-authored-by: Jan Jones <[email protected]>
Co-authored-by: Alexander Köplinger <[email protected]>
Co-authored-by: Alexander Köplinger <[email protected]>
|
Closing in favor of dotnet/docs#49430 |
6 participants
No description provided.