Signed version

[rollbar]

Signed version

[akornich]

After doing some more reading on the topic, it seems we are better going the Strong Namer route. It is an easy and straightforward solution to Rollbar.NET signing needs. Any Rollbar.NET hosting application that expects the Rollbar assemblies to be signed will just sign its own assemblies and install StrongNamer NuGet package that will make sure all the not-strongly-named dependencies can be loaded by the signed hosting application at runtime. It is that easy.
We may want to add a new section to the Readme file to point to the StrongNamer’s Readme file within a short description of our own.
@chadly, thanks for pointing us towards the StrongNamer!

[chadly]

Please don't do this. Just use strong namer if you want a signed assembly.

[rokob]

I am not sure if we can do both to make both use cases easy, or if we just need documentation on how to use our package with a signed project. Adding to the v1 milestone so that we take care of it either way.

[akornich]

@rokob : the suggestion provided by @chadly is worth considering that may be the way to go. But I, personally, will have to learn a bit more about strong namer before committing to it. one area of concern is how well or not it plays with .NET platform multi targeting.

[akornich]

How about we just maintain two Nuget packages, for example, Rollbar and Rollbar-signed? This way the users can pick one that fits their application signing scenario...

[jessewgibbs]

@akornich have you guys settled on a solution for this issue? Sounds like there are a couple of options to consider...

[akornich]

i am personally leaning towards the two builds/packages solution: one signed, one unsigned. It is very straightforward and does not play any "magic" like the strong namer does.
also, when going with the two builds approach we can use this opportunity to setup CI and build automation environment for rollbar.net...

[chadly]

My only concern with the two-package approach is that if a package that I depend on depends on the signed version whereas I depend on the unsigned version, it will cause all kinds of versioning/binding redirect hell for me and negates the benefits of having the unsigned package.

The trend in the .net world has been to stop signing dlls, especially for OSS. I feel for the poor souls who still must use signed packages, but I feel like strong namer is a good solution for them - with the idea that they would be using it within their own internal, private, enterprise builds - not spreading the strong named cancer throughout the ecosystem.

[akornich]

BTW, we may want to try signing all of our Rollbar.NET samples while adding StrongNamer NuGet package to them to serve as a proof of concept...