[GH-ISSUE #75] Use NuGet package, but no automatic signing of assemblies #65

New issue

Closed

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

kerem commented

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

Owner

Originally created by @MarcelVersteeg on GitHub (Nov 8, 2022).
Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/75

I have created issue #74 before about this. That issue was closed, but even after your response it is still reproducible. I have duplicated my remark to that issue here.

My project file looks like this (kept out unnecessary details):

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

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>net481</TargetFrameworks>
    ....
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
  </PropertyGroup>
   ....
  <ItemGroup>
    <PackageReference Include="Brutal.Dev.StrongNameSigner" Version="3.1.1" />
    <PackageReference Include="Vestris.ResourceLib" Version="2.1.0">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
  </ItemGroup>
  <Target Name="SignResourceLib" BeforeTargets="ResolveAssemblyReferences" Condition=" '$(TargetDir)' != '' " Inputs="$(SolutionDir)bin\_packages\vestris.resourcelib\2.1.0\lib\net45\Vestris.ResourceLib.dll" Outputs="$(SolutionDir)bin\_signed\Vestris.ResourceLib.dll">
    <Exec Command="&quot;$(StrongNameSignerDirectory)StrongNameSigner.Console&quot; -in &quot;$(SolutionDir)bin\_packages\vestris.resourcelib\2.1.0\lib\net45&quot; -out &quot;$(SolutionDir)bin\_signed&quot;" WorkingDirectory="$(SolutionDir)" />
  </Target>

</Project>

The target is executed as expected and signs the Vetris.ResourceLib.dll. However, when I look at the build output, there is also another task being executed that seems to try to sign all DLLs in my entire tree. This is what I see in the output (verbosity level "Normal"):

Target StrongNameSignerTarget:
  -- Starting Brutal Developer .NET Assembly Strong-Name Signer Task --
  <a lot of assemblies from alll kinds of folders are "added for processing">
  -- Finished Brutal Developer .NET Assembly Strong-Name Signer Task in 00:00:01.4505714 --

This StrongNameSignerTarget is the target that is started automatically, and is not explicitly referenced in the project. @brutaldev How can I prevent this target to run?

Originally created by @MarcelVersteeg on GitHub (Nov 8, 2022). Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/75 I have created issue #74 before about this. That issue was closed, but even after your response it is still reproducible. I have duplicated my remark to that issue here. My project file looks like this (kept out unnecessary details): ``` <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFrameworks>net481</TargetFrameworks> .... </PropertyGroup> <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "> <DebugSymbols>true</DebugSymbols> <DebugType>full</DebugType> <Optimize>false</Optimize> <DefineConstants>DEBUG;TRACE</DefineConstants> </PropertyGroup> .... <ItemGroup> <PackageReference Include="Brutal.Dev.StrongNameSigner" Version="3.1.1" /> <PackageReference Include="Vestris.ResourceLib" Version="2.1.0"> <PrivateAssets>all</PrivateAssets> <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets> </PackageReference> </ItemGroup> <Target Name="SignResourceLib" BeforeTargets="ResolveAssemblyReferences" Condition=" '$(TargetDir)' != '' " Inputs="$(SolutionDir)bin\_packages\vestris.resourcelib\2.1.0\lib\net45\Vestris.ResourceLib.dll" Outputs="$(SolutionDir)bin\_signed\Vestris.ResourceLib.dll"> <Exec Command=""$(StrongNameSignerDirectory)StrongNameSigner.Console" -in "$(SolutionDir)bin\_packages\vestris.resourcelib\2.1.0\lib\net45" -out "$(SolutionDir)bin\_signed"" WorkingDirectory="$(SolutionDir)" /> </Target> </Project> ``` The target is executed as expected and signs the Vetris.ResourceLib.dll. However, when I look at the build output, there is also another task being executed that seems to try to sign all DLLs in my entire tree. This is what I see in the output (verbosity level "Normal"): ``` Target StrongNameSignerTarget: -- Starting Brutal Developer .NET Assembly Strong-Name Signer Task -- <a lot of assemblies from alll kinds of folders are "added for processing"> -- Finished Brutal Developer .NET Assembly Strong-Name Signer Task in 00:00:01.4505714 -- ``` This `StrongNameSignerTarget` is the target that is started automatically, and is not explicitly referenced in the project. @brutaldev How can I prevent this target to run?

kerem closed this issue

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

kerem commented

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

Author

Owner

@MarcelVersteeg commented on GitHub (Nov 9, 2022):

I found the solution to this issue myself now. It is not an issue with the package. When adding the NuGet package to the project, exclude the build asset from the dependency, by either adding that to the dependency properties, or by editing the project file like this:

<PackageReference Include="Brutal.Dev.StrongNameSigner" Version="3.1.1">
    <ExcludeAssets>build</ExcludeAssets>
</PackageReference>

@MarcelVersteeg commented on GitHub (Nov 9, 2022): I found the solution to this issue myself now. It is not an issue with the package. When adding the NuGet package to the project, exclude the `build` asset from the dependency, by either adding that to the dependency properties, or by editing the project file like this: ``` <PackageReference Include="Brutal.Dev.StrongNameSigner" Version="3.1.1"> <ExcludeAssets>build</ExcludeAssets> </PackageReference> ```

kerem commented

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

Author

Owner

@brutaldev commented on GitHub (Nov 9, 2022):

@MarcelVersteeg Thanks for the info, I hope this can be helpful to other and I might just add it to the documentation as well.

@brutaldev commented on GitHub (Nov 9, 2022): @MarcelVersteeg Thanks for the info, I hope this can be helpful to other and I might just add it to the documentation as well.