Comments
Sort by recent activity
It is one of the fun things targeting the .NET Framework, the assembly resolution. In its project files SmartAssembly uses semi-full name resolution so an assembly called "myassembly" does not equal one called "myassembly, Culture=neutral, PublicKeyToken=xxxxxxx".
One big thing that should be noted is that SmartAssembly will always resolve the referenced assemblies from the main assembly itself. It only uses the listing in the project file to determine what settings to apply.
So having two entries in the project file about the "same" (one full, one partially named) assembly will not make any difference to the build process, however SmartAssembly will only apply the protection settings listed in the full named section.
The fact that the other entry is kept does have the nice benefit that if you have dynamic references (or even want to use the same project file for multiple assemblies via the command line... although we don't recommend this) you can add protection entries for all the assemblies you are likely to apply protection to and they will be protected when SmartAssembly finds them needed.
Generally we recommend using the GUI to edit the project file, although there are lots of times when we understand editing the file by hand is the easiest way. I suppose at some point we should give the file grammar, but I think the only gotcha is that the AssemblyName should be the .NET full name without version number. / comments
It is one of the fun things targeting the .NET Framework, the assembly resolution. In its project files SmartAssembly uses semi-full name resolution so an assembly called "myassembly" does not equa...
Sorry that is a known issue, partly related to the strong name signing issue discussed in http://www.red-gate.com/MessageBoard/viewtopic.php?t=11220.
The issue occurred in version 5.0 if you have any of the protection features that use compression ('resource compression and encryption', 'error reporting', or 'string compression and encryption') and tried to sign your assembly with a strong name key with a key size of more than 128 bytes.
It will be fixed in the forthcoming update.
I'll PM you with a temporary patch to fix the issue. / comments
Sorry that is a known issue, partly related to the strong name signing issue discussed in http://www.red-gate.com/MessageBoard/viewtopic.php?t=11220.
The issue occurred in version 5.0 if you have a...
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. / comments
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...
I agree, I am in the middle of filing a bug report. / comments
I agree, I am in the middle of filing a bug report.
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. / comments
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...
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... / comments
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 ...
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. / comments
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 p...
Calling Application.Run twice is not really supported by Winforms.
When the login form closes, the last part of the Application.Run(...) call performs various operations that clear-up the application's context. These contexts include the application's ThreadContext, this means the event handler for unhandled exceptions in the thread is removed, stopping the Unhandled Exception feature for being called.
The better method if you want to have multiple forms displayed is to do Application.Run on the main form, and possibly set it to be hidden in the constructor.
Then within the main form's load method show the other form. / comments
Calling Application.Run twice is not really supported by Winforms.
When the login form closes, the last part of the Application.Run(...) call performs various operations that clear-up the applicati...
The wording has been fixed for the forthcoming update.
We do have a feature, to add self-verification to protected assemblies, listed on the roadmap for SmartAssembly (SA-77). So hopefully it will make it in at some point soon (although no promises). / comments
The wording has been fixed for the forthcoming update.
We do have a feature, to add self-verification to protected assemblies, listed on the roadmap for SmartAssembly (SA-77). So hopefully it will ...
I think the wording that SmartAssembly uses is a little bit strong in this case.
SmartAssembly does not perform a full hash of the assembly to verify that nothing has changed, so it will not detect changing a primitive constant in a hex editor.
If you want this sort of functionality either strong name signing the assembly (and then verifying on load) or using code signing (Authenticode) is the best and simplest way.
However SmartAssembly will protect against modifications by decompilation/recompilation, code injection and most modification to the actual code. / comments
I think the wording that SmartAssembly uses is a little bit strong in this case.
SmartAssembly does not perform a full hash of the assembly to verify that nothing has changed, so it will not detect...