Different Behavior during ASPNET Core upgrade (MSI install vs Windows Update install)

[RomBrz]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Last week i discovered that i could update the ASPNET Core versions on servers using WSUS updates and configure to deliver the ASPNET Core updates to help me managing 30+ servers.
Happen to the WSUS update doesn't make the server at same level comparing with a "Stand alone Host Bundle Install".

I have two servers "twins", with same ASPNET Core versions installed on both.
Server 1 i downloaded the Hosting Bundle packages (https://dotnet.microsoft.com/en-us/download/dotnet)
Server 2 i installed all the Windows Updates available (WSUS configured using https://devblogs.microsoft.com/dotnet/net-core-updates-coming-to-microsoft-update/)

Server1 after installing manually:
.NET Core Runtimes:
6.0.4 x86
6.0.4 x64
5.0.16 x86
5.0.16 x64
3.1.24 x86
3.1.24 x64

ASP.NET Core Runtimes:
6.0.4 x86
6.0.4 x64
5.0.16 x86
5.0.16 x64
3.1.24 x86
3.1.24 x64

.NET Core Runtime & Hosting Bundles:
3.1.24
6.0.4
5.0.16

Server2 after WSUS install:
.NET Core Runtimes:
6.0.3 x86
6.0.3 x64
5.0.16 x86
5.0.16 x64
3.1.24 x86
3.1.24 x64

ASP.NET Core Runtimes:
6.0.3 x86
6.0.3 x64
5.0.16 x86
5.0.16 x64
3.1.24 x86
3.1.24 x64

.NET Core Runtime & Hosting Bundles:
3.1.23
6.0.4
5.0.15

Seems like either the Hosting Bundle are update or the Runtime are updates.
3.1.24 and 5.0.16 updated the runtimes, but not the Hosting Bundle
6.0.4 updated the Hosting Bundle, but not the runtimes.

After reboot, and checking with Windows Update again, no updates are found.

Expected Behavior

The WSUS/Windows Update of the ASPNET Core should deliver the same "updated version" that the intall of the stand alone Hosting Bundle package.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

all versions

Anything else?

No response

[wtgodbe]

@jamshedd do we know what version(s) of the hosting bundle are now available on WSUS?

I just confirmed that installing the 6.0.3 Hosting Bundle followed by the 6.0.4 one will leave the 6.0.4 runtimes on your machine as expected, so I'm surprised to see the WSUS machine w/ the 6.0.4 Hosting Bundle but 6.0.3 runtimes

[jamshedd]

The removal of the older 6.0.3 runtime should not have anything to do with whether the hosting bundle was installed via WSUS or manually. Removal is of the older installers is handled by our bundle and the same bundle is executed in both cases. The removal of hte older runtime (or lack thereof) is likely a function of what else is on the machine (for e.g. VS) that might be referencing the older installer, or what app or service might have been running and locked files.

Adding @csnellgrove1-zz to confirm.

[RomBrz]

I did more tests after this post.
Explaining better:
Server1: Installed manually the hosting bundle
Server2: Installed with WSUS -> Installing the 04/2022 patches (Windows, DotNet Framework, DotNet Core) -> DotNet 6.0.4 installation FAILED
Server3: Installed with WSUS -> Installing the 04/2022 patches (Windows, DotNet Framework, DotNet Core) -> DotNet 6.0.4 installation OK

Seems like the Server2 has some problem installing all the patches together. After reboot, the patch didn't show (Windows Update says that everything is up to date). (And the information appears like the initial post) I tried manually installing the 6.0.4 Hosting Bundle but didn't work. After some "good" time trying to solve what's wrong, because no matter what i did, i could not install the 6.0.4 (but could install the 6.0.3 after removing everything about 6.0.*), (ever tried install 6.0.4 after reinstall 6.0.3 but didn't work either) i reinstalled the 6.0.3, checked for updates, Windows Update found the 6.0.4 and installed OK. So seems like that the crash during the first Windows Update install broke and lock the server to only accept the 6.0.4 with WU.

About the Server3, it received the same patches that Server2 received, but installed all patches without problem. The result was that the server ends with the same components that Server2 (after all i posted above).

Both servers updated The 3.1.x, 5.0.x and 6.0.x runtimes (and removed the olders), but both didn't updated the ".NET Core Runtime & Hosting Bundles" for 3.1.x and 5.0.x (just the 6.0.x).

So at the end i have this:
Server1 (manually):
3.1.24 Runtimes / 3.1.24 Hosting Bundle
5.0.16 Runtimes / 5.0.16 Hosting Bundle
6.0.4 Runtimes / 6.0.4 Hosting Bundle

Server2 and Server3 (with WSUS):
3.1.24 Runtimes / 3.1.23 Hosting Bundle
5.0.16 Runtimes / 5.0.15 Hosting Bundle
6.0.4 Runtimes / 6.0.4 Hosting Bundle

[RomBrz]

Today i installed on another server, and the same behavior occurs:
Both 3.1.24 and 5.0.16 installers doesn't updated the Hosting Bundle package.

Seems like the problem with the 6.0.4 in this case was something with the Windows Update itself (and, as i told early, what i did to solve).

Funny fact: The manual Hosting Bundle package doesn't recognize the 3.1.24 and 5.0.16 Windows Update installation: both installers open as i didn't have anything related installed (welcome to the installation, next next finish).
The 6.0.4 installer recognize the Windows Update installation (shows me the "modify, repair or uninstall" page)

[wtgodbe]

Could be related to the VS/SDK mismatch from 6.0.4 (we inadvertently shipped mismatched runtimes in Visual Studio vs. the Dotnet SDK in 6.0.4) - do these machines have VS installed? You could try the steps described here: https://developercommunity.visualstudio.com/t/PackageId:MicrosoftAspNetCoreSharedFra/10015847#T-N10018891

[RomBrz]

These servers are for publishing applications, so they don't have VS installed, and i never installed the SDK on it.

Before i knew that i could update DotNet using WSUS/WU, i just downloaded each month the Hosting Bundle and install it on my IIS Servers so the DEV team could publish DotNet Core apps with existing DotNet Framework apps.

[RomBrz]

Trying again this month and trying to documentate the things:
Server before updates:

The updates available by Windows Update:

Server after updates:

Seems like the Hosting Bundle for 3.1.x and 5.0.x are not updating with the Windows Update; only with manual installing of Hosting Bundle.

Expected behavior (i downloaded both Hosting Bundle from MS site and installed manually):

[wtgodbe]

Ah, that might be a hint - we recently did work to provide the Hosting Bundle through Microsoft Update - @jamshedd @joeloff @csnellgrove1-zz does MU offer the hosting bundle for 6.0 only, or for 3.1 & 5.0 as well? The change that makes it possible to offer the hosting bundle is present all the way back to 3.1, but I'm not sure whether or not MU actually offers it that far back.

[jamshedd]

Its offered for all versions (not just 6.0).

[RomBrz]

Any news with this problem? Right now i have to reinstall the 3 hosting bundle for different reasons:

• 3.1 and 5.0 not update the Hosting Bundle package
• 6.0 depending of the server and the applications (or the order of the instalation of the patches) crash during the install, so i have to uninstall everything mannualy, reboot the server, install the previous version, reboot the server again, check for updates and waiting for the windows update update to the latest version.

The 3.1 and 5.0 question happen on 100% of the servers
the 6.0 broken installation occurs on "randon" situations, some servers update okay, some servers broke the installation (and the only way to "unbroke" is to do what i told above.

[wtgodbe]

The 3.1/5.0 problem sounds like an issue w/ Windows Update - @jamshedd @csnellgrove1-zz who can we talk to to confirm if/why the hosting bundle isn't being offered for 3.1/5.0? Sounds like @RomBrz has consistently not been offered it for the past 3 releases.

As for 6.0, are you able to attach logs from the failed install? They should be in your %Temp% folder after the install.

[joeloff]

The hosting bundle's offering depends on detecting the relevant ANCM copy. If the the 3.1 and 5.0 installs did not include ANCM, it won't be offered - this is one of the reasons why I suggested we should actually do the full bundle detection, rather than looking at the MSIs.