Skip to content
This repository has been archived by the owner on Jan 23, 2023. It is now read-only.

Latest commit

 

History

History
24 lines (14 loc) · 3.91 KB

strong-name-signing.md

File metadata and controls

24 lines (14 loc) · 3.91 KB
Raw

Strong Name Signing

All .NET Core assemblies are strong-named. We do this for two reasons:

  1. Compatibility. We want to maintain type identity with previous versions of our assemblies that have shipped across various versions of our platforms. Removing a strong-name from an assembly is a breaking change, and would break the ability to consume and run libraries built against the previous identities.

  2. Serviceability. When running on .NET Framework some of .NET Core assemblies ship locally ("app-local") with the application, this is in contrast to other framework assemblies that are placed in the GAC. To be able to service these libraries for critical security updates, we make use of the app-local servicing feature which requires that assemblies have strong-names.

FAQ

1. Microsoft strong-names their assemblies, should I?

For the most part, the majority of applications and libraries 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. However in recent years, sandboxing via AppDomains, especially to [isolate ASP.NET web applications] (http://support.microsoft.com/kb/2698981), is no longer guaranteed and is not recommended.

However, strong-names are still required in some rare situations, most of which are called out on this page: Strong-Named Assemblies.

2. I really, really need to strong-name, what kinds of issues will I run into?

There are three major problems that developers run into after strong naming their assemblies:

  1. Binding Policy. When developers talk about strong-names, they are usually conflating it with the strict binding policy of the .NET Framework that kicks in when you strong-name. This binding policy is problematic because it forces, by default, an exact match between reference and version, and requires developers to author complex binding redirects when they don't. In recent versions of Visual Studio, however, we've added Automatic Binding Redirection as an attempt to reduce pain of this policy on developers. On top of this, all newer platforms, including Silverlight, WinRT-based platforms (Phone and Store), .NET Native and ASP.NET 5 this policy has been loosened, allowing later versions of an assembly to satisfy earlier references, thereby completely removing the need to ever write binding redirects on those platforms.

  2. Virality. Once you've strong-named an assembly, you can only statically reference other strong-named assemblies.

  3. No drop-in replacement. This is a problem for open source libraries where the strong-name private key is not checked into the repository. This means that developers are unable to build to their own version of the library and then use it as a drop-in replacement without recompiling all consuming libraries up stack to pick up the new identity. This is extremely problematic for libraries, such as Json.NET, which have large incoming dependencies. Firstly, we would recommend that these open source projects check-in their private key (remember, strong-names are used for identity, and not for security). Failing that, however, we've introduced a new concept called Public Signing that enables developers to build drop-in replacements without needing access to the strong-name private key. This is the mechanism that .NET Core libraries use by default.