Thank you for your comment, as you've verbalized something in my mind.
It affects running the binary for debugging (calling it directly), as `dotnet run` is used for running on the development cycle and later, the application on production is published using `dotnet publish`. But it also could affect to apphosts as "This environment variable is used only when running apps via generated executables (apphosts)." [1]
As workarounds, the DOTNET_ROOT can be exported manually, set in some json files for configuring the solution in the sln folder [5] or call the executable directly prepending the DOTNET_ROOT variable with the correct folder (in this case DOTNET_ROOT=/usr/lib/dotnet).
I found an issue about Debugging on upstream [2], but reading this comment [3] it seems that Visual Studio debugs through the /usr/bin/dotnet binary (that's ok with this package version), not calling the binary directly.
About the apphosts, I couldn't check the impact and I was trying to get to the error through the apphost executable deployed by apphost-pack, but a single-executable file can be published by dotnet publish turning off apphost [4].
TBH, I have the patch prepared for next dotnet version (to be relased 13th Dec,we will get the code next Friday) and if you think that this could cause more noise and the existent workaround could be missed, I could resubmit this package (6.0.111) with the fix to be on the safe side.
I'm unable to estimate the impact because, although is not a commonly use and I don't see it referred in official docs about how to run or deploy (even for singleton apps), I don't know if could be a trick used or not.
Hi Łukasz!!
Thank you for your comment, as you've verbalized something in my mind.
It affects running the binary for debugging (calling it directly), as `dotnet run` is used for running on the development cycle and later, the application on production is published using `dotnet publish`. But it also could affect to apphosts as "This environment variable is used only when running apps via generated executables (apphosts)." [1]
As workarounds, the DOTNET_ROOT can be exported manually, set in some json files for configuring the solution in the sln folder [5] or call the executable directly prepending the DOTNET_ROOT variable with the correct folder (in this case DOTNET_ ROOT=/usr/ lib/dotnet) .
I found an issue about Debugging on upstream [2], but reading this comment [3] it seems that Visual Studio debugs through the /usr/bin/dotnet binary (that's ok with this package version), not calling the binary directly.
About the apphosts, I couldn't check the impact and I was trying to get to the error through the apphost executable deployed by apphost-pack, but a single-executable file can be published by dotnet publish turning off apphost [4].
TBH, I have the patch prepared for next dotnet version (to be relased 13th Dec,we will get the code next Friday) and if you think that this could cause more noise and the existent workaround could be missed, I could resubmit this package (6.0.111) with the fix to be on the safe side.
I'm unable to estimate the impact because, although is not a commonly use and I don't see it referred in official docs about how to run or deploy (even for singleton apps), I don't know if could be a trick used or not.
[1] https:/ /learn. microsoft. com/en- us/dotnet/ core/tools/ dotnet- environment- variables# net-sdk- and-cli- environment- variables /github. com/dotnet/ runtime/ issues/ 74361 /github. com/dotnet/ runtime/ issues/ 74361#issuecomm ent-1230487811 /learn. microsoft. com/en- us/dotnet/ core/deploying/ deploy- with-cli /learn. microsoft. com/en- us/dotnet/ core/deploying/ single- file/overview? tabs=cli
[2] https:/
[3] https:/
[4] https:/
[5] https:/