Options
ExcludePublicMembers no longer works?
ApocDev
Posts: 14
In previous versions (pre-6.6.x) we were able to tag assemblies in the .saproj with
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.
<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
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?
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.
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)
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.
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)