[Announcement] Assemblies are now strong named #3156

cesarbs opened this Issue Nov 11, 2015 · 10 comments


None yet

8 participants

cesarbs commented Nov 11, 2015

Discussion for aspnet/Announcements#109

@cesarbs cesarbs referenced this issue in aspnet/Announcements Nov 11, 2015

Assemblies are now strong named #109


It was my impression that we were moving away from strong named assemblies. Or maybe I'm just mistaken. The fact that you have to validate an assembly while somebody already has access to your file system seemed a bit redundant.

Are those assemblies for backward compatibility only?

Eilon commented Nov 11, 2015

There are a number of reasons.

One reason we enabled strong naming is that we have cases where for a variety of reasons something that depends on the code here must be strong named, and so we must be strong named. (Strong naming is viral.)

Another reason (closely related to the first) is that in order to release critical security updates when running on .NET 4.x, we have to be able to install patches into the GAC, and the GAC requires strong naming.

@cesarbs cesarbs modified the milestone: 1.0.0-rc1, Discussion Nov 11, 2015

There you go. I knew it must have been simple.






Sigh. Fail Naming.


As a hater of strong naming I feel your pain. (intensely)

There's a few things that alleviate the pain when using our new toolchain and runtime, and changes to the process:

  • You never really have to see binding redirects (we'll handle this either at runtime or by generating the right things on your behalf). If you do however use this with vanilla .NET in existing projects. All of the old problems exist. On MSBuild based projects that do not use our new tool chain, this is available https://msdn.microsoft.com/en-us/library/2fc472t2(v=vs.110).aspx.
  • Unlike before, we're checking in the private key. There's no security feature (since strong naming isn't about security anyways). This means you can still swap packages with source on any OS and we'll do the right thing to make sure that works.
  • The binding policy on CoreCLR means binding redirects are never a problem (all the more reason to move everything there as soon as possible 😄).

It's disappointing that for .NET Framework, the problems all still exist but such is life...


Hm, It looks like that the rc2 assemblies become incompatible to the rc1 assemblies because of the stronge naming. Which makes it hard to keep things working. Especially because the package restore seems not to respect the dependency versions: #3152


@endeffects Package restore absolutely respects dependency versions. You're hitting something else altogether.

Eilon commented Nov 12, 2015

@endeffects indeed an assembly would have to be recompiled across those versions. But with all the various renames and other changes, it is quite likely that a recompile would have to take place anyway in order to work.

SamB commented Nov 18, 2015


  • Unlike before, we're checking in the private key.

Well, that certainly eliminates what could have been the main pain point going forwards!

@jonorossi jonorossi referenced this issue in castleproject/Core Nov 26, 2015

Port unit tests to .NET Core Part 1 #118

@hotchkj hotchkj added a commit to hotchkj/AspNetCore.DataProtection.Aws that referenced this issue Jun 7, 2016
@hotchkj hotchkj Adds strong naming with checked in private key (see aspnet/dnx#3156 f…
…or anyone panicking about that)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment