[Enhancement] Strong Name assemblies

[bruno-garcia]

Summary

Consider strong naming Microsoft.Maui.* and including the snk in the repo.

I understand this wasn't an option on Xamarin but would this be an option on MAUI?

After all, this is the official library authoring guideline from .NET:

✔️ CONSIDER strong naming your library's assemblies.

✔️ CONSIDER adding the strong naming key to your source control system.

CSC : error CS8002: Referenced assembly 'Microsoft.Maui, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.

[BlueRaja]

I'll admit I don't fully understand the use-case for strong naming, but isn't it basically obsolete now? See for example here

For the most part, the majority of applications do not need strong-names. Strong-names are left over from previous eras of .NET where sandboxing needed to differentiate between code that was trusted, versus code that was untrusted.

or here

For .NET Core, strong-named assemblies do not provide material benefits.

[bruno-garcia]

It's mainly a legacy .NET Framework thing, yes.

The use case though is being able to have code that is already strong named, depend on these libraries. Since the beginning of time the advise was to strong name libraries. That created a viral effect such that today the ecosystem is mainly strong named. So if you have a strong named library, such as Sentry that has integrations for multiple .NET libraries like Serilog, NLog, ASP.NET Core etc, they all need to be strong named. And they all are.

Except the Xamarin assemblies. And now MAUI.

[mattjohnsonpint]

Here's another case for strong naming the MAUI assemblies.

If a MAUI project references a .NET class library that is strong named, the class library won't be able to use InternalsVisibleTo to make its internals available to the MAUI project. Trying to do so will give a compile error:

[CS1726] Friend assembly reference 'MyMauiAssembly' is invalid. Strong-name signed assemblies must
         specify a public key in their InternalsVisibleTo declarations.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[mattjohnsonpint]

I believe I have found a reasonable workaround:

<PropertyGroup>
  <NoWarn>$(NoWarn);CS8002</NoWarn>
  <SignAssembly>true</SignAssembly>
  <UseMaui>true</UseMaui>
</PropertyGroup>

That allows signed projects to consume unsigned MAUI assemblies. Everything then just works as expected.