.NET 7.0 November 2022 Update - .NET 7.0.0 and SDK 7.0.100

[dotnet-sb-bot]

Please use the v7.0.100-rtm.22521.12 tag to source-build .NET version 7.0.0 / 7.0.100.

• Release Notes: https://github.com/dotnet/core/blob/main/release-notes/7.0/7.0.0/7.0.0.md
• Tag URL: https://github.com/dotnet/installer/releases/tag/v7.0.100-rtm.22521.12

@dotnet/distro-maintainers

Release info:

{
  "Channel": "7.0",
  "Runtime": "7.0.0",
  "Sdk": "7.0.100",
  "InstallerTag": "v7.0.100-rtm.22521.12"
}

[ayakael]

I'm having issues with some version mismatch stuff, especially due to applying the v7.0.100-rtm.22521.12 monicker. A lot of components are expecting version 7.0.100 of stuff. Am I the only one experiencing these issues?

[ayakael]

Indeed, this was one issue we encountered. The following patch did the trick:

diff --git a/src/installer/eng/Versions.props b/src/installer/eng/Versions.props
index b2330f533..8010b5f82 100644
--- a/src/installer/eng/Versions.props
+++ b/src/installer/eng/Versions.props
@@ -204,9 +204,9 @@
     <XamarinMacCatalystWorkloadManifestVersion>15.4.1006-rc.1</XamarinMacCatalystWorkloadManifestVersion>
     <XamarinMacOSWorkloadManifestVersion>12.3.1006-rc.1</XamarinMacOSWorkloadManifestVersion>
     <XamarinTvOSWorkloadManifestVersion>15.4.1006-rc.1</XamarinTvOSWorkloadManifestVersion>
-    <MonoWorkloadManifestVersion>$(MicrosoftNETCoreAppRefPackageVersion)</MonoWorkloadManifestVersion>
-    <MicrosoftNETWorkloadEmscriptennet6Manifest70100Version>7.0.0</MicrosoftNETWorkloadEmscriptennet6Manifest70100Version>
-    <MicrosoftNETWorkloadEmscriptennet7Manifest70100Version>7.0.0</MicrosoftNETWorkloadEmscriptennet7Manifest70100Version>
+    <MonoWorkloadManifestVersion>7.0.0-rtm.22504.4</MonoWorkloadManifestVersion>
+    <MicrosoftNETWorkloadEmscriptennet6Manifest70100Version>7.0.0-rtm.22504.3</MicrosoftNETWorkloadEmscriptennet6Manifest70100Version>
+    <MicrosoftNETWorkloadEmscriptennet7Manifest70100Version>7.0.0-rtm.22504.3</MicrosoftNETWorkloadEmscriptennet7Manifest70100Version>
     <EmscriptenWorkloadManifestVersion>$(MicrosoftNETWorkloadEmscriptennet7Manifest70100Version)</EmscriptenWorkloadManifestVersion>
   </PropertyGroup>
   <PropertyGroup

Our other issues had to do with trying to build our stage0 package, which is an online build relying on nuget repos rather than the prebuilt artifacts tar. It doesn't seem like the nuget feeds are sporting the new 7.0.0 packages yet, but it's slowly clearing up as those feeds are being populated.

[crummel]

I'll get in touch with the folks who push the packages and see what the current status is, thanks for the heads-up.

[ayakael]

The following packages are yet to be in nuget feeds:

• microsoft.dotnet.ilcompiler.7.0.0.nupkg
• microsoft.dotnet.common.projecttemplates.7.0.7.0.100.nupkg
  (and above packages referenced in patch)

The rest seem good. We went around the issue by providing those packages manually.

[crummel]

Someone is working on pushing these four packages to dotnet-public now. dotnet7 may take longer but it should unblock you just to have them in public I think.

[crummel]

These packages should be available on dotnet-public now.

[cho-m]

I'm trying to update to this tag in Homebrew (Homebrew/homebrew-core#115365), but the Linux build hangs forever (or at least 10+ hours). Homebrew Linux CI is run in an Ubuntu 22.04 container within GitHub's ubuntu-22.04 or Google Cloud ubuntu-2204-lts.

I did some additional debugging and it looks like the shutdown attempt is where build is getting stuck
https://github.com/dotnet/installer/blob/v7.0.100-rtm.22521.12/src/SourceBuild/tarball/content/build.sh#L182

  $CLI_ROOT/dotnet build-server shutdown

Homebrew build essentially follows steps in https://github.com/dotnet/installer#building. One potential difference from some Linux distros' packaging is that we don't maintain our own prebuilt/SDK and instead just use default fetched to bootstrap with.

Couldn't find much related. dotnet/msbuild#8006 did have some linked issues that mention hanging but was merged back in September.

I was testing workarounds/changes in Homebrew/homebrew-core#117596 and only one that allowed getting past this behavior was removing above shutdown line.

[cho-m]

I can try some more things out in Homebrew CI and get back.

I will note that the Homebrew macOS builds don't see any issue and I assume Linux distros haven't hit an issue based on .NET 7 packages I have seen so far.

I don't know what is exact extent of differences in build environments. One thing could be the docker container. May need to check if Ubuntu has a .NET 7 package as that would be closest to Homebrew's build environment.

[cho-m]

One thing I would check more broadly is if you can pin down which build-server being shut down is the cause of the hang. the shutdown command takes a number of flags, (--msbuild, --vscscompiler, and --razor)

@baronfel --vbcscompiler is causing hang.

Currently don't see any logging info from the command so I don't have any extra info to provide. Is there a verbose/debug flag?

[crummel]

@baronfel Is there any more info @cho-m can provide you to debug this? Or anything we should try?

[baronfel]

sorry - I missed the follow-up. @jaredpar who would be a good person to ping about the roslyn build server seeming to hang on .NET 7?

[jaredpar]

@baronfel myself.