Skip to content

Enable Strong Name Signing #416

Description

@anuj-modi

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

Activity

  1. atakavci commented on Apr 30, 2025

    @atakavci
    Collaborator

    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.

  2. anuj-modi commented on Apr 30, 2025

    @anuj-modi
    Author

    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.

  3. mgravell commented on Jul 28, 2025

    @mgravell
    Collaborator

    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?

  4. mgravell commented on Jul 28, 2025

    @mgravell
    Collaborator

    Closing this out in deference to the older #99 - but emphasizing that the discussion here is more timely and relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions