1

Closed

Nuget 3.4 package not strong named

description

Just upgraded a project to the 3.4 nuget and noticed its dosnt have a strong name so assembly so assembly redirect is broken
Closed Aug 17, 2012 at 3:23 PM by JeremyS

comments

JeremyS wrote Aug 17, 2012 at 3:22 PM

Going forward the primary nuget package will no longer be strongly named.

A separate package, FluentValidation-signed can be used if you absoloutely need strong naming, but it is recommended that you use the unsigned version.

SoulMaster wrote Aug 17, 2012 at 6:40 PM

Can you explain u recommand non strongly named dll as primary package?

JeremyS wrote Aug 18, 2012 at 7:40 AM

There's typically not a good reason to use a strong named version if you can avoid it.

It often makes upgrades more difficult. For example, the NancyFX framework has a dependency on FluentValidation. If you're using both NancyFX and FluentValidation, and want to upgrade the version of FluentValidation (for example, to take advantage of a new feature) then you'd need to recompile NancyFX as well.

Without strong naming, you can simply drop in a new version of FluentValidation without needing to recompile, provided that the public API is backwards compatible.

danthman wrote Aug 19, 2012 at 5:01 PM

I have added a bug report to Ninject.Web.Mvc.FluentValidation (see https://github.com/ninject/ninject.web.mvc.fluentvalidation/issues/3), because that project was still referencing FluentValidation as a strongly named assembly. This caused my project to stop compiling (see stackoverflow.com/questions/12015553/).

While I agree with the trend toward weakly named assemblies, making the switch can easily be a breaking change. One suggestion would be to have two parallel projects/Nuget packages, one strongly named and one weakly named. You could then discontinue development on the strongly named one and encourage developers to switch to the weakly named one. That would mean that the new weakly named project would have to have a unique name, however, which could be confusing as well. I guess what is ultimately needed is a new feature on Nuget feature to make the transition from strongly named to non-strongly name more seamless.

JeremyS wrote Aug 20, 2012 at 8:00 AM

There is already a separate strongly-named package. The package IDs are FluentValidation-Signed, FluentValidation.MVC3-signed and FluentValidation.MVC4-signed. Please feel free to try these out and let me know if they work OK for you.

Jeremy