Referenced assembly 'Pri.LongPath' does not have a strong name about longpath HOT 3 CLOSED

I'm looking more into this. From a LongPath point of view, adding a strong-name only causes future problems. There are some tools that sign unsigned packages in NuGet locally--which would probably solve your particular problem.

from longpath.

One way to achieve this would be through disassembling/reassembling the dll.
http://buffered.io/posts/net-fu-signing-an-unsigned-assembly-without-delay-signing/
There is also a nuget package
http://www.nivot.org/blog/post/2013/04/30/Signing-unsigned-assemblies-in-NuGet-packages
I am just wondering, is this OK for distributing the dll in a commercial application? The actual code has not changed but the output dll will be different than the original Pri.LongPath nuget package.

from longpath.

I hate strong naming! but had to use this library in a strongly named project. I cannot blame @peteraritchie here as I think the current situation is right thing to do. NuGet should just have a way to do this like: Install-Package Pri.LongPath -SignTheWorldAsIWannaFeelSecureEvenIfIAmActuallyNot.

from longpath.