You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Empty .Net Core Runtime install folder is enough to break applications. #91806
A group of applications are built to run against .Net 6.
A tester or user uninstalls the .Net Runtime for whatever reason, in this example assume .Net v6.0.20.
Later, when our applications are installed, the .Net 6 Runtime is reinstalled, in this example assume .Net v6.0.16.
Our applications fail to execute.
Event Viewer shows this error: "Message: A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\6.0.20'."
We then notice that an empty "6.0.20" folder exists while the full Runtime is available in a "6.0.16" folder.
If we delete the 6.0.20 the issue is fixed.
Reproduction Steps
We do not know what is causing the empty folder. It is happening to our testers and in the field to Windows users, albeit at a low rate. But when you have millions of customers, it adds up.
We have not been able to reproduce this issue at all when we are actively trying. So we do not know how the issue comes about. But you can manually replicate the problem by simply creating an empty folder in
This should be fixed in #90035.
I think the fix should be in .NET 8 RC1 when it ships (or you can get the nightly).
The fix is in hostfxr which is "global" on the machine and we always use the latest version. If you install the fixed version then it will be fixed for all apps regardless of which version of the runtime they need.
Nice to know it was fixed. That said, .Net 6 is an LTS. Therefore, I would like to propose that the fix needs to be backported to .Net 6. I work for Dell Technologies and stating that we need to install the .Net 6 runtime AND the .Net 8 runtime (when released) on all of our customer's machines just to fix this issue seems extreme.
Interesting decision. .Net 6 is an LTS and we have proof that this issue leaves customer machines unable to execute .Net 6 applications. ANY .Net 6 application.
After some more evaluation of the impact and risk, we are backporting this to .NET 6 (and 7). We missed the deadline for October, but the fix should be in the November release.
ghost locked as resolved and limited conversation to collaborators on Oct 18, 2023
Activity
vitek-karas commentedon Sep 8, 2023
This should be fixed in #90035.
I think the fix should be in .NET 8 RC1 when it ships (or you can get the nightly).
The fix is in
hostfxrwhich is "global" on the machine and we always use the latest version. If you install the fixed version then it will be fixed for all apps regardless of which version of the runtime they need.vitek-karas commentedon Sep 8, 2023
/cc @elinor-fung
rruizGit commentedon Sep 8, 2023
Nice to know it was fixed. That said, .Net 6 is an LTS. Therefore, I would like to propose that the fix needs to be backported to .Net 6. I work for Dell Technologies and stating that we need to install the .Net 6 runtime AND the .Net 8 runtime (when released) on all of our customer's machines just to fix this issue seems extreme.
agocke commentedon Sep 11, 2023
Given that this is not a regression and can only result from an incorrect uninstall, I do not think this meets the bar for backport to .NET 6.
rruizGit commentedon Sep 11, 2023
Interesting decision. .Net 6 is an LTS and we have proof that this issue leaves customer machines unable to execute .Net 6 applications. ANY .Net 6 application.
elinor-fung commentedon Sep 18, 2023
After some more evaluation of the impact and risk, we are backporting this to .NET 6 (and 7). We missed the deadline for October, but the fix should be in the November release.