[GH-ISSUE #61] SNS is modifying assemblies in the NuGet package cache

kerem commented

2026-02-25 21:30:34 +03:00

Owner

Originally created by @robertmclaws on GitHub (Mar 27, 2021).
Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/61

Originally assigned to: @brutaldev on GitHub.

I'm trying to compile the RESTier project using this library, and since the project binaries are signed, and their internals are exposed to the unit test projects, I also need to strong name the unit tests. One of the libraries it uses (Simple.OData.Client) is not signed, so we're using this NuGet package to sign it.

That client references NuGet package dependencies that are already signed, but SNS is doing two things:

It is re-signing dependent binaries that are already signed
it is modifying those binaries in the NuGet package cache, which is breaking every other project that depends on them.

This is the Microsoft.OData.Core binary in the NuGet package cache BEFORE compiling my project with SNS:

This is that binary afterward:

This is breaking all my builds, because once the dependent binaries are modified, the assembly identity is broken, and the build can't find the proper types. And when I say all my builds, I also mean any other application on my machine that also uses those packages.

I've tried several different ways to disable to Targets from executing, with no luck.

SNS should not be re-signing binaries that are already signed.
SNS should not be modifying files in the package cache directly, it should be copying them to a temp folder and then copying them to the build folder.
SNS should either a) have a project property that lets you specify binaries to sign, or b) have a flag that shuts off dependent binary signing.

Is there any way to quickly get this problem fixed so we can get a new build out? Thanks a bunch!

Originally created by @robertmclaws on GitHub (Mar 27, 2021). Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/61 Originally assigned to: @brutaldev on GitHub. I'm trying to compile the [RESTier project](https://github.com/odata/restier) using this library, and since the project binaries are signed, and their internals are exposed to the unit test projects, I also need to strong name the unit tests. One of the libraries it uses (Simple.OData.Client) is not signed, so we're using this NuGet package to sign it. That client references NuGet package dependencies that are already signed, but SNS is doing two things: 1) It is re-signing dependent binaries that are already signed 2) it is modifying those binaries in the NuGet package cache, which is breaking every other project that depends on them. This is the Microsoft.OData.Core binary in the NuGet package cache BEFORE compiling my project with SNS: ![image](https://user-images.githubusercontent.com/1657085/112706951-0c668180-8e7e-11eb-8d84-a7d5759c198d.png) This is that binary afterward: ![image](https://user-images.githubusercontent.com/1657085/112706965-2ef89a80-8e7e-11eb-8163-40a515c4aea6.png) This is breaking all my builds, because once the dependent binaries are modified, the assembly identity is broken, and the build can't find the proper types. And when I say all my builds, I also mean any other application on my machine that also uses those packages. I've tried several different ways to disable to Targets from executing, with no luck. 1) SNS should not be re-signing binaries that are already signed. 2) SNS should not be modifying files in the package cache directly, it should be copying them to a temp folder and then copying them to the build folder. 3) SNS should either a) have a project property that lets you specify binaries to sign, or b) have a flag that shuts off dependent binary signing. Is there any way to quickly get this problem fixed so we can get a new build out? Thanks a bunch!

kerem

2026-02-25 21:30:34 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-25 21:30:34 +03:00

Author

Owner

@brutaldev commented on GitHub (Mar 29, 2021):

Re-signing would be a necessary process since any changes to the assemblies. When this was developed it would simply scan and fix you local "packages" directory so would not impact any other projects since everyone has their own copies.

Due to how packages are shared in a central location these days there would need to be some work done as to how this is managed, resigning the whole packages directory was never a good idea and now it's compounded by everything sharing from the same place and multiple versions etc.

For now you will have to use the build targets to manually point it to your assembly locations rather than it scanning your references: https://github.com/brutaldev/StrongNameSigner#build-process

@brutaldev commented on GitHub (Mar 29, 2021): Re-signing would be a necessary process since any changes to the assemblies. When this was developed it would simply scan and fix you local "packages" directory so would not impact any other projects since everyone has their own copies. Due to how packages are shared in a central location these days there would need to be some work done as to how this is managed, resigning the whole packages directory was never a good idea and now it's compounded by everything sharing from the same place and multiple versions etc. For now you will have to use the build targets to manually point it to your assembly locations rather than it scanning your references: https://github.com/brutaldev/StrongNameSigner#build-process

kerem commented

2026-02-25 21:30:34 +03:00

Author

Owner

@robertmclaws commented on GitHub (Mar 29, 2021):

Thanks for the details! Some feedback:

I tried that process for modifying the build manually, it doesn't work anymore. It's automatically overridden by the .targets file in the package, and there is no MSBuild variable in the .targets file that will allow you to skip using the target. Plus, those instructions are not enough to make the process work from the NuGet Package cache.
If an assembly referenced by the package is already signed, it does not need to be re-signed. As an example, Microsoft already strong name signs its assemblies, and modifying them will break ASP.NET web applications that rely on assembly binding redirects in the web.config or app.config file.

Your package "worked" in the days of /packages folders and separate NuGet manifests. It does not work in the world of SDK projects, tags, and shared package caches. Instead of using brutal tactics, it needs to get surgical about what it is signing, and where it is doing the work.

It should analyze the tree for which assemblies are already signed and ignore ones that are.
It should copy all assemblies that need to be re-signed to a temp folder and sign them from there.
It should copy the resulting files to the bin folder of the project.
After the build is finished, it should clean up it should delete the temp folder from the system.
Its operation should be 100% configurable using MSBuild variables, including folder locations to check, or individual assembly names to include or exclude.

Happy to potentially assist, if necessary.

@robertmclaws commented on GitHub (Mar 29, 2021): Thanks for the details! Some feedback: - I tried that process for modifying the build manually, it doesn't work anymore. It's automatically overridden by the .targets file in the package, and there is no MSBuild variable in the .targets file that will allow you to skip using the target. Plus, those instructions are not enough to make the process work from the NuGet Package cache. - If an assembly referenced by the package is already signed, it *does not* need to be re-signed. As an example, Microsoft already strong name signs its assemblies, and modifying them will break ASP.NET web applications that rely on assembly binding redirects in the web.config or app.config file. Your package "worked" in the days of /packages folders and separate NuGet manifests. It does not work in the world of SDK projects, <PackageReference> tags, and shared package caches. Instead of using brutal tactics, it needs to get surgical about what it is signing, and where it is doing the work. - It should analyze the tree for which assemblies are already signed and ignore ones that are. - It should copy all assemblies that need to be re-signed to a temp folder and sign them from there. - It should copy the resulting files to the bin folder of the project. - After the build is finished, it should clean up it should delete the temp folder from the system. - Its operation should be 100% configurable using MSBuild variables, including folder locations to check, or individual assembly names to include or exclude. Happy to potentially assist, if necessary.

kerem commented

2026-02-25 21:30:34 +03:00

Author

Owner

@brutaldev commented on GitHub (Mar 31, 2021):

Remove the nuget package and install the console version to use the custom build targets.

I'm not in a position to update this project so you are welcome to fork it and make the changes necessary for modern projects that use the cache. I only use this myself for older projects where signing was important. These days nothing is strong-name signed anymore as it's seen as an anti-pattern and breaks things more than it fixes.

Files are copied to temp locations and backed up, problem is they need to return to the source since a reference is disk location based.

@brutaldev commented on GitHub (Mar 31, 2021): Remove the nuget package and install the console version to use the custom build targets. I'm not in a position to update this project so you are welcome to fork it and make the changes necessary for modern projects that use the cache. I only use this myself for older projects where signing was important. These days nothing is strong-name signed anymore as it's seen as an anti-pattern and breaks things more than it fixes. Files are copied to temp locations and backed up, problem is they need to return to the source since a reference is disk location based.

kerem commented

2026-02-25 21:30:34 +03:00

Author

Owner

@rcdailey commented on GitHub (Aug 13, 2021):

These days nothing is strong-name signed anymore as it's seen as an anti-pattern and breaks things more than it fixes.

This just isn't true. For example the yFiles library license requires all libraries using their interfaces to be strong named. Does that suck? Sure does. Is it avoidable? Nope. Open source projects have a lot more freedom on this than established enterprise software projects.

The direction I took was to just copy & paste the console EXE into my repository and set up my own custom targets to invoke it so it processes assemblies in my bin directory. It sucks but it works so far.

@rcdailey commented on GitHub (Aug 13, 2021): > These days nothing is strong-name signed anymore as it's seen as an anti-pattern and breaks things more than it fixes. This just isn't true. For example the yFiles library license requires all libraries using their interfaces to be strong named. Does that suck? Sure does. Is it avoidable? Nope. Open source projects have a lot more freedom on this than established enterprise software projects. The direction I took was to just copy & paste the console EXE into my repository and set up my own custom targets to invoke it so it processes assemblies in my bin directory. It sucks but it works so far.

kerem commented

2026-02-25 21:30:34 +03:00

Author

Owner

@brutaldev commented on GitHub (Dec 30, 2021):

Package cache directories are now correctly ignored in v3.0.6-beta: https://www.nuget.org/packages/Brutal.Dev.StrongNameSigner/3.0.6-beta

@brutaldev commented on GitHub (Dec 30, 2021): Package cache directories are now correctly ignored in v3.0.6-beta: https://www.nuget.org/packages/Brutal.Dev.StrongNameSigner/3.0.6-beta

kerem commented

2026-02-25 21:30:34 +03:00

Author

Owner

@brutaldev commented on GitHub (Dec 30, 2021):

Official release: https://www.nuget.org/packages/Brutal.Dev.StrongNameSigner/3.1.0

@brutaldev commented on GitHub (Dec 30, 2021): Official release: https://www.nuget.org/packages/Brutal.Dev.StrongNameSigner/3.1.0

kerem referenced this issue

2026-02-25 21:30:41 +03:00

[PR #67] [MERGED] 3.1.0 beta to production changes. #99

Rows
Columns

[GH-ISSUE #61] SNS is modifying assemblies in the NuGet package cache #52