What are the challenges you face when working across database platforms? Take the survey
Options

ExcludePublicMembers no longer works?

ApocDevApocDev Posts: 14
edited March 18, 2012 11:56PM in SmartAssembly
In previous versions (pre-6.6.x) we were able to tag assemblies in the .saproj with
<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.

Comments

  • Options
    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.
  • Options
    Any news on this?
  • Options
    This has been logged as bug: SA-1389.
  • Options
    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?
  • Options
    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)
  • Options
    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.
  • Options
    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)
  • Options
    Is this because those members are accessed from other assemblies once they are in the merged exe.
    g.gif
Sign In or Register to comment.