runtime: .NET 6 strong name signing behavior breaks existing code.

Description

I’ve got a program that uses the Boo interpreter under the hood. It breaks on updating to .NET 6, because of a breaking change that causes strong name signing to throw an exception. The following code will always throw, even if the public key value is null:

			var assemblyName = new AssemblyName();
			assemblyName.Name = GetAssemblySimpleName(outputFile);
			assemblyName.Version = GetAssemblyVersion();
			if (Parameters.DelaySign)
				assemblyName.SetPublicKey(GetAssemblyKeyPair(outputFile).PublicKey);
			else
				assemblyName.KeyPair = GetAssemblyKeyPair(outputFile);
			return assemblyName;

Is there any way to fix this behavior without 1) modifying the compiler’s code or 2) reverting back to .NET 5 and losing some important .NET 6 benefits I’d prefer to keep?

Reproduction Steps

var assemblyName = new AssemblyName();
assemblyName.Name = "test";
assemblyName.SetPublicKey(null);

Expected behavior

Behavior should remain consistent with previous versions of .NET.

Actual behavior

An exception is thrown.

Regression?

Yes, this is a massive breaking change from .NET 5 and earlier .NET versions. And even if strong-name signing is no longer supported, supplying a null here indicates that strong-name signing is not actually being used, and therefore no problem exists that needs to be interrupted by throwing an exception.

Known Workarounds

No response

Configuration

.NET 6, Windows 10, x64

Other information

No response

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 20 (17 by maintainers)

Most upvoted comments

@AaronRobinsonMSFT Looks like we missed the doc for this. I can do retroactively update the doc if needed. The scenario previously compiled and ran but never worked. As soon as you ever tried doing anything with the instance, you’d get a runtime exception. The only thing you could ever do was to create the instance and then never look at it again. So to make more explicit that this scenario was unsupported, the exception-throwing logic was moved into the instance ctor, and since no instances could ever be created, propagated to public entry points returning this type (like the KeyPair accessor).

@masonwheeler Can you clarify what you mean by the below comment?

it starts failing on all sorts of other reflection APIs that are not in .NET 6

Pretty much all reflection APIs which were in .NET Framework should also be in .NET 6 and should work correctly. If you have a simplified repro showing something that does not work - even after the call to the KeyPair property has been removed - let us know and we can take a look! Thanks.

GrabYourPitchforks on May 14, 2022

AssemblyBuilder.SetEntryPoint did not exist in .NET 5. There is no way that a call to AssemblyBuilder.SetEntryPoint could have worked in .NET 5.

jkotas on May 14, 2022

var assemblyName = new AssemblyName();
assemblyName.Name = "test";
assemblyName.SetPublicKey(null);

This does not throw for me on .NET 6.

What is the stacktrace of the exception you seeing?

jkotas on May 13, 2022