Repository navigation
Enable Strong Name Signing #416
Description
Activity
hi @anuj-modi , thank you for using NRedisStack and letting us hear about your case.
I noticed there have been other requests related to signing, but it seems it didn't make to the master branch anyway. I'll need to look into those requests further to understand all the details. It also appears there might be some confusion around package signing vs strong-naming the binary.
Having said that, it's clear that your request specifically concerns strong-naming the binary. There are a couple things to evaluate there too, especially with open-source projects as i read. 👉 https://github.com/dotnet/runtime/blob/main/docs/project/strong-name-signing.md
I ll dig in more and keep it updated here. For the time being we are busy with other tasks so i can not provide a clear timeline for it.
Hi @atakavci. Definitely appreciate you taking a look at this. I made a PR that adds the strong name signing. I understand there are more considerations on top of simply doing the signing, but hopefully this makes your job a little easier.
Changing (including adding) strong name signing is a very hard break; that doesn't mean it can't be done, but it requires very careful consideration and has major implications - it needs communication and a "major" semver release. It can be done, though - we did it for StackExchange.Redis
community guidance includes:
❌ DO NOT add, remove, or change the strong naming key.
and
❌ DO NOT publish strong-named and non-strong-named versions of your library. For example, Contoso.Api and Contoso.Api.StrongNamed.
There's also the reality it "only" really impacts netfx. The air quotes there are because I don't intend that to be dismissive - I understand that many people still limited to netfx, but: this problem simply goes away in modern .NET, and the benefits of adding a strong-name on the net8 (for example) build is highly questionable. That said, I'm not proposing "strong name on netfx only" - that level of inconsistency would also make me itch somewhat.
It is perhaps unfortunate that there was a 1.0.0 just 3 months ago - we could have fixed this more cleanly as, say, a 1.0.0-beta2 followed by a 1.0.0 both strong named.
But: it we want to fix this, sooner is probably better. My suggestion, therefore, is we simply eat the hard break, add the strong name, and re-issue as 2.0.0. Thoughts, @atakavci in particular?
Closing this out in deference to the older #99 - but emphasizing that the discussion here is more timely and relevant.
Microsoft's Semantic Kernel framework has a capability to use Redis as a Vector store for AI applications. The Redis connector package is Strong name signed and thus requires all of its dependencies to also be strong name signed in order to load successfully. NRedisStack needs to enable Strong Name signing in order to support using htis package from .NET Framework applications.
The issue I opened with Semantic Kernel is here: microsoft/semantic-kernel#11807