Comments
Sort by recent activity
The option to use "Automatic reporting (without UI)" is mostly designed for use where a dialog box might not be appropriate, for instance a command line tool or a Windows service. / comments
The option to use "Automatic reporting (without UI)" is mostly designed for use where a dialog box might not be appropriate, for instance a command line tool or a Windows service.
I've sent you a PM.
No the field name managling shouldn't make any different in this case. / comments
I've sent you a PM.
No the field name managling shouldn't make any different in this case.
Oh that is an interesting bug. If you are using [ObfuscateTo( string )] on a method then you have to use "Unicode encoding with advanced renaming" for it to work. I've logged the bug as (SA-325) as it should be available on all settings.
[ObfuscateNamespaceTo( string )] needs to be applied to a class, struct, enum or interface, otherwise you will get a compiler error. / comments
Oh that is an interesting bug. If you are using [ObfuscateTo( string )] on a method then you have to use "Unicode encoding with advanced renaming" for it to work. I've logged the bug as (SA-325) as...
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...