How is dnSpy able to preserve the publickeytoken in an assembly when patching a module? #74
-
Hi there, I have a closed source program that I use and unfortunately the author won't incorporate changes that I suggest. So I maintain a git repo where I commit the author changes by committing to a master branch using the dnSpy exported VS project files. I then use a modification branch with my patches, rebasing as I go. The problem now is: The program loads the assembly that I change (.dll) with a strong name. When I do the patches using dnSpy it works. When I compile the dll with VS2019 the publickeytoken is lost and the .dll is rejected when opening the program. (manifest definition of the assembly does not match the assembly reference) So that means dnSpy is using some magic to preserve the strong name. First I thought it is merely copying the .publickeytoken IL property. But when I do this (ILDASM /all /out my VS2019 .dll;;; copy the .publickeytoken of the assembly;;; ILASM the file back together) it still gets rejected because of the strong name. So I tried skimming through the dnSpy code but I cannot seem to find where or how this magic happens. Can someone who is more fluent in this give a small pointer? Many thanks in advance. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Hrm it seems like dnSpy uses dnlib which in turn has no problems copying the AssemblyDef.PublicKey property and writing it correctly. I have written a small powershell script to do this as post-build step in VS. Still wondering why the ILASM approach didn't work. |
Beta Was this translation helpful? Give feedback.
Hrm it seems like dnSpy uses dnlib which in turn has no problems copying the AssemblyDef.PublicKey property and writing it correctly.
I have written a small powershell script to do this as post-build step in VS. Still wondering why the ILASM approach didn't work.