Open jberezanski opened 2 years ago
cc @wtgodbe @joeloff
Am I understanding right that the scenario is - runtime version X is already installed, then when running the hosting bundle for the same version X with OPT_NO_RUNTIME=1 OPT_NO_SHAREDFX=1
, that runtime gets uninstalled? Are you running the hosting bundle just for the purpose of getting ANCM?
This does sound like a bug, and may be a scenario we didn't already consider. I'd suggest working around this for now by not passing those switches, we'll look in to creating a fix.
Thanks for contacting us.
We're moving this issue to the .NET 8 Planning
milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
@wtgodbe this is likely an issue with not passing the commandline option through to the uninstall of the previous hosting bundle, so when that runs, it detects that the installed runtime matches the runtime it carries and proceeds to remove it.
@wtgodbe
runtime version X is already installed, then when running the hosting bundle for the same version X with OPT_NO_RUNTIME=1 OPT_NO_SHAREDFX=1, that runtime gets uninstalled?
Correct. (However, only the 64-bit runtime gets uninstalled; the 32-bit runtime remains installed.)
Are you running the hosting bundle just for the purpose of getting ANCM?
That's right. I'm forced to do that because of the lack of an ANCM-only installer (which I had asked for some years ago, but despite a favorable reaction in the initial discussion the installer never materialized). I'm using a modular approach to server configuration and I want to have completely separate control over the installation of runtimes and ANCM.
@joeloff
this is likely an issue with not passing the commandline option through to the uninstall of the previous hosting bundle
The problem occurs also on a clean machine, with no previous hosting bundle installed (please see the reproduction steps).
Thakns, I think I know what's going on here.
@wtgodbe for EXE packages, if the install condition is false, the bundle will remove the package, even during an install when it detects that it is present. See this
It's likely detecting the bundle as it matches what's being installed and skipped from the hosting bundle so the engine believes it needs to be removed.
I'll sync with you to see if we can find a workaround. WiX v3 is not taking any changes at the moment (other than critical and security AFAIK) and this behavior has been around for about 10 years now. The one option to work around this is to pull in the standalone MSIs instead of the actual runtime bundles, but this would be a significant change.
Looking from a different angle: the problem first started happening in 6.0.5. What changed from 6.0.4 and could that change be reverted?
Looking from a different angle: the problem first started happening in 6.0.5. What changed from 6.0.4 and could that change be reverted?
https://github.com/dotnet/aspnetcore/pull/41057
We don't want to revert that change, since in most scenarios, users who uninstall the hosting bundle would want it to uninstall its associated runtimes, if it was the source of those runtime installs. It looks like in your particular scenario that's leading to bad behavior - I'll work with @joeloff to see if we can find a solution
Any update? Still happening with 6.0.14
still happening, also when installing via chocolatey with its default installation
Are there any chances this will be fixed in .NET 8? (still happening in preview 5)
I confirm that it is happening with the .NET 8
On a server with .NET Runtime 8.0.0 and ASP.NET Core Runtime 8.0.0 runtimes installed, running the Hosting Bundle 8.0.0 installer with OPT_NO_RUNTIME=1 OPT_NO_SHAREDFX=1 causes the uninstallation of both x64 runtimes (.NET Runtime 8.0.0 and ASP.NET Core Runtime 8.0.0).
The Hosting Bundle is installed only to add the ANCM
I encountered a similar problem when my colleague installed x86 and x64 SDK, and then installed the Hosting Bundle. My solution is to change the installation order SDK x86 => Hosting Bundle => SDK x64
Is there an existing issue for this?
Describe the bug
On a 64-bit machine where the core Runtime 6.0.11 and the ASP.NET Runtime 6.0.11 are already installed (both x64 and x86), running the Hosting Bundle 6.0.11 installer with the
OPT_NO_RUNTIME=1 OPT_NO_SHAREDFX=1
parameters results in the ASP.NET Runtime x64 being uninstalled (but only that one runtime; core runtimes x64 and x86, as well as ASP.NET runtime x86 remain installed).With .NET 7 the problem is worse. In a similar scenario, on a machine with 7.0.0 core and ASP.NET runtimes installed, running the Hosting Bundle 7.0.0 installer with
OPT_NO_RUNTIME=1 OPT_NO_SHAREDFX=1
causes the uninstallation of both x64 runtimes (core and ASP.NET).The problem first started happening with the Hosting Bundle 6.0.5. Version 6.0.4 is the last one to behave correctly.
It seems this happens only if the existing installed runtime is the same version as the Hosting Bundle being installed. When runtimes 6.0.5 were installed and Hosting Bundle 6.011 was invoked the problem did not occur (no runtimes got uninstalled).
Expected Behavior
The Hosting Bundle installer invoked with
OPT_NO_RUNTIME=1 OPT_NO_SHAREDFX=1
should not touch any existing installations of the core Runtime or ASP.NET Runtime (regardless of their bitness).Steps To Reproduce
Initial machine configuration:
Enable-WindowsOptionalFeature -Online -FeatureName IIS-StaticContent -All
Helper function used in all cases:
Case 1: .NET 6.0.11
Result: after Hosting Bundle installation the ASP.NET Runtime x64 is missing.
Case 2: .NET 7.0.0
Result: after Hosting Bundle installation the entire x64 .NET is missing, even dotnet.exe.
Case 3: .NET 6.0.5
Result: after Hosting Bundle installation the ASP.NET Runtime x64 is missing.
Case 4: .NET 6.0.4
Result: this version works as expected - all 4 runtimes remain present after Hosting Bundle installation.
Exceptions (if any)
N/A
.NET Version
First found in 6.0.5 (see bug description).
Anything else?
Attached are PowerShell console commands and output from the four scenarios described in Steps To Reproduce, as well as log files created by the installers.
v6.0.4-console.txt v6.0.4-logs.zip v6.0.5-console.txt v6.0.5-logs.zip v6.0.11-console.txt v6.0.11-logs.zip v7.0.0-console.txt v7.0.0-logs.zip