Hi,
We’re facing some issues when upgrading our Aspose components from 21.2 to 21.11 (.NET). More specific it’s the Aspose.Words that causes problems. I read a similar post regarding PDF here:
https://forum.aspose.com/t/aspose-pdf-for-net-why-public-key-token-changed/237049
After upgrade, it seems that the public key token is the same for Cells, Slides and Pdf, while it has changed for Words. When I use nuget to see the history (Visual studio 2019 → “Manage NuGet Packages for Solution”), it seems that the token was unchanged up to and including 21.5, then from 21.6 it has changed. The error I’m getting is (also screenshot below)
“Could not load file or assembly ‘Aspose.Words, Version=21.11.0.0, Culture=neutral, PublicKeyToken=716fcc553a201e56’ or one of its dependencies.”
The public key token for Words is in my current solution c6f00a3913c6cd45.
Thanks,
Karl
image.png (47.9 KB)
@ka.broden I have checked public key token of old versions of Aspose.Words and as I can see it is unchanged since the first version of Aspose.Words available on NuGet and is 716fcc553a201e56.
I used sn.exe tool to get public key token:
sn.exe -T Aspose.Words.dll
Could you please attach the old version of Aspose.Words.dll used on your side?
Thanks for replying. I have done the same check on my side (using Developer Command Prompt for VS 2019).
For the 21.2 version I get public key token = 716fcc553a201e56
For the 21.11 version I get public key token = c6f00a3913c6cd45
I’m not able to upload the old 21.2 dll (7z) at the moment, just getting an error message. Will try again later today. Attached is a screenshot of my command prompt in case that could help (e.g. if I’m doing something wrong…)
Karl
image.png (10.7 KB)
@ka.broden It is really strange, I just redownloaded Aspose.Words 21.11 from NuGet and rechecked again and the result is the same public key token is 716fcc553a201e56. image.png (6.9 KB)
Yes that’s a bit strange… seems like it could be something on my side then if you’re able to get the same token as earlier.
If still interesting, I’ve uploaded the 21.2 dll now.Aspose.Words.dll.7z (4.3 MB)
@ka.broden Checked it too and public key token is the same on my side. Also checked this on two different PCs with the same result.
Ok I might have misunderstood when you asked for the old dll (or maybe if I expressed myself unclear in the first place) but the dll I uploaded is the 21.2 version that we have been using up until now. That has token “716fcc553a201e56” and has been working fine. I attach the 21.11 dll on my side that has the other token, “c6f00a3913c6cd45”.
But I still think it’s something at my side, and I actually discovered that my dll changes both filesize and token when I install the nuget to a second project in the solution. So, I’ll investigate further.
Aspose.Words.dll.7z (4.5 MB)
@ka.broden I also noticed that file size and public key token is different in the dll you have attached. This can occur if you disassemble the dll and sign it with different key. But I do not thin you do this.
Please let us know if you find the reason why the dll was changed on your side.
Getting closer to the root cause now I think. We’re using a nuget for signing assemblies, Brutal.Dev.StrongNameSigner (version 2.3.1), which previously only has been affecting our own project assembly. Now for some reason, it edits the Aspose Words assembly too. From the comments in that nuget code it seems there’s an issue with “unsigned friend assemblies”, which are then removed from the assembly and the assembly is re-signed. And this is the reason I get a different file size and a new public key token for my Aspose.Words.dll.
The method in the StrongNameSigner code is “RemoveInvalidFriendAssemblyReferences”, and the comment is:
// Remove all InternalsVisibleTo attributes without public keys from the processed assemblies. Signed assemblies cannot have unsigned friend assemblies.
Link to the code is here: https://github.com/brutaldev/strongnamesigner
Is it possible for you to investigate if there are any unsigned friend assemblies inside your Aspose Words assembly (21.11)? If so, is it supposed to be like that or should something be modified on your side?
I’m trying to figure out how and where to solve my issue, i.e. keeping the assembly untouched. If nothing’s wrong at your side then we might need to modify how we sign our own assembly in the project.
Karl
@ka.broden Thank you for additional information. We will investigate the issue on our side too and let you know our findings.
1 Like
For info we temporarily removed the signing to move forward, but it would still be nice to hear if you get to some conclusions on your side.
@ka.broden I have logged this issue as WORDSNET-23218. Our developers will investigate the issue . Once there are news regarding this issue I will let you know.
1 Like
@ka.broden We have tried to resign Aspose.Words.dll with StrongNameSigner 2.3.0 and 2.9.1 as a standalone assembly and as a referenced assembly too.
But StrongNameSigner detected it as an already signed assembly and did change it.
Also we have looked at the StrongNameSigner code and found out it ignores signed assemblies and didn’t pass it to RemoveInvalidFriendAssemblyReferences method.
Aspose.Words.dll assembly can be resigned by StrongNameSigner if you remove its signature before the process. So we close the issue and Won't Fix because there is nothing to fix in Aspose.Words code.