You can just use https://github.com/brutaldev/StrongNameSigner

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

Just use SttongNameSigner

I'm getting

CSC : warning CS8002: Referenced assembly 'TUnit.Core, Version=0.4.105.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.

Ya, I could strong name it myself, @jzabroski. But why should I and everyone else who hits this have to do so, when it can be strong named when originally built to solve the problem for everyone who has it at once?

@thomhurst with #1436 adding support (theoretically) for .NET Framework test projects, this strong naming issue is now the blocker for any repo that strong names its projects. For my part, all of my repos always strong name sign all projects, since it adds value at least on .NET Framework and expands the set of users that can reference the projects.

Adding a strong name is a binary breaking change for .NET Framework, but not for .NET.

My .NET Framework targeted projects are failing with:

   Tests failed:
      Unhandled Exception: System.TypeInitializationException: The type initializer for '<Module>' threw an exception. ---> System.IO.FileLoadException:
       Could not load file or assembly 'TUnit.Core, Version=0.6.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named
      assembly is required. (Exception from HRESULT: 0x80131044)
         at .cctor()
         --- End of inner exception stack trace ---

Can you please add a strong name?
You don't need to worry about keeping the private key a secret. The .NET team has publicly documented that strong naming isn't about security, and the simple snk file can be checked into your OSS github repo.

I'd be willing to submit the PR.

If security isn't an issue then sure. I haven't strongly signed stuff before so I'd need to look up how to do it. If you know what you're doing then great I'd be happy to accept a pr

Security isn't an issue.

@AArnott You can use StrongName Signer as a drop in replacement for not needing an SDK tool to sign assemblies. Just provide a key file and password as arguments. Then as long as you pack this rewritten assembly, you will ship nuget packages the same as your PR.

The advantage is it is a lot cleaner as you refactor dependencies imho. See the section of the readme that explains "dealing with delendencies".

I don't really care how it gets done tbqh.

@jzabroski:

You can use StrongName Signer as a drop in replacement for not needing an SDK tool to sign assemblies

We always have the SDK available during a build. How would avoiding a tool / feature it ships with and using a 3rd party one be an improvemenet?

Then as long as you pack this rewritten assembly, you will ship nuget packages the same as your PR.

Packing assemblies that already exist in other nuget packages can create a huge problem for your users, who may have dependencies on both packages. These folks will then get references to both copies of the assembly provided to the compiler, causing build breaks.

It seems a lot cleaner to just get dependencies to build strong named in the first place. IMO.