Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use NuGet package, but no automatic signing of assemblies #74

Closed
MarcelVersteeg opened this issue Nov 2, 2022 · 2 comments
Closed

Use NuGet package, but no automatic signing of assemblies #74

MarcelVersteeg opened this issue Nov 2, 2022 · 2 comments

Comments

@MarcelVersteeg
Copy link

Via a third-party NuGet package I obtain an unsigned assembly I need for my application. I want to use the StrongNameSigner to only sign this single assembly, so I added the StrongNameSigner NuGet package to my application's project. This makes in unnecessary for other people in my team to install the StrongNameSigner separately when building the projects.

However, by adding the StrongNameSigner NuGet package to my project, all assemblies in the target directory are automatically processed. Is there a way to disable this automatic processing, or to specify which assembly/assemblies I want to be processed via this automatic mechanism?

@brutaldev
Copy link
Owner

Second example in the docs: https://github.com/brutaldev/StrongNameSigner#build-process

Example of targeting one package folder.

<Target Name="BeforeBuild">
  <Exec ContinueOnError="false"
        Command="&quot;..\packages\Brutal.Dev.StrongNameSigner.3.1.1\build\StrongNameSigner.Console.exe&quot; -in &quot;..\packages\elmah.corelibrary.1.2.2&quot;" />
</Target>

You can remove the other targets that are created in your project file that perform a full signing operation.

@MarcelVersteeg
Copy link
Author

MarcelVersteeg commented Nov 3, 2022

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants