Separate DLLs won't play nice after obfuscation - how can obfuscation map be shared between DLLs?

MikeJ

Hi all,

This scenario may be addressed in documentation or another forum post but I haven't been able to track it down, so apologies if this is an old question.

Our application consists of half a dozen DLLs. After a successful build and obfuscation process, the application runs initially but exploratory testing brings up an error. For the purposes of this discussion I'll focus on two DLLs related to the error.

Let's call them:

LibraryA.dll

LibraryB.dll

LibraryA depends on LibraryB.
LibraryB has 'InternalsVisibleTo( "LibraryA", PublicKey=00030030003033... ) within its AssemblyInfo.cs 

The error goes something like this:

Could not load type 'LibraryB.Data.ModeEnum' from assembly 'LibraryB, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bdb4a1234fe7688c'.

To fix, I have tried both merging and embedding LibraryB within LibraryA, neither work. Note, there is no exe here, this is a web application.

Within LibraryB, the enum that is the source of the error is declared as follows:

internal enum ProjectCalendarListUsageMode

I presume I could add a [Obfuscation(Exclude = true, Feature = "renaming" ...] attribute before the enum declaration but here's the thing:

I am evaluating SmartAssembly as a potential replacement to Dotfuscator. Within Dotfuscator all the applcation's DLLs appear to be obfuscated as a group. My approach with SmartAssembly has been to create an individual SA project per DLL. I am thinking the reason I am seeing an error is because there is no way for the call in LibraryA to know the obfuscated name for the enum in LibraryB as the libraries get obfuscated separately.

As said I could look to exclude this enum from obfuscation but I would prefer not to have to examine all our code for such scenarios. Furthermore, Dotfuscator is capable of dealing with this without the need to introduce the exclusion. Is there a way in SmartAssembly to group all these DLLs together into the obfuscation process such that the renaming will be consistent across the DLLs? Or, is there any other approach that will address this issue without me having to go through all our code to identify cross library calls and expose the relevant classes etc via exclusions?

Would appreciate any help or suggestions,

-MikeJ

Jessica R

Hi @MikeJ,

Thanks for your post!

I'm afraid that SmartAssembly does not currently support cross-assembly obfuscation, so it's not possible to  consistently rename across the DLLs at the moment.

With that, you do need to make sure to exclude any internal members that are called on by friend assemblies from obfuscation and pruning. 

We have a request (SA-322) for SmartAssembly to resolve friend assemblies during obfuscation and patch them to use the same obfuscated names of objects. I've gone ahead and +1'd this request for you. So sorry that it doesn't already handle the friend assemblies better at the moment!

The best workaround for now would be to use the Find function in VS to search through your source code for InternalsVisibleTo attributes for the friend assemblies involved in this particular application and exclude them using SmartAssembly's [DoNotObfuscate] attribute--and I apologize as I know that's not ideal!