This repository has been archived by the owner. It is now read-only.

[Announcement] Assemblies are now strong named #3156

Closed
cesarbs opened this Issue Nov 11, 2015 · 10 comments

Comments

Projects
None yet
8 participants
@cesarbs
Contributor

cesarbs commented Nov 11, 2015

Discussion for aspnet/Announcements#109

@MaximRouiller

This comment has been minimized.

Show comment
Hide comment
@MaximRouiller

MaximRouiller Nov 11, 2015

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?

MaximRouiller commented Nov 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Eilon

Eilon Nov 11, 2015

Member

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.

Member

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 milestones: 1.0.0-rc1, Discussion Nov 11, 2015

@MaximRouiller

This comment has been minimized.

Show comment
Hide comment
@MaximRouiller

MaximRouiller Nov 12, 2015

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

Thanks!

MaximRouiller commented Nov 12, 2015

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

Thanks!

@thecodejunkie

This comment has been minimized.

Show comment
Hide comment
@thecodejunkie

thecodejunkie commented Nov 12, 2015

"simple"

:)

@phillip-haydon

This comment has been minimized.

Show comment
Hide comment
@phillip-haydon

phillip-haydon Nov 12, 2015

Sigh. Fail Naming.

phillip-haydon commented Nov 12, 2015

Sigh. Fail Naming.

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl Nov 12, 2015

Member

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...

Member

davidfowl commented Nov 12, 2015

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...

@endeffects

This comment has been minimized.

Show comment
Hide comment
@endeffects

endeffects Nov 12, 2015

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 commented Nov 12, 2015

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

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl Nov 12, 2015

Member

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

Member

davidfowl commented Nov 12, 2015

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

@Eilon

This comment has been minimized.

Show comment
Hide comment
@Eilon

Eilon Nov 12, 2015

Member

@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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@SamB

SamB Nov 18, 2015

@davidfowl:

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

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

SamB commented Nov 18, 2015

@davidfowl:

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

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

hotchkj added a commit to hotchkj/AspNetCore.DataProtection.Aws that referenced this issue Jun 7, 2016

@Eilon Eilon closed this Dec 17, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.