Click once: Strong name validation failed...

[tom-englert]

The project builds and runs locally, but for published click once applications the strong name validation fails for the post-signed assemblies after download and the app won't install.

[brutaldev]

@tom-englert This is not nearly enough information to assist you. It's likely you are not signing the correct assemblies in a batch so references are not being fixed appropriately breaking the referential integrity. You may also be using an older version that does not automatically fix friend assembly references.

Please provide actual error messages, stack traces, a sample project, post-install commands, msbuild config, anything that could help identify if this is a bug or simply a misconfiguration.

[tom-englert]

After realizing it did not work for ClickOnce Apps I had to quickly rollback. I will try to make a reproducible sample.

[brutaldev]

This has been tested on ClickOnce application without an issue. You need to sign all files before creating the ClickOnce manifest since the manifest is also signed. My suggestion with all setups is to always sign your assemblies BEFORE anything, even compiling.

[tom-englert]

I've uploaded compile output and the detailed error message: http://1drv.ms/1GNr3jW Do you need anything else?

[tom-englert]

• The source code is at https://resxresourcemanager.codeplex.com/SourceControl/latest
• The version with the signing issue is in the Feature\Test branch.
• The click once app is the ResXManager project.
• You can ignore the ResXManager.VSIX project (it's not loadable if you don't have the VS SDK installed)

[tom-englert]

P.S. If you don't have Microsoft Code Contracts installed, you will get lots of Code Analysis warnings - just suppress them.

[brutaldev]

When it comes to the two assemblies being signed, it doesn't seem to like each assembly having a unique public key. I'll take this as a bug since the strong-name file generated could be used for all assemblies and this problem would be completely avoided quite easily.

To overcome the issue now, simply provide a key file to sign the assemblies with. You already have one in the root (Key.snk) so just use that until this gets corrected in 1.4.9.

Also just sign the two assemblies that actually need to be signed, this makes the build process much faster.

<Target Name="BeforeBuild">
  <Exec ContinueOnError="false" Command="&quot;..\packages\Brutal.Dev.StrongNameSigner.1.4.8\tools\StrongNameSigner.Console.exe&quot; -k &quot;..\Key.snk&quot; -in &quot;..\packages\WindowsAPICodePack-Core.1.1.1|..\packages\WindowsAPICodePack-Shell.1.1.1&quot;" />
</Target>

I think your key is password protected so you will also need to pass in -p and your key password for the signer, this is not ideal since it will end up in source control. You can do this manually for now, I'll get the multi-key signing issue fixed up and release 1.4.9. now.

[brutaldev]

You'll need to delete the WindowsAPICodePack directories or restore their .unsigned copies. The tool will not sign already signed assemblies.

[brutaldev]

Fixed in 1.4.9. All assemblies will use the same generated key and not be invalidated.

Make sure you delete any packages that were previously signed and invalidated and let them be restored by NuGet. Alternatively restore the from the .unsigned backup file that is created before the assembly is signed.

Get the latest NuGet package here https://www.nuget.org/packages/Brutal.Dev.StrongNameSigner/1.4.9

[tom-englert]

I could find no difference with 1.4.9, but specifying an own key fixed the problem. Thanx for the support.

[brutaldev]

Prior to deploying, I dropped 1.4.9 into the packages folder in your project (into the 1.4.8 folder so I didn't even change the .csproj), deleted the previously incorrectly signed assemblies and published it, worked perfectly first time. :confused:

The fix is pretty important anyway since delayed friend reference fixing could break normal references if a new key is generated. If you are using a password for your SNK file, then you don't want that password in your .csproj to run the tool with, 1.4.9 takes care of that as well.

[tom-englert]

I did merely the same, I always completely deleted the affected packages before building. The final working version is now in the Main branch, it uses 1.4.9 with -k. If I remove the -k, the click-once does not work. With -k it runs fine. I just double-click the "ResXManager.application" to test it. I'm using Win 8.1, maybe that's important to reproduce?

[brutaldev]

Just to verify, I downloaded your project again and got it building perfectly with the new version.

The first thing I did was opened up ResXManager.csproj to remove the -k argument and noticed the path is still using 1.4.8.

When you upgraded the package, the new path created would be packages\Brutal.Dev.StrongNameSigner.1.4.9, but the old one does not get removed so you will still have packages\Brutal.Dev.StrongNameSigner.1.4.8 available locally.

Without changing the 1.4.8 in the path, I restored packages and tried to build and of course it doesn't find the 1.4.8 package folder and the build fails, this is why I suspect you still have that folder locally if things are still working for you.

Editing the ResXManager.csproj again and changing the path to 1.4.9, rebuilt (keep in mind this would be the first time anything is signed and without the -k option) and everything went smoothly. Verified that the two signed assemblies contained the same public key which means the fix worked, they did. Also ran the ClickOnce app and it also installed correctly with no error.

It appears that nothing changed because you must have still been using 1.4.8 without realizing it. If you perform a fresh build with no packages, only 1.4.9 is pulled down and the build actually fails because the path to the signer is incorrect. Change it to actually point to the 1.4.9 package and you should be good to go.

[tom-englert]

The latest version in Main branch has this change to 1.4.9 - maybe you still have looked at the Feature/Test branch? What OS are you using?

[brutaldev]

Downloaded your project again and used the Main branch. Remove the -k option, restored NuGet packages, built, published and truth be told, it does not work!! I did replace your Key.snk with another one that has no password but that's irrelevant.

I verified that the fix in 1.4.9 was being applied, it is so I'm happy about that, but for some reason I cannot get that branch to work without using the -k option. Everything looks correct, the strong-name is in fact valid for all intents and purposes, the reference from Shell is correct, and the invalid friend references have been removed. This works without a problem when running normally and there is no reason it should fail the ClickOnce installation (but it does).

This is totally different to what was I explained was happening with the Feature branch which boggles my mind :confused:

At least the -k option works for you in the meantime, but this should really work flawlessly without that option. I'm going to take a hard look at this and hopefully I can track down the issue, I'll post my findings here.

By the way, thanks for persisting with this. I was convinced this was resolved (as it should be) but clearly there is something weird going on.

[brutaldev]

Fixed in 1.5.0 and tested on your project. Seems like it's an issue with the StrongNameKeyPair internally, reusing it wasn't a good idea.

[tom-englert]

Sorry to say, but while 1.4.9 worked fine with my own key, 1.5.0 did not even work with this, so I had to rollback to 1.4.9. Maybe what you are testing is only working fine on your machine?

[brutaldev]

@tom-englert The unit tests all pass and this was tested against your own ClickOnce project on my machine during development and another fresh virtual machine after release.

The changes to 1.5.0 wouldn't have affected the functionality in 1.4.9 if using your own key (review the commits it if you wish).

Not sure what else you want me to do? You need to send me a project that fails so I can identify why it doesn't work for you, otherwise I have to assume you are using it incorrectly.

[tom-englert]

Tried again with 1.5.0, and this time it worked. Sorry for the confusion, maybe there was a bad signed file dangling around from previous tests... However I never got it to work without specifying my own key with the -k option, but I'm fine with this.

[brutaldev]

1.5.1 will fix this once and for all. Seems like a ordering issue that I could reproduce after a few tries. Fixing friend assembly references invalidates the signature, so the fix is to re-sign for every write (which was happening when you provide a key file but not when a key is generated). No need for you to upgrade though since you are using your own key.