Strong name signed version

[Tasteful]

Working today with an ecommerce platfor and looking into if we can use Hangfire for scheduled jobs. The only problem that I see today is that we need to ship all our assemblies strong name signed and can't make a reference to Hangfire because of the lack of strong name signed assemblies.

From aspnet/DataProtection#245 (comment) that davidfowl write

Package authors realistically all need to be strong named and we (Microsoft) need to fix the .NET Framework to not require binding redirects to truly solve the problems that people hit (I'm fighting for this, again 😄).

Is there any possibility that atleast the "core" package (this repro) can be strong name signed?

---

I found the following issued about strong naming signing

• Sign assemblies with strong names #1 Sign assemblies with strong names was closed because of service stack not was signed
• Consider about ServiceStack.* dependencies #41 Consider about ServiceStack.* dependencies was removing service stack, in the descriptions it says that you want Hangfire to be signed.
• To sign or not to sign the assemblies #54 To sign or not to sign the assemblies was closed with comment that you not believe that anybody need it, but a comment on that issue exists from user that needing strong named version.

And if we check the thirdparty that are used and if the support strong naming for this repo

• Owin
• Microsofts.* all assemblies are strong name signed
• Ssytem.* all assemblies are strong name signed
• Dapper, it exists a Dapper.StringNaming that is a signed replacement and it looks like V2 will only be strong name signed Dapper v3 planning and discussion DapperLib/Dapper#688
• CronExpressionDescriptor
• Newtonsoft.Json
• NCrontab, it exists NCrontab.Signed that is a signed replacement
• StackExchange.Redis (part of Hangfire.Pro), it exists StackExchange.Redis.StrongName that is a signed replacement and it looks like V2 will only be strong name signed StackExchange.Redis: Version 2.x Planning StackExchange/StackExchange.Redis#528

Dependencies that is placing source into Hangfire is not relevant to be strong name signed

• LibLog
• MoreLinq.Source.MoreEnumerable.Pairwise
• StackTraceFormatter.Source
• StackTraceParser.Source

[thoemmi]

For MahApps.Metro we decided against strong naming, see StrongName signed assembly? Hey, it's 2017...:

Strong-named assemblies are only useful in some rare scenarios. If you need strong-named assembly then you can compile the source by yourself ore use the Strong Namer from Daniel Plaisted @dsplaisted or Strong-Name Signer from Werner van Deventer @brutaldev.

More informations about the reason of this decision can be found here:

• Still Strong-Naming your Assemblies? You do know it’s 2016, right?
• XAML Behaviors UWP Managed 1.1.0
• Strong-Named Assemblies

[Tasteful]

@thoemmi It is possible for use to do either strong name signing by our self or use the Strong-Name Signer, but if we do that we need to distribute the signed version out to all our partner developers that are using the platform and in that case it's a question if we will violate the license terms to publish another version of hangfire that is strong name signed. We also need to put maintenance time to update that version with all changes from the this repo that not is needed if the orignal assembly is strong name signed or that the project automatic (conditions is proj-file) is building two different versions and distribute with every release.

Strong-Name Signer is working great for package consumers but not for package authors.

[sandorfr]

@thoemmi I don't find the article you linked very relevant. It's based on a lot of assumptions. I remember that the runtime can optimize some runtime check on the full framework when it's signed. And here is the best comment on the matter : aspnet/DataProtection#245 (comment)

But besides that point, the current Hangfire.Redis.Pro references the unsigned version of StackExchange.Redis where the Microsoft.AspNetCore.All is using the strong named version and they conflict.

[milindk0404]

Hi All,
I am using Hangfire.Redis.StackExchange with Hangfire.(.net core 2.0)
As "ConnectionMultiplexer" exists in both StackExchange.Redis.StrongName(in .net core) and StackExchange.Redis(in Hangfire.Redis.StackExchange as dependent dll), I am not able to build the project. Could you guide me to resolve this?

Error:
The type 'ConnectionMultiplexer' exists in both 'StackExchange.Redis.StrongName, Version=1.2.4.0, Culture=neutral, PublicKeyToken=c219ff1ca8c2ce46' and 'StackExchange.Redis, Version=1.2.6.0, Culture=neutral, PublicKeyToken=null'

Tired this trick also(Did not solve):
[https://stackoverflow.com/questions/46047718/stackexchange-redis-strongname-is-refrenced-but-not-included-as-package?rq=1]

Milind

[luizfbicalho]

Any news about this?

There is no downside to sign, and it would help the use in other projects.

I don't understand the deal, it's clear to me that it is better to sign

[augustoproiete]

Hey @odinserj, any plans to merge and release #1177 to resolve this issue?

[achimismaili]

Workaround:
I found the following nuget package very useful, that takes care of signing every reference of a project during build. A build target for singing all reference is added automatically since the most recent version. For me, it worked with Hangfire. It also works when called from console.

Nuget
https://www.nuget.org/packages/Brutal.Dev.StrongNameSigner/

Project
https://github.com/brutaldev/StrongNameSigner

[augustoproiete]

@achimismaili Unfortunately the workaround has issues in some cases

[Tasteful]

@achimismaili did you read the above comments? As I pointed out in an early comment the self signed version is working great in solutions, but now when you deliver packages that someone else is using.

[achimismaili]

I agree with you, @caioproiete & @Tasteful. Yes, this is not a solution, just a workaround for some scenarios.
I found this issue when looking for a solution to my problem and the title and initial description well fit to my problem, so I documented the solution I found.
When re-reading the comments of this issue again in detail now, I see that you got already past the self signing and that the nuget package I was referring to was even already mentioned by @thoemmi before.
Sorry for that.

[luizfbicalho]

Any updates on this question?

[augustoproiete]

@odinserj @quinvit I'd be happy to submit a PR for this one. LMK