Core: 3.1.102 release broke build using Microsoft.Win32

[andrzejpindor]

3.1.102 release broke build working on 3.1.101

I use dot.net sdk image to build my app inside Docker, using image tagged as mcr.microsoft.com/dotnet/core/sdk:3.1-alpine
My application has TargetFramework set to netcoreapp3.1
Previous version used for build was 3.1.101 and code using type Registry from assembly Microsoft.Win32 was build without any problems on Linux containers, targeting runtimes win10-x64 and osx.10.11-x64.

Today our build server downloaded new version of image - 3.1.102 and now build is broken for both runtimes mentioned earlier.

Build error:

Infrastructure/Networking/INetSettings.cs(32,37):
error CS0103: The name 'Registry' does not exist in the current context 

Sticking my Docker build environment to image mcr.microsoft.com/dotnet/core/sdk:3.1.101-alpine solves the problem, but I don't see anything in Release Notes for version 3.1.102 which I should care about, I think it's may be a bug.

[gareth-horstmann]

I've just run into this issue on my pipelines. The failure I was getting was that some of the System packages weren't restored, which caused the build command to fail. Maybe a restore problem?

We are building using the 3.1-nanoserver-1809 and 3.1-bionic tags and both fail with the same issue. Pinning to 3.1.101 has solved it for me too.

[EamonNerbonne]

To chime in: I also just encountered this on our build pipelines, which we worked around by adding <PackageReference Include="Microsoft.Win32.Registry" Version="4.5.0" /> as a dependency... everywhere.

[scalablecory]

@leecow

[leecow]

Possibly related to https://github.com/dotnet/aspnetcore/issues/19133.

[leecow]

This will be fixed with the next release (3.1.3).

[AArnott]

@leecow I'm confused by your proposed fixing release. This appears to break by updating from 3.1.101 to 3.1.102 (a service release to the .NET Core SDK). A 3.1.3 release doesn't seem to line up with the release versioning. Wouldn't the fix be in 3.1.103? Or are you talking about some other package we have to reference to get the fix?

[leecow]

@AArnott - yes, the fix will be in the 3.1.103 SDK but we tend to refer to the releases by Runtime version. Sorry for the confusion.

[AArnott]

Thanks, @leecow. Was there a bug in the runtime version too such that a new release of the runtime is necessary? I thought this was just an SDK bug.

[leecow]

@AArnott - Not for this specific issue though there are runtime and library fixes included in 3.1.3

• coreclr
• corefx
• aspnetcore

[andrzejpindor]

Hi folks, same situtation for 3.1.300