Discussion for aspnet/Announcements#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?
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.
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:
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.
@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.
Unlike before, we're checking in the private key.
Well, that certainly eliminates what could have been the main pain point going forwards!
Adds strong naming with checked in private key (see aspnet/dnx#3156 f…
…or anyone panicking about that)