Red Gate forums :: View topic - ExcludePublicMembers no longer works?
Return to www.red-gate.com RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
SmartAssembly 6
SmartAssembly 6 forum

ExcludePublicMembers no longer works?

Search in SmartAssembly 6 forum
Post new topic   Reply to topic
Jump to:  
Author Message
ApocDev



Joined: 30 Sep 2010
Posts: 10

PostPosted: Fri Feb 03, 2012 7:09 pm    Post subject: ExcludePublicMembers no longer works? Reply with quote

In previous versions (pre-6.6.x) we were able to tag assemblies in the .saproj with
Code:
<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.
Back to top
View user's profile Send private message
Chris.Allen



Joined: 12 Mar 2009
Posts: 593

PostPosted: Mon Feb 06, 2012 1:56 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
ApocDev



Joined: 30 Sep 2010
Posts: 10

PostPosted: Tue Feb 07, 2012 11:45 pm    Post subject: Reply with quote

Any news on this?
Back to top
View user's profile Send private message
Chris.Allen



Joined: 12 Mar 2009
Posts: 593

PostPosted: Mon Feb 13, 2012 1:54 pm    Post subject: Reply with quote

This has been logged as bug: SA-1389.
Back to top
View user's profile Send private message
Simon C



Joined: 26 Feb 2008
Posts: 140
Location: Red Gate Software

PostPosted: Mon Feb 13, 2012 3:57 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message Send e-mail
ApocDev



Joined: 30 Sep 2010
Posts: 10

PostPosted: Mon Feb 13, 2012 5:09 pm    Post subject: Re: Reply with quote

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)
Back to top
View user's profile Send private message
Simon C



Joined: 26 Feb 2008
Posts: 140
Location: Red Gate Software

PostPosted: Mon Feb 13, 2012 6:06 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Send e-mail
ApocDev



Joined: 30 Sep 2010
Posts: 10

PostPosted: Mon Feb 13, 2012 7:14 pm    Post subject: Re: Reply with quote

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)
Back to top
View user's profile Send private message
ffukes



Joined: 19 Mar 2012
Posts: 2

PostPosted: Mon Mar 19, 2012 4:56 am    Post subject: Reply with quote

Is this because those members are accessed from other assemblies once they are in the merged exe.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic All times are GMT + 1 Hour
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group