Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
dagood opened this issue Dec 3, 2019 · 17 comments
Closed

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

dagood opened this issue Dec 3, 2019 · 17 comments

Comments

@dagood
Copy link
Member

@dagood dagood commented Dec 3, 2019

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

@dagood dagood mentioned this issue Dec 3, 2019
8 of 11 tasks complete
@dagood dagood self-assigned this Dec 3, 2019
@dagood

This comment has been minimized.

Copy link
Member Author

@dagood dagood commented Dec 3, 2019

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

This comment has been minimized.

Copy link
Member Author

@dagood dagood commented Dec 3, 2019

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

This comment has been minimized.

Copy link
Member Author

@dagood dagood commented Dec 3, 2019

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

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

This comment has been minimized.

Copy link
Member

@leecow leecow commented Dec 4, 2019

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

@yyjdelete

This comment has been minimized.

Copy link

@yyjdelete yyjdelete commented Dec 4, 2019

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

This comment has been minimized.

Copy link
Member

@leecow leecow commented Dec 4, 2019

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

@joeloff @JunTaoLuo

@dasMulli

This comment has been minimized.

Copy link

@dasMulli dasMulli commented Dec 4, 2019

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

This comment has been minimized.

Copy link
Member

@leecow leecow commented Dec 4, 2019

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

This comment has been minimized.

Copy link

@dasMulli dasMulli commented Dec 4, 2019

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

This comment has been minimized.

Copy link
Member Author

@dagood dagood commented Dec 4, 2019

@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

This comment has been minimized.

Copy link
Member

@mthalman mthalman commented Dec 4, 2019

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

This comment has been minimized.

Copy link
Member Author

@dagood dagood commented Dec 4, 2019

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

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

@SimonCropp

This comment has been minimized.

Copy link

@SimonCropp SimonCropp commented Dec 4, 2019

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

@SimonCropp

This comment has been minimized.

Copy link

@SimonCropp SimonCropp commented Jan 5, 2020

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

@dagood

This comment has been minimized.

Copy link
Member Author

@dagood dagood commented Jan 6, 2020

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

This comment has been minimized.

Copy link
Member Author

@dagood dagood commented Jan 15, 2020

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

@dagood dagood closed this Jan 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.