[GH-ISSUE #80] SDK style probjects supported? #64

New issue

Closed

opened 2026-02-25 21:30:35 +03:00 by kerem · 4 comments

kerem commented

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

Owner

Originally created by @kirillkovalenko on GitHub (Dec 18, 2022).
Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/80

Originally assigned to: @brutaldev on GitHub.

I trying to use strong name signer tool to have a new 3rd party dependency assembly signed automatically. It seems that the tool finds in project dependencies referenced via ProjectReference, but does not process those referenced via PackageReference tag. Is SDK style not supported or it's me doing something wrong?

Build started...
1>------ Build started: Project: Client, Configuration: Debug Any CPU ------
1>-- Starting Brutal Developer .NET Assembly Strong-Name Signer Task --
1>Adding 'Contracts.dll' for processing.
1>Adding 'Core.dll' for processing.
1>Adding 'Directory.dll' for processing.
1>Adding 'Interop.WtsApi.dll' for processing.
1>Checking assembly references in 'Contracts.dll'.
1>Checking assembly references in 'Core.dll'.
1>Checking assembly references in 'Directory.dll'.
1>Checking assembly references in 'Interop.WtsApi.dll'.
1>Removing invalid friend reference from assembly 'Core.dll'.
1>Removing invalid friend reference from assembly 'Core.dll'.
1>Removing invalid friend reference from assembly 'Directory.dll'.
1>-- Finished Brutal Developer .NET Assembly Strong-Name Signer Task in 00:00:13.9144618 --
1>CSC : warning CS8002: Referenced assembly 'NtApiDotNet, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.

Originally created by @kirillkovalenko on GitHub (Dec 18, 2022). Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/80 Originally assigned to: @brutaldev on GitHub. I trying to use strong name signer tool to have a new 3rd party dependency assembly signed automatically. It seems that the tool finds in project dependencies referenced via `ProjectReference`, but does not process those referenced via `PackageReference` tag. Is SDK style not supported or it's me doing something wrong? ```text Build started... 1>------ Build started: Project: Client, Configuration: Debug Any CPU ------ 1>-- Starting Brutal Developer .NET Assembly Strong-Name Signer Task -- 1>Adding 'Contracts.dll' for processing. 1>Adding 'Core.dll' for processing. 1>Adding 'Directory.dll' for processing. 1>Adding 'Interop.WtsApi.dll' for processing. 1>Checking assembly references in 'Contracts.dll'. 1>Checking assembly references in 'Core.dll'. 1>Checking assembly references in 'Directory.dll'. 1>Checking assembly references in 'Interop.WtsApi.dll'. 1>Removing invalid friend reference from assembly 'Core.dll'. 1>Removing invalid friend reference from assembly 'Core.dll'. 1>Removing invalid friend reference from assembly 'Directory.dll'. 1>-- Finished Brutal Developer .NET Assembly Strong-Name Signer Task in 00:00:13.9144618 -- 1>CSC : warning CS8002: Referenced assembly 'NtApiDotNet, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name. ```

kerem closed this issue

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

kerem commented

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

Author

Owner

@brutaldev commented on GitHub (Dec 18, 2022):

@kirillkovalenko Do you have a basic sample project that I can test with?

@brutaldev commented on GitHub (Dec 18, 2022): @kirillkovalenko Do you have a basic sample project that I can test with?

kerem commented

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

Author

Owner

@kirillkovalenko commented on GitHub (Dec 19, 2022):

I've created a simple project Sns80.zip

BTW, does your tool respect AssemblyOriginatorKeyFile MsBuild property?

@kirillkovalenko commented on GitHub (Dec 19, 2022): I've created a simple project [Sns80.zip](https://github.com/brutaldev/StrongNameSigner/files/10258036/Sns80.zip) BTW, does your tool respect `AssemblyOriginatorKeyFile` MsBuild property?

kerem commented

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

Author

Owner

@brutaldev commented on GitHub (Dec 19, 2022):

BTW, does your tool respect AssemblyOriginatorKeyFile MsBuild property?

No, it's completely separate from any MSBuild specifics that project files could be using and you would need to pass you key file in the same way.

The problem you are experiencing with your project is related to PR #78
Package references go into cache directories such as C:\Users\USER_NAME\.nuget\packages\ntapidotnet, the locations are explicitly excluded with the automatic build task because there are usually thousands of packages in there, none of which we want to traverse and check for each project's build unnecessarily.

A solution now would be to sign explicitly using the console application with build events as described here: https://github.com/brutaldev/StrongNameSigner#build-process
You could also sign using the application, re-publish to your own local (or private NuGet repository) or just reference the final signed file directly. Ther project you are referring to is also open source so you could request from the developers to sign it or fork your own version, sign it and make another NuGet package for them.

You have a lot of options that make it not necessary to use this tool since it is intended as a last resort.

@brutaldev commented on GitHub (Dec 19, 2022): > BTW, does your tool respect AssemblyOriginatorKeyFile MsBuild property? No, it's completely separate from any MSBuild specifics that project files could be using and you would need to pass you key file in the same way. The problem you are experiencing with your project is related to PR #78 Package references go into cache directories such as `C:\Users\USER_NAME\.nuget\packages\ntapidotnet`, the locations are explicitly excluded with the automatic build task because there are usually thousands of packages in there, none of which we want to traverse and check for each project's build unnecessarily. A solution now would be to sign explicitly using the console application with build events as described here: https://github.com/brutaldev/StrongNameSigner#build-process You could also sign using the application, re-publish to your own local (or private NuGet repository) or just reference the final signed file directly. Ther project you are referring to is also open source so you could request from the developers to sign it or fork your own version, sign it and make another NuGet package for them. You have a lot of options that make it not necessary to use this tool since it is intended as a last resort.

kerem commented

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

Author

Owner

@kirillkovalenko commented on GitHub (Dec 20, 2022):

A solution now would be to sign explicitly using the console application

Thanks, I've already implemented this approach.

@kirillkovalenko commented on GitHub (Dec 20, 2022): > A solution now would be to sign explicitly using the console application Thanks, I've already implemented this approach.

kerem referenced this issue

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

[PR #64] [MERGED] Introduce a new option -sk, to keep files struture in output directory. #97