Unable to sign squirrel.windows

[filippobottega]

I'have tried to add squirrel.windows nuget package after Brutal.Dev.StrongNameSigner to a WinForm application but Visual Studio 2015 uses 100% of CPU and resulting assemblies are not valid.

Best regards, Filippo.

[brutaldev]

Which version are you using and what are your paths you are providing to sign?

[filippobottega]

I have created a sample solution:

WindowsApplication1.zip

I'm not able to add Brutal.Dev.StrongNameSigner nuget package without getting errors.

Thank you for your support, Filippo.

[brutaldev]

I can't seem to figure this one out, it's all running correctly but not redirecting the reference paths to the newly signed files. MSBuild seems to be having a bit of a problem here, not the signing process. Making adjustment to the targets file but nothing seems to resolve it. Works with smaller projects with less references although it's doing the exact same thing in both cases...

As a workaround, just sign the assemblies manually from your project file: https://github.com/brutaldev/StrongNameSigner#build-process

Also remove the import that is causing all this trouble

<Import Project="packages\Brutal.Dev.StrongNameSigner.2.1.3\build\Brutal.Dev.StrongNameSigner.targets" Condition="Exists('packages\Brutal.Dev.StrongNameSigner.2.1.3\build\Brutal.Dev.StrongNameSigner.targets')" />

[groogiam]

@brutaldev I am not getting any error when I run this sample project in visual studio 2017. Add downloaded the WindowsApplication1 and then added the strong name signer nuget package to it. The project builds fine but none of the assemblies get signed. I turned on detailed build logging and it looks like one of the conditions is failing. I checked and the file exist on my file system but for some reason the condition fails.

Task "Error" skipped, due to false condition; (!Exists('packages\Brutal.Dev.StrongNameSigner.2.1.3\build\Brutal.Dev.StrongNameSigner.targets')) was evaluated as (!Exists('packages\Brutal.Dev.StrongNameSigner.2.1.3\build\Brutal.Dev.StrongNameSigner.targets')).

[brutaldev]

@rufio620 It's all related to weirdness in the MSBuild targets, even the error message you posted is similar to what I see and makes no sense. The errors don't help in debugging the problem which is why I haven't figured out why this happens.

Just use the solution in the above comment to get around it for now, I'll need to spend some time figuring out why the auto-signing build process freaks out sometimes.

[groogiam]

@brutaldev The performance of executing against the packages directory seems to be very poor. I've been executing for at least 10 minutes and there does not appear to be an end in sight. It seems like there is an issue with the assembly reference fix algorithm. It appears to be trying to fix references to assemblies that are not referenced in the current strong named assemblies metadata. For projects with large amounts of nuget packages (especially true for the .NET standard packages) this appears to be a major performance issue. I'm gonna try and rewrite the command line to specify specific packages to see if this helps. Although this becomes much more tedious to manage as any updates to nuget pacakges must be followed by a manuall edit to the strong build action.

[brutaldev]

@rufio620 This was largely addressed in issue #24.

Remember that multiple passes are required, as each assembly is signed, it needs to re-evaluate all assemblies again to determine if they were referencing newly signed assemblies, then all assemblies need to be re-evaluated again to determine if they where referencing any of those and so it goes on.

If you have a large number of assemblies then this is just compounded as as you can see, it can take forever since reading assemblies in to parse their meta data isn't a cheap operation. I really don't think it is tedious to include simple filters for the files you want to include in the signing process, you should actually know which assemblies are not signed that are causing build problems for you and only if you happen to introduce more unsigned assemblies would you need to introduce more filters.

Dealing with dependencies documentation section

Having unsigned assemblies is such an edge case already it's unlikely you'll ever update the filters once you've identified what you need to sign. Once the filters have been setup, you'll save more time than writing them in the first place as this will significantly speed up your build and highlight to other developers exactly what the offending assemblies are and what you are targeting.

Strong-name signing is really only useful for assemblies you want to add to the GAC. If you are strong-name signing your own assemblies and wanting to also sign/re-sign the .NET Core assemblies you're going to be in a world of hurt, rather just leave your stuff unsigned or at least filter out all the MS packages, they certainly are not referencing anything unsigned.

[brutaldev]

Tested the attached solution with the latest version (2.4.0) and it works perfectly.