Comments
Sort by recent activity
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) / comments
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...
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) / comments
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 attribu...
Any news on this? / comments
Any news on this?
Brian Donahue wrote:
Thanks - I will turn this over to the development team as I really don't understand this very well -- you have an enum, which would normally be a long or int, but instead you are making an enum out of struct, and the struct is packed. Then you ask marshal about the size of the struct and it does not report the correct length. Is that the gist of it?
It would probably be important to let us know which protection options you are using so we can try to isolate which one may be interfering with this.
Not quite. The issue is with structure sizes. (The enum sanity check is due to Marshal.SizeOf not being able to determine the size of an enum, so we grab the underlying type (enum Foo: uint, will cause the underlying type to be uint, [4 bytes]))
The bug is with structs with fixed buffers. (public fixed byte Padding[50];)
This happens with zero protection options turned on. (Not even strong-name signing, or error reporting. No obfuscation, no pruning, no string encryption, etc) / comments
Brian Donahue wrote:
Thanks - I will turn this over to the development team as I really don't understand this very well -- you have an enum, which would normally be a long or int, but instead yo...
When our projects are not obfuscated, there is no issue, as Windows ignores the folder casing all together.
E.g; say you have 2 projects (Project1, and Project2)
Project1 uses zh-hans/Project1.resources.dll
Project2 uses zh-Hans/Project2.resources.dll
This is fine, as windows will create the folder for whichever is encountered first, and just place both DLLs in the same folder. (For the sake of argument, lets say it uses zh-hans)
This gives you;
zh-hans/Project1.resources.dll
zh-hans/Project2.resources.dll
However, when SA merges assemblies, it reads them as 2 "distinct" cultures (which they technically, are not), and will generate resources for zh-hans, then generate resources for zh-Hans, which overwrites "Project1"'s resources.
zh-hans/MergedProject.resources.dll
zh-Hans/MergedProject.resources.dll
Hopefully that shows where the issue is.
I hope that's more clear. / comments
When our projects are not obfuscated, there is no issue, as Windows ignores the folder casing all together.
E.g; say you have 2 projects (Project1, and Project2)
Project1 uses zh-hans/Project1.reso...
Brian Donahue wrote:
It's hard to say why it doesn't work without knowing what the SLP tool does or specifically what error it throws out when you try to use it. In my mind, ASCII obfuscation should be okay -- it should allow the third-party tool to at least get the method names and so forth.
Maybe a combination of obfuscation and "something else" is the issue. For instance, string encoding, pruning, or anything that would pooch the metadata in the assembly may be the actual cause.
Pretty much the point of an obfuscator is to prevent things like IL Disassembly.
That was the first thing I thought of as well. However, I made sure to test with absolutely everything 'off'. Then I turned on obfuscation at the lowest settings possible, and the error popped up.
I've also tried the complete opposite. Everything on, with settings as high as they can go. Not a single problem with that.
It only pops up when I turn obfuscation on.
(Obviously false metadata and ILDASM suppression were off for these tests) / comments
Brian Donahue wrote:
It's hard to say why it doesn't work without knowing what the SLP tool does or specifically what error it throws out when you try to use it. In my mind, ASCII obfuscation sh...