When already strong named my assemly, SA says it is not the same strong name

PatrickG

Hi Smart-Assembly Support,
we do sign our assembly with a Strong Name via ILMERGE. Afterwards, opening with Smart Assembly the project (saproj for that assembly, which is configured to obfuscate and also to Strong name the outcome again with the SAME .snk file.
The GUI displays following message in red "The original DLL was signed with a different strong name key. The new DLL will not be binary compatible with the original version." (See screenshot)
For clarification, building the saproj works and the assembly has no issues at Runtime so far. We would just like to get this ugly error message to disappear!

I have tried to sign it with the integrated Visual Studio signing, instead of IlMerge but this results in the same error message.
The strange thing I have noticed was, that on the target Assembly the PUBLICKEY (the hash of PublicKeyToken) was displayed, but on the outcome assembly was the PUBLICKEYTOKEN displayed!
Then I tried something different: I just built the saproj with the mentioned error message. Afterwards, still in the same project I have changed the target assembly to the just created new assembly, then suddenly NO ERRORMESSAGE is shown. Also, the GUI displays the PUBLICKEYTOKEN also on the target assembly now.

Therefore I thought that Smart Assembly writes for sure the AssemblyAttribute somehow different in the assembly. Then, I have opened with ILDissambler the processed (strong named) SA assembly and the assembly strong named by ilmerge and searched for a difference:
Surprising the ".publickey" attribute was written identically and I could also not find any other difference, which could make this error message appear.
I compared this string in the MANIFEST:
".publickey = (00 24 00 00 04 80 00 00 94 00 00 00 06 02 00 00 // .$..............
00 24 00 00 52 53 41 31 00 04 00 00 01 00 01 00 // .$..RSA1........
D9 52 2D AD ED EC 46 95 4A D4 EB FB 12 77 82 C5 // .R-...F.J....w..
4E 9A 54 BB 4A 9A 56 DD CA 62 AD 61 DD 5A 8B 93 // N.T.J.V..b.a.Z..
1B F7 B0 9F E3 E6 7D C2 0F F0 86 81 F3 8E 9E // ......}.........
EE 97 51 B0 BB AA 7E C2 8B 15 C3 40 91 84 C9 23 // ..Q...~....@...#
35 D8 21 62 97 46 25 94 F1 83 D1 6B 33 77 29 3E // 5.!b.F%....k3w)>
F1 38 75 D0 E7 7D 4B 45 A7 79 A8 71 34 3D EC FE // .8u..}KE.y.q4=..
4F 71 AC DF 1B 21 1F F8 A8 A4 7B CA D5 B4 12 7A // Oq...!....{....z
FA AB 2A 8F EA 10 5D 94 BF 97 2D E0 F6 83 17 E7 ) // ..*...]...-....."


This is always the case for us that the target assembly will be already signed before processed by SA.
It would be nice if you could give me a solution to make this error disappear!

Best Regards,
Patrick Gruber

Jessica R

Hi Patrick,

Thanks! I have been able to reproduce this and it is quite odd.

I think SA is directly comparing the two full assembly names (shown under "Selected software") which is why it says the keys don't match up.

I'm still trying to understand how we are getting the public key token with that value though, or what ILMerge does to change the value.

I have found though that if I sign the assembly through Visual Studio when I first build and then again through ILMerge, then the problem doesn't happen.

Would that be a possible option for you?

(Note: I'm not a developer myself, but I wonder actually if it's best to do that to make sure that the assembly is still binary compatible after you process it- either with ILMerge or SmartAssembly. SA usually warns you that the assembly may not be binary compatible if you tell it to sign an assembly that wasn't originally signed.)

Jessica R

Hi @PatrickG,

Thanks for your post and for all the investigation you've done on this so far!

Hm, I'm not immediately sure what could be causing this though as I haven't been able to reproduce it (from a quick test at least).

Just to double check in case this might be specific to ILMerge- when you sign the assembly with Visual Studio, are you still processing it through ILMerge after (and then putting it through SmartAssembly)?

Or in case it's specific to your snk, does it still happen if you create and use a new one?

Can you kindly clarify what you meant by "The strange thing I have noticed was, that on the target Assembly the PUBLICKEY (the hash of PublicKeyToken) was displayed, but on the outcome assembly was the PUBLICKEYTOKEN displayed!"? Where were you seeing these values?

Thank you!

PatrickG

Hi @Jessica R,
thanks for your answer!

My mistake, just with the signing by Visual Studio the message will not appear.

So, it must be the ILMerge:
We have included in the .csproj file a MSBuild task which does the expected work with ILMerge. We use following NuGet package for that:
https://github.com/wade/ILMerge.Tools

The ILMerge.exe version what we are using comes also with a NuGet package:
https://www.nuget.org/packages/ILMerge.Tools/2.14.1208/

Our task is executed in a target with attribute BeforeTargets="CopyFilesToOutputDirectory":
<ILMergeTool InputAssemblies="@(ILMergeInputAssemblies)&quot; OutputFile="obj\$(AssemblyName).dll" KeyFile="$(SolutionDir)Resources\Strong Name\my.snk" SearchDirectories="@(ILMergeSearchDirectories)&quot; LogFile="..\ILMerge.log" Internalize="True" Closed="True" AllowDuplicateTypeNames="True" TargetPlatformVersion="4" TargetPlatformDirectory="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0" ToolPath="$(SolutionDir)packages\ILMerge.Tools.2.14.1208\tools\ILMerge.exe" />

See this screenshot, what I mean that the target assembly shows the Public Key instead of the token:



Thanks,
Patrick

PatrickG

Hi Jessica R,
thanks for your answer and I am glad you could reproduce it!

Sounds great, thanks for the workaround, but this is a temporary solution. It would be of course really nice if this bug is fixed in the next version of SA.

(Note: Thanks for the tip, we will look at this.)

This POST could be closed, but it would be really nice if you could update the post as soon as the new bug fixed version of SA is released.

Thanks,
Patrick

Jessica R

Hi @PatrickG,

Thanks!

I tried to do some more digging myself, but I'm unfortunately still not sure how/why SmartAssembly is reading in the public key token incorrectly after ILMerge alone has signed it.

With that, I have logged this internally as bug SA-2035 - I will post here once we have any updates on this!

(Note: my colleague actually pointed out to me as well that you don't necessarily need to sign with VS first - sometimes it's best to delay sign, particularly when many developers are working on an assembly and you don't want to share the key with all of them.)