Comments
Sort by recent activity
Unfortunately, we don't currently produce a human readable map file (it is in our requests tracker as SA-91).
If you do need to do post processing on the assembly where you need to know the obfuscated name you can use the "[ObfuscateTo( string )]" attribute, although I'll admit it is not the most friendly method. / comments
Unfortunately, we don't currently produce a human readable map file (it is in our requests tracker as SA-91).
If you do need to do post processing on the assembly where you need to know the obfusca...
Yes it is
[ObfuscateTo("human")]
void anymethod()
{}
The string is a standard .NET System.String so it is enclosed in "", and you can do anything you can do with a string constant (e.g. "\u0001Hello" )
The other attribute which you would probably want to use alongside [ObfuscateTo(..)] is [ObfsucateNamespaceTo( string )] this, unsurprisingly, specifies the name to obfuscate the namespace of the type to. / comments
Yes it is
[ObfuscateTo("human")]
void anymethod()
{}
The string is a standard .NET System.String so it is enclosed in "", and you can do anything you can do with...
You can obfuscate any pure .NET assembly, you just need to create a new SmartAssembly project for the plugin assembly and build it with the protection you want to apply.
If your plugin is a library (.dll) then SmartAssembly will leave all public interfaces, types and methods visible.
If your plugin is an executable (.exe) then SmartAssembly will obfuscate (effectively hiding) everything by default.
The section "Excluding public members from obfuscation" on our support page http://www.red-gate.com/supportcenter/Content.aspx?c=SmartAssembly\help\5.0\SA_ObfuscatingCode.htm&p=SmartAssembly#o11193 describes how to change the default behaviour.
As long as your main exe references the plugin you can embed or merge the plugin.
If you don't have a reference to the plugin in the executable and can't add one (for instance if you want dynamically choose which plugins to load at runtime) then it is not currently possible to embed or merge the the plugin using SmartAssembly.
If you can't embed the plugin you can manually do it, see http://www.codeproject.com/KB/DLL/EmbedAssemblyAsResource.aspx, although this is more of a pain to do and doesn't do any encryption or compression on the embedded plugin assembly. / comments
You can obfuscate any pure .NET assembly, you just need to create a new SmartAssembly project for the plugin assembly and build it with the protection you want to apply.
If your plugin is a library...
You can obfuscate any pure .NET assembly, you just need to create a new SmartAssembly project for the plugin assembly and build it with the protection you want to apply.
If your plugin is a library (.dll) then SmartAssembly will leave all public interfaces, types and methods visible.
If your plugin is an executable (.exe) then SmartAssembly will obfuscate (effectively hiding) everything by default.
You can override the default behavior by using the <ExcludePublicMembers> attribute in the SmartAssembly project file (*.saproj). This enables you to treat EXE files in a similar way to DLL files.
To exclude public members from obfuscation, specify a value of '1' for the project file:
<Obfuscation ExcludePublicMembers="1" Obfuscate="1">...
</Obfuscation>
As long as your main exe references the plugin you can embed or merge the plugin.
If you don't have a reference to the plugin in the executable and can't add one (for instance if you want dynamically choose which plugins to load at runtime) then it is not currently possible to embed or merge the the plugin using SmartAssembly.
If you can't embed the plugin you can manually do it, see http://www.codeproject.com/KB/DLL/EmbedAssemblyAsResource.aspx, although this is more of a pain to do and doesn't do any encryption or compression on the embedded plugin assembly. / comments
You can obfuscate any pure .NET assembly, you just need to create a new SmartAssembly project for the plugin assembly and build it with the protection you want to apply.
If your plugin is a library...
Yes, in the SmartAssembly settings specify to create a PDB file and make sure the Obfuscate document URLs check box is unticked.
If you then build it and run, then just use Attach to Process in your debugger. / comments
Yes, in the SmartAssembly settings specify to create a PDB file and make sure the Obfuscate document URLs check box is unticked.
If you then build it and run, then just use Attach to Process in you...
[DoNotObfuscate] will only stop the name of the type (or what ever the attribute is applied to) from being obfuscated.
In this case you'll want to use [DoNotObfuscateType] as the method signature of the interface need to be left unobfuscated as well as the type name.
"The Method X in type A.Y from assembly A does not have an implementation" error can mean various things. The usual cases are either it can't find the method signature in the interface (for instance because it is obfuscated or because it is referencing an incorrect version of the assembly), or if the interface is in an assembly which is not referenced. / comments
[DoNotObfuscate] will only stop the name of the type (or what ever the attribute is applied to) from being obfuscated.
In this case you'll want to use [DoNotObfuscateType] as the method signature o...
Yes the second option (obfuscate both class and method names) in the GUI has exactly the same effect as adding the [DoNotObfuscateType()].
You only need to add the DoNotObfuscateType attribute to the interface, in fact the compiler will give an error if you add it to a method...
As long as the interface type and methods are visible, the references are there, the assembly full name (i.e. name + cutlure + public key token) and the files are all local there shouldn't be any problems.
If all of the above is true, the only other thing I can think is to try compiling the plugin against the obfuscated main assembly. It isn't the recommended way but the compiler might give a more helpful error message.
Ben1628 wrote:
Method 'soso" in type 'abc' from assembly 'abc .... publickeytoken=... ' does not have an implemention.
abc is the plugin (not obfuscatged yet), I don't know why it is referred to as type,...
I'm as confused as you why abc is referred to as a type. / comments
Yes the second option (obfuscate both class and method names) in the GUI has exactly the same effect as adding the [DoNotObfuscateType()].
You only need to add the DoNotObfuscateType attribute to t...
Does it tell you what type it is failing to load?
If not:
If you turn on the Self Diagnosis feature (on the Build Succeeded page of the SmartAssembly UI) or, if you are testing on a different machine to the one with SmartAssembly on, turn on the Automated Error Reporting.
When the error occurs you will then get an error report which will tell you the unobfuscated name of the type which is causing issues.
Is the type defined in the main assembly and then used by the plugin?
How is the type being created/used in the plugin?
The mostly likely cause is that the type is mistakenly being obfuscated or pruned (this can occur if the type is defined in an exe or is only being called by reflection).
If you open up the SmartAssembly project for the assembly that contains the type.
If you are applying pruning to your assembly, then under the Pruning section next to the name of the assembly there will be an "Exclusions..." link. If you click on this link and then navigate through the namespace to find the type
If the type is described as being a "Fully useful class" or is only listing a few members or attributes to prune then that is good and SmartAssembly has correctly identified it as being used. If it is described as a "Prunable Class" click the "Exclude from Pruning" button in the middle of the page. This will tell SmartAssembly not to prune the type.
If you are applying obfuscation to your assembly, then under the Obfuscation section next to the name of the assembly there will be an "Exclusions..." link. If you follow the same procedure as I described for the pruning to make sure that it is not obfuscating the name of the typel. / comments
Does it tell you what type it is failing to load?
If not:
If you turn on the Self Diagnosis feature (on the Build Succeeded page of the SmartAssembly UI) or, if you are testing on a different mach...
That is a interesting bug, glad you managed to get to the bottom of it.
I presume you are setting output to self.
SmartAssembly will delete the output file if it exists and then write out the new file. The signing is part of the write out step (rather than being a post build step) and as you've found if it can't open the strong name key because of a password decryption failure it will stop, leaving no file.
The failure should return a error code, I'll have a look into it and raise a bug if this is not the case. / comments
That is a interesting bug, glad you managed to get to the bottom of it.
I presume you are setting output to self.
SmartAssembly will delete the output file if it exists and then write out the new f...
That is the annoying thing with MSBuild (and devenv.exe which is a wrapper around it), it redirects the console output to the logger and the default settings for the default logger are for a very quiet output.
Glad you managed to find the problem.
I'll log a feature request for the <Include ...> structure / comments
That is the annoying thing with MSBuild (and devenv.exe which is a wrapper around it), it redirects the console output to the logger and the default settings for the default logger are for a very q...