[GH-ISSUE #73] Transitive dependencies from PackageReferences are not investigated/signed #61

New issue

Closed

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

kerem commented

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

Owner

Originally created by @DoctorVanGogh on GitHub (Oct 27, 2022).
Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/73

I've come across a tricky issue with StrongNameSigner.

If you have a nuget package referenced via PackageReference but that package is (mostly) a metapackage - meaning it has a lots of dependencies into other nuget packages - StrongNameSigner will only - if ever - sign the direct dependency.

If you have dependencies like

Project
  nuget -> Foo
    nuget -> Bar
    nuget -> Baz
  nuget -> StrongNameSigner

Only the direct assemblies from Foo will ever get looked at.

Here's an example project & program:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>net472;net6.0</TargetFrameworks>
    <ImplicitUsings>disable</ImplicitUsings>
    <Nullable>disable</Nullable>
    <SignAssembly>True</SignAssembly>
    <AssemblyOriginatorKeyFile>foo.snk</AssemblyOriginatorKeyFile>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Brutal.Dev.StrongNameSigner" Version="3.1.1" />
    <PackageReference Include="Nito.AsyncEx" Version="5.1.2" />
  </ItemGroup>

</Project>

using Nito.AsyncEx;
using System;
using System.Threading.Tasks;

namespace Demo {
    public class Program {
        public async static Task Main(string[] args) {
            Console.WriteLine("Waiting...");
            var al = new AsyncLazy<int>(Foo);

            Console.WriteLine(await al);
        }

        public async static Task<int> Foo() {
            await Task.Delay(2000);
            return 42;
        }
    }
}

SNS will not sign anything in this situation.
And of course, the resulting assembly wont run :(

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'Nito.AsyncEx.Coordination, Version=5.1.2.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)

Should this be supported by SNS?

Originally created by @DoctorVanGogh on GitHub (Oct 27, 2022). Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/73 I've come across a tricky issue with StrongNameSigner. If you have a nuget package referenced via `PackageReference` but that package is (mostly) a metapackage - meaning it has a lots of dependencies into *other* nuget packages - StrongNameSigner will only - if ever - sign the direct dependency. If you have dependencies like ``` Project nuget -> Foo nuget -> Bar nuget -> Baz nuget -> StrongNameSigner ``` Only the direct assemblies from Foo will ever get looked at. Here's an example project & program: ```xml <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFrameworks>net472;net6.0</TargetFrameworks> <ImplicitUsings>disable</ImplicitUsings> <Nullable>disable</Nullable> <SignAssembly>True</SignAssembly> <AssemblyOriginatorKeyFile>foo.snk</AssemblyOriginatorKeyFile> </PropertyGroup> <ItemGroup> <PackageReference Include="Brutal.Dev.StrongNameSigner" Version="3.1.1" /> <PackageReference Include="Nito.AsyncEx" Version="5.1.2" /> </ItemGroup> </Project> ``` ```cs using Nito.AsyncEx; using System; using System.Threading.Tasks; namespace Demo { public class Program { public async static Task Main(string[] args) { Console.WriteLine("Waiting..."); var al = new AsyncLazy<int>(Foo); Console.WriteLine(await al); } public async static Task<int> Foo() { await Task.Delay(2000); return 42; } } } ``` SNS will not sign anything in this situation. And of course, the resulting assembly wont run :( ``` Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'Nito.AsyncEx.Coordination, Version=5.1.2.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044) ``` *Should* this be supported by SNS?

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 (Oct 27, 2022):

This should be supported and should work because for each referenced assembly the entire dependency tree is traversed and all unsigned references will get signed and their references changed in the parent.

Thanks for the example code, will reproduce this and see if it can be fixed. I think your mention of "metepackage" might be the root cause because there is not direct reference to an assembly to start traversing from.

@brutaldev commented on GitHub (Oct 27, 2022): This _should_ be supported and _should_ work because for each referenced assembly the entire dependency tree is traversed and all unsigned references will get signed and their references changed in the parent. Thanks for the example code, will reproduce this and see if it can be fixed. I think your mention of "metepackage" might be the root cause because there is not direct reference to an assembly to start traversing from.

kerem commented

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

Author

Owner

@nickrandolph commented on GitHub (Dec 13, 2022):

@brutaldev doesn't the code exclude any references coming from nuget packages?
see github.com/brutaldev/StrongNameSigner@c38d42ab8d/src/Brutal.Dev.StrongNameSigner/AutomaticBuildTask.cs (L73)

@nickrandolph commented on GitHub (Dec 13, 2022): @brutaldev doesn't the code exclude any references coming from nuget packages? see https://github.com/brutaldev/StrongNameSigner/blob/c38d42ab8d1444504720a62736b310303236cd85/src/Brutal.Dev.StrongNameSigner/AutomaticBuildTask.cs#L73

kerem commented

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

Author

Owner

@dansiegel commented on GitHub (Dec 13, 2022):

technically I believe that these lines would also exclude NuGet references. This seems like the wrong approach as you likely want any unsigned references (particularly NuGet references) to also be signed.

github.com/brutaldev/StrongNameSigner@c38d42ab8d/src/Brutal.Dev.StrongNameSigner/AutomaticBuildTask.cs (L68-L71)

@dansiegel commented on GitHub (Dec 13, 2022): technically I believe that these lines would also exclude NuGet references. This seems like the wrong approach as you likely want any unsigned references (particularly NuGet references) to also be signed. https://github.com/brutaldev/StrongNameSigner/blob/c38d42ab8d1444504720a62736b310303236cd85/src/Brutal.Dev.StrongNameSigner/AutomaticBuildTask.cs#L68-L71

kerem referenced this issue

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

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