I just had a bit of an issue with the Csla-Core NuGet package. Basically because the dependency specifies Bcl.Async >= 1.0.165 if you install Csla today it will grab the latest, which also depends on a later Bcl version as well. The issue is that Csla itself is built against System.Runtime 2.6.6, which caused an issue with FxCop as NuGet got 2.6.7 and FxCop will not let you use 2.6.7 in place of 2.6.6. I'm not sure if this is because Csla is strong named too.
Also, is there any reason to strong name Csla? If there is can we have a -Unsigned package as well?
You may be able to use an assembly redirect in your app.config file to resolve the version differences.
The Bcl.Async packages in nuget have been a problem since day 1, because they do some things that don't fit well into the tooling model (or so I'm told). I'm not sure how to resolve those issues to be honest, at least short of releasing a new CSLA build every time any of the various nuget packages we rely on change.
CSLA is strong named because that's a requirement for quite a number of .NET shops. For better or worse a lot of shops require signed assemblies. Normally being signed is not a drawback for people who don't care, so the lowest friction option is to always sign.
Why would you want an unsigned version?
Copyright (c) Marimer LLC