Signed nuget version

[IvanYur4enk0]

Hello,

Current nuget version is not signed and it is very uncomfortably\limited to use this version in signed applications. Can you upload signed version to nuget repository, please?

Thanks,
Ivan

[MatejQ]

I second that. We need local cache in combination with Redis cache in an Azure environment and this seems to be the only library we can use. Please make signed version, it shouldn't be so hard...

[MichaCo]

@MatejQ @IvanYur4enk0 do you mean a strong named version of the assemblies or sign the nuget packages?

If you mean strong naming then, why? That's an artifact and causes all kinds of issues in open source projects.
Microsoft is strongly naming their packages because they cannot break backward compatibility.

See problems if you strongly name your assemblies for example here.

That's why I didn't do it.

[MatejQ]

Thank you for your answer, @MichaCo
I meant strong naming (and I think that's what the OP meant too). Our product is strong named from the beginning, consists of more than 50 projects and uses many other NuGet packages. We don't want to go from "strong named" to "not strong named" right now (who knows what breaks in the process).
Anyway, for example, the package StackExchange.Redis offers both strong named and non strong named versions. I thought similar approach would work well here too. Current CacheManager package references the non strongly named version.
I guess our only option as last resort now is to clone repository of CacheManager, and sign it using our own snk file. And of course, reference the strongly named StackExchange.Redis package. But then we lose the benefits of nuget packages so it would be much better if there was a strongly named nuget package of CacheManager available.

//edit: oh, and then also CacheManager.StackExchange.Redis package will need to be strongly named to be used.

[MichaCo]

Just signing the packages later would not help because they reference each other, so the nuget dependencies would reference the not signed ones. That means, I'd have to create additional projects or some other strange solution.
And, more importantly, CacheManager already produces a lot of NuGets, I actually don't want to double them... ;)

I might just use the sign feature of project.json ("keyFile" setting) in general, for all projects.
I just don't know what the impact might be in general...
That would also mean that I always reference the StrongName redis package...

[MatejQ]

Well, if the result is that the CacheManager DLLs can be referenced from strong named assemblies, then it would make us happy :)

[IvanYur4enk0]

We solve this in our solution by using Brutal.Dev.StrongNameSigner nuget - just adding following targets file:

<Target Name="StrongNameSignNugetPackages" AfterTargets="BeforeBuild">
    <Exec ContinueOnError="false" Command="&quot;..\packages\Brutal.Dev.StrongNameSigner.1.8.0\tools\StrongNameSigner.Console.exe&quot; -k &quot;..\..\Key\{Customer}.snk&quot; -in &quot;..\packages\CacheManager.Core.0.9.0\lib\Net45|..\packages\CacheManager.SystemRuntimeCaching.0.9.0\lib\Net45&quot;" />
</Target>

[MichaCo]

@MatejQ @IvanYur4enk0
I just released version 0.9.1 and all those packages are now signed.

[IvanYur4enk0]

Thank you

[brianlocke]

With this change we now have conflicting references between StackExchange.Redis and the strongname version. Our library references other nugets that require the non-strongname. How are folks getting around this conflict?
Fixed: Assigned the alias 'signed' in the properties of the project reference to the StrongName version. Then 'using signed::StackExchange.Redis;' in code.

[MichaCo]

@brianlocke

Fixed: Assigned the alias 'signed' in the properties of the project reference to the StrongName version. Then 'using signed::StackExchange.Redis;' in code.

cool! Thanks for letting us know. Was wondering if there is a workaround or if I have to create two different packages (which I didn't want to do at all).