ExcludePublicMembers no longer works?

.NET obfuscator and automated error reporting

ExcludePublicMembers no longer works?

Postby ApocDev » Fri Feb 03, 2012 7:09 pm

In previous versions (pre-6.6.x) we were able to tag assemblies in the .saproj with
Code: Select all
<Obfuscation Obfuscate="1" ExcludePublicMembers="1">


We merge roughly 8-10 DLLs into our main exe, and the above helps tremendously when maintaining the libraries. (We don't need to mark every public type with DoNotObfuscateType, instead its done via the project file)

With 6.6, this seems to be completely ignored and is breaking our older projects, as well as hindering newer ones. Is this a known bug? Has the XML attribute moved? Or do we have to go through and manually tag all of our public classes with DoNotObfuscate?

Edit:

We don't have pruning enabled (as that would strip quite a bit of our API). We are using the exact same settings in 6.6 that we did in 6.5.

It seems like its renaming the classes, but not fields within the classes.
ApocDev
 
Posts: 10
Joined: Thu Sep 30, 2010 10:43 pm

Postby Chris.Allen » Mon Feb 06, 2012 1:56 pm

I'm just double-checking with our dev team if anything has changed regarding the XML schema. (We haven't been notified of any changes so, its more likely that what you are seeing is a regression). Please bear with me while I clarify the situation.
Chris.Allen
 
Posts: 594
Joined: Thu Mar 12, 2009 4:17 pm

Postby ApocDev » Tue Feb 07, 2012 11:45 pm

Any news on this?
ApocDev
 
Posts: 10
Joined: Thu Sep 30, 2010 10:43 pm

Postby Chris.Allen » Mon Feb 13, 2012 1:54 pm

This has been logged as bug: SA-1389.
Chris.Allen
 
Posts: 594
Joined: Thu Mar 12, 2009 4:17 pm

Postby Simon C » Mon Feb 13, 2012 3:57 pm

Hi ApocDev; I'm currently looking at this issue now.

Just to be clear, you're specifying ExcludePublicMembers on dlls that are being merged in, and you want public members of those merged dlls to still be accessible in the resulting exe? Is this because those members are accessed from other assemblies once they are in the merged exe, or as a shortcut to exclude them from obfuscation?

What was the previous SA version you were using?
Simon C
 
Posts: 140
Joined: Tue Feb 26, 2008 4:56 pm
Location: Red Gate Software

Re:

Postby ApocDev » Mon Feb 13, 2012 5:09 pm

Simon C wrote:Just to be clear, you're specifying ExcludePublicMembers on dlls that are being merged in, and you want public members of those merged dlls to still be accessible in the resulting exe?


Correct. We do some runtime compiling of C# files (more or less a plugin system) so we expose quite a bit of our API via the .exe, instead of a stack of dlls. This also ties into the IronPython usage we have for other things.

We tried marking the main exe with ExcludePublicMembers as well, but that had no effect on anything.

Simon C wrote: Is this because those members are accessed from other assemblies once they are in the merged exe, or as a shortcut to exclude them from obfuscation?

What was the previous SA version you were using?


Yes to both. As I explained above, its to provide support for our runtime compiling, and IronPython usage.

We also use it as a shortcut to exclude any public classes/members from obfuscation. When you start providing a few hundred public classes, that grows daily (mostly wrappers around other things to hide away implementation details), it becomes incredibly difficult to maintain the attributes for manual exclusion. (This also applies to any class members, or methods)

Our previous project has been reverted back to v5.5 of SA to ensure we're not breaking anything for end-users. (At the risk of less protection) As far as I'm aware, 6.2 was working as intended as well, and 6.5 was hit and miss. (We assumed it had something to do with clashing names, so we shrugged it off as a minor issue, and just tagged those classes manually)

With 6.6, its almost entirely ignored on every level.

I'm positive that 5.5 is working, and 90% sure 6.2 was working. (Again, 6.5 was hit and miss)
ApocDev
 
Posts: 10
Joined: Thu Sep 30, 2010 10:43 pm

Postby Simon C » Mon Feb 13, 2012 6:06 pm

It looks like this was a behaviour change introduced in 6.5, with the rearchitecture. ExcludePublicMembers works as documented when specified on the main assembly, but is not properly taken account of when applied to merged assemblies.

This was introduced in 6.5 because we did not take account of SmartAssembly being used to merge assemblies to produce an API on an exe file. Using ExcludePublicMembers on merged assemblies in such a way is somewhat undocumented, which is why we missed it.

We will be fixing this in the next minor release; it is a change that requires some amount of testing to ensure we haven't got any further regressions.

Just to check, have you looked at excluding entire namespaces from obfuscation & pruning in the SmartAssembly UI? That might produce the API you wish without having to use attributes and ExcludePublicMembers.
Simon C
 
Posts: 140
Joined: Tue Feb 26, 2008 4:56 pm
Location: Red Gate Software

Re:

Postby ApocDev » Mon Feb 13, 2012 7:14 pm

Simon C wrote:Just to check, have you looked at excluding entire namespaces from obfuscation & pruning in the SmartAssembly UI? That might produce the API you wish without having to use attributes and ExcludePublicMembers.


We do this for a few namespaces where it's safe to do so. However, we use reflection extensively (both for our XML engine, and type loaders for the plugin system) so pruning isn't quite the best approach for us since we don't personally use all the classes defined in a namespace, but 3rd parties most likely will.

Additionally; we do have private members in some classes that we *do* want obfuscated for obvious reasons. (f.ex. providing the functionality it used to, where it would still obfuscate anything internal/private (internal when viable that is), but leaving public API alone)
ApocDev
 
Posts: 10
Joined: Thu Sep 30, 2010 10:43 pm

Postby ffukes » Mon Mar 19, 2012 4:56 am

Is this because those members are accessed from other assemblies once they are in the merged exe.
Image
ffukes
 
Posts: 2
Joined: Mon Mar 19, 2012 4:49 am


Return to SmartAssembly 6

Who is online

Users browsing this forum: No registered users and 0 guests