search

peteraritchie / LongPath

drop-in library to support long paths in .NET
GNU Lesser General Public License v3.0
112 stars 43 forks source link

Referenced assembly 'Pri.LongPath' does not have a strong name #24

Closed trondr closed 7 years ago

trondr commented 9 years ago

When trying to compile a project referencing 'Pri.LongPath' installed from Nuget I get a compiliation error:

Referenced assembly 'Pri.LongPath' does not have a strong name

Can you please consider strong naming the 'Pri.LongPath'. Thanks!

peteraritchie commented 9 years ago

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.

gpetrou commented 9 years ago

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.

tugberkugurlu commented 8 years ago

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.