CryptographicException while signing assembly

[Uniwares_AS]

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.

[Paul.Martin]

Looking at the report it seems that SmartAssembly thinks that the strong name key does have a password for some unknown reason.

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.

[Uniwares_AS]

Did that. Getting the same error but this time right when selecting the key file. Error report sent.

[Uniwares_AS]

Ok, now I created a new key, directly in SA and got the same result at build time. Error report sent.

[Uniwares_AS]

Last try: created a password protected key file in VS2010, same problem when selecting the keyfile in SA. It doesnt even ask for the password.

[Paul.Martin]

OK, can you try it the manual way.
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...

[Uniwares_AS]

I just removed the Password= attribute from the sa project using the same keyfile without password. Works now.

Obviously there is something wrong with the password handling in SA5.

[Paul.Martin]

There is one known issue with the stored encrypted passwords when you upgrade a project file from SmartAssembly 4 to 5.
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.

[Uniwares_AS]

Yes, you are right, at one point there was another keyfile with password used in the project, which changed using SA 4.x still. Funny though that SA4 does not complain about the password it left in the project file and doesnt try to use it.

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.

[Paul.Martin]

I agree, I am in the middle of filing a bug report.

[Uniwares_AS]

I am back to this one but because of another reason. It seems to me that you have changed salt or encoding scheme of the passwords as they are stored in the project files.
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.

[Paul.Martin]

Yes, that is why I suggested that workaround of reselecting the strong name key file as this refreshes the password.

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.