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.

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

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.

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.

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