CryptographicException while signing assembly
Uniwares_AS
Posts: 168
I do get a "System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed" while building a .{sa}proj file with SA5. The keyfile was a simple VS2008 generated .snk file without password.
Exception report was sent.
Building the same file with SA4.x works without problems, so it seems to be a bug in SA5.
Exception report was sent.
Building the same file with SA4.x works without problems, so it seems to be a bug in SA5.
Comments
Try opening SmartAssembly and in the project settings page for your project, just re-browse for the strong name key file again. Hopefully this should fix it.
If you open the .{sa}proj file in notepad or similar, under the "Options" section there will be a "StrongNameSigning" node.
If you remove the node completely and then re-open the project in SmartAssembly. It should now not be strong name signing, if you then specify a key, hopefully...
Obviously there is something wrong with the password handling in SA5.
Usually it can just be resolved by just re-selecting the Strong Name Key file.
The interesting thing in this case was that you were using a strong name key file without a password. Looking at the code I think what must have happened is that at some point you had used a password protected strong name key file on this project, and because the code only updates the encrypted password when the user specifies a new password (which you didn't need to do because the new key didn't need one) it was left there.
In which case yes removing the Password= attribute from the "StrongNameSigning" node will solve the issue.
Bad though that SA doesn't ignore/reset the password when you change the key file through the GUI, even worse, when you create a new one.
When using an SA 4.x project file unaltered with SA 5.0, I am seeing the same error. Removing and adding the same keyfile with the same password solves the situation.
From what I have seen comparing old and new project file, only the password value if different, while having the same password on the keyfile.
If thats the case then you should issue a big no-no when upgrading, otherwise the user will fall into that trap.
Yes I know that it is a silly thing to have to do when upgrading projects, it is going to be formally documented in the update on Thursday.