3.1.0 GA Windows installers for the runtime are branded "3.1.0 Preview 3"

[dagood]

Reported at dotnet/core#3950 (comment) by @henrikrxn (thank you!)

After installing VS 16.4 I checked "Control Panel" and the 3.1 runtime is listed as

Name
"Microsoft .NET Core Runtime - 3.1.0 Preview 3 (x64)"
"Microsoft .NET Core Runtime - 3.1.0 Preview 3 (x86)"

Version
3.1.0.28312
3.1.0.28312

The name should be updated. Given the information available on https://dotnet.microsoft.com/download/dotnet-core/3.1
I am unable to determine whether 28312 is the 3.1 RTM build number. Maybe include this number in future releases as it has been the custom for previews?

Additional info
Tried

• Uninstalling both the 3.1 Preview 3 runtimes
• Downloading the .NET Core 3.1 runtime x64 installer and when opening it also states 3.1 Preview 3 as the version in the UI

This is an issue with the installer build, putting bad ProductName properties in the MSIs, e.g.:

• Microsoft .NET Core Runtime - 3.1.0 Preview 3 (x64)
• Microsoft Windows Desktop Runtime - 3.1.0 Preview 3 (x64)
• Microsoft .NET Core Host - 3.1.0 Preview 3 (x64)
• Microsoft .NET Core Host FX Resolver - 3.1.0 Preview 3 (x64)

The MSIs do appear to install proper 3.0.0 content, only branding appears to be affected.

Something in the infra didn't work right with the stabilized versions. There were some changes around versioning to simplify the publishing infra that were made somewhat recently that I think might be involved. I'll investigate a fix.

/cc @leecow @dleeapho @mmitche

[mmitche]

The prerelease label should have been rtm: https://github.com/dotnet/core-setup/blame/4e1bb23ca12cfe3de0b7e834872ed7327377d420/eng/Versions.props#L7

which is then dealt with here:

https://github.com/dotnet/core-setup/blob/4e1bb23ca12cfe3de0b7e834872ed7327377d420/src/pkg/Directory.Build.targets#L13

[dagood]

Something's more broken here than I initially thought. We may have published the wrong thing?

1. I can't repro the problem when building the dotnet/core-setup v3.1.0 tag locally. (I would expect to be able to.)
2. The .NET Core SDK installer has a different MSI, which doesn't have this branding problem.
   • The (bad) .NET Core Runtime installer EXE carries a runtime MSI built on 2019-11-12
   • The .NET Core SDK installer EXE carries a runtime MSI built on 2019-11-15

The original report was from a VS install, which suggests that at the point of release, VS had the wrong MSI inserted.

/cc @johnbeisner

[dagood]

MSI version of the above two MSIs for reference:

• The .NET Core Runtime installer carries 24.64.28312
• The SDK installer carries 24.64.28315

[dagood]

The Core-Setup diff between the versions is dotnet/core-setup@157910e...v3.1.0. It includes CoreCLR, CoreFX, WinForms, and WPF dependency updates:

• dotnet/coreclr@816d9ee...1ed7226
• dotnet/corefx@4703e4a...0f7f38c
• dotnet/winforms@922e410...4bcd68c
• dotnet/wpf@af68b9c...427fa56

WinForms took a localization update. That will be missing if you install using the .NET Core Desktop installer until we get this fixed.

It looks to me like the other repos just had minor build infrastructure changes.

(So far, it appears this was not caused by a bug in the Core-Setup repo, rather it was a release problem.)

@vivmishra is working on fixing up the installers available for download.

@leecow, have you talked to @johnbeisner about the VS insertion?

Heads up @MichaelSimons @mthalman: dotnetcli blob storage has the incorrect version, so I believe @vivmishra will need to make an in-place update to correct this and the checksums will have to change.

[leecow]

Working on publishing the correctly branded files Davis identifies above. Don't know that it will be complete tonight.

[yyjdelete]

This also happen for ASP.NET Core Runtime Hosting Bundle with chksum: f831fefd7315370e68b6743b4511435a1bbfd0945ac1957e16e22ccd7cd56c3fa0da083b66d6528039b1333ab0c8d72f00a05592b359b9ef7bc0cc9fca5872c1
from https://dotnet.microsoft.com/download/dotnet-core/thank-you/runtime-aspnetcore-3.1.0-windows-hosting-bundle-installer

[leecow]

Thanks, @yyjdelete - the hosting bundle will take some more work to resolve.

@joeloff @JunTaoLuo

[dasMulli]

just as a heads-up, what's the plan for dealing with this so we can plan ahead?:

1. Do nothing and tell people to ignore the preview label as a hickup (i'm okay with that, but some enterprise admins may scratch their head why we're trusting the build).
2. Expect 3.1.0 GA assets to change at some point (mess witth file hashes)
3. Expect a 3.1.1 release soon.
4. something else..

[leecow]

Correct Runtime and Windows Desktop installers will be correct from the site in a few minutes. Tomorrow morning, I'll sync with the folks that own the hosting bundle and determine if it needs to be rebuilt. I can give an accurate update after that conversation happens.

[dasMulli]

fyi - meanwhile my colleagues who tried to uninstall and reinstall the hosting bundle are hitting something similar to https://developercommunity.visualstudio.com/content/problem/664156/run-repair-dotnet-sdk-30100-preview7-012821-win-x6.html 😢
"The specified account already exists" error message. can probably try to get newer logs if it isn't already a known problem.

[dagood]

@dasMulli It looks like it's been reported over in aspnet (https://github.com/search?q=org%3Aaspnet+"The+specified+account+already+exists"&type=Issues), if that message is enough to know if it's actually the same. (This issue the only thread in the dotnet org with that phrase.) I wonder if the current situation exacerbates it in some way... doesn't seem to be a new problem though. I'd recommend filing or adding on over there for the hosting bundle repair issue.

[mthalman]

I'm not seeing any changes to the checksums. The Dockerfiles that we published yesterday are still verifying correctly with the checksums that existed at that time.

Example: https://github.com/dotnet/dotnet-docker/blob/b4b02f911964baec3273fd64169236711665c306/3.1/runtime/alpine3.10/amd64/Dockerfile#L7

[dagood]

A few notes about this point in time (Dec 4, 2019, 12:02 PM CST):

• https://dotnetcli.azureedge.net/dotnet/Runtime/3.1.0/dotnet-runtime-3.1.0-linux-musl-x64.tar.gz is still a bad version. (Commit 157910e in shared/.../.version.)
• https://dotnetcli.blob.core.windows.net/dotnet/Runtime/3.1.0/dotnet-runtime-3.1.0-linux-musl-x64.tar.gz is also still the bad 157910e (in case the CDN mattered).

@leecow are you also tracking getting the blob storage updated?

[SimonCropp]

any reason why the packages in question havnt been de-listed?

[SimonCropp]

i realize it is the holiday season for many people. but would it be possible to get an update on this?

[dagood]

Here's what I know (indeed coming back from holidays):

The ASP.NET Core Runtime Hosting Bundle will not be fixed for 3.1.0, it will be fixed in 3.1.1. I wrote up a known issue note for 3.1.0 at https://github.com/dotnet/core/blob/master/release-notes/3.1/3.1-known-issues.md#aspnet-core. (To point it out for this thread, it's only a branding issue. We expect no functional differences from having the "wrong" one installed. There is an issue with the Windows installers misbehaving if you try to replace the runtime with the correct one, also documented there.)

I'm not as sure about the bad blobs still on dotnetcli blob storage. We aren't currently tracking reuploading them--I'll try to confirm this was intentional with some folks. (IMO it seems the issue was fixed incorrectly because only a subset of the files were replaced, but I'll have to confirm.) There is no expected functional difference for most of those so I doubt they'll be reuploaded. The WindowsDesktop zips might be a special case because of the localization difference, I'll ask about those in particular.

any reason why the packages in question havnt been de-listed?

For what it's worth, the NuGet packages aren't affected. As for the installers/zips/etc., I don't think we identified a reason to delete them.

[dagood]

Closing: fixed by 3.1.1. We aren't planning any further "in-place" fixes for 3.1.0 artifacts.