search

brutaldev / StrongNameSigner

Strong-name sign third party .NET assemblies without the source code.
https://brutaldev.com/post/net-assembly-strong-name-signer
Other
320 stars 68 forks source link

Recursing? #19

Closed jlegan closed 8 years ago

jlegan commented 8 years ago

Below is the snippet from my build task. During a build it gets into an infinite loop of signing and fixing references. On the second pass nothing needs to be signed (verified with your GUI as well) and no references are fixed. Can you think of what might be causing this? This is VS2015 U1 though I doubt it is at play.

<Target Name="BeforeBuild"> <Exec ContinueOnError="false" Command="&quot;$(ProjectDir)..\packages\Brutal.Dev.StrongNameSigner.1.6.1\tools\StrongNameSigner.Console.exe&quot; -in &quot;$(ProjectDir)..\packages&quot;" /> </Target>

When I finally CTRL+BREAK the IDE build I have 1000's of lines of this

1> Fixing references to '..\packages\Microsoft.Net.Http.2.2.29\lib\portable-net45+win8+wpa81\System.Net.Http.Primitives.dll' in '..\packages\Microsoft.Net.Http.2.2.29\lib\sl4-windowsphone71\System.Net.Http.Primitives.dll'... 1> No assembly references to fix... 1> 1> Fixing references to '..\packages\Microsoft.Net.Http.2.2.29\lib\sl4-windowsphone71\System.Net.Http.dll' in '..\packages\Microsoft.Net.Http.2.2.29\lib\sl4-windowsphone71\System.Net.Http.Primitives.dll'... 1> No assembly references to fix... 1> 1> Fixing references to '..\packages\Microsoft.Net.Http.2.2.29\lib\sl4-windowsphone71\System.Net.Http.Extensions.dll' in '..\packages\Microsoft.Net.Http.2.2.29\lib\sl4-windowsphone71\System.Net.Http.Primitives.dll'... 1> No assembly references to fix... 1> 1> Fixing references to '..\packages\Microsoft.Net.Http.2.2.29\lib\win8\System.Net.Http.Extensions.dll' in '..\packages\Microsoft.Net.Http.2.2.29\lib\sl4-windowsphone71\System.Net.Http.Primitives.dll'... 1> No assembly references to fix...

brutaldev commented 8 years ago

What is probably happening is that there is a circular reference in a pair of assemblies. Since you are trying to sign your entire packages directory, the issue could be anywhere.

Can I suggest rather including only the directories that contain unsigned assemblies and their dependencies that you actually need to sign. Your build process will be a lot faster if you don't need to trawl through all the packages and every version of the libs that are included in them. An example is available under Dealing With Dependencies

jlegan commented 8 years ago

The only concern there (and maybe room for enhancement) is the lack of support for wildcards in directory names for the -in parameter. Nuget imposes the versioned directory construct on us as developers however Nuget packages get updated all of the time. To make the | delimited directory structure more user friendly might I suggest allow for wildcards (ie. "..\packages\elmah.corelibrary.**|..\packages\Elmah.MVC.*".

This would allow a developer to consume unsigned packages and not have to worry about updating .csproj files in bulk everytime someone rolls a 3rd party library on nuget.

I will grab the source and implement the feature for my own personal use and if you would like it pass it along. Thank you for all of your hard work.

brutaldev commented 8 years ago

Updating .csproj files is actually a pain point for my own projects as well, although the versions of unsigned assembly don't seem to change often enough to have bugged me.

I like the idea of adding wild card capabilities to the input directory list, I would certainly use it. You're welcome to submit a pull request with your changes and I'll make an official release for it. The only place that would need to handle the wildcards is here.

jlegan commented 8 years ago

20 is checked in. I don't have git setup on this box but I only had to touch two files and did a drag and drop check-in and pull request.

brutaldev commented 8 years ago

Workaround provided in release 1.7.0