Better obfuscating in Visual Studio for solutions with many projects?

I have a solution with many projects, which leads to many dll files.

My q开发者_开发知识库uestion is, is this an obstacle when obfuscating and should I optimize this in some way?

Or it is just a matter of public/private fields/methods?

The way you accomplish this with Dotfuscator is to add all of your assemblies as inputs to the Dotfuscator project. Once you have done this you will need to turn off Library mode either for the project as a whole (from the Input Files tab, the icon that looks like a set of books) or on each assembly individually. Library mode is the default mode for DLL files and does not rename any publicly visible elements.

With Library mode turned off all methods will be renamed, and the methods in the calling assemblies will be updated as well. If you are performing any dynamic invocation via Reflection or late binding you will need to manually exclude those target methods from renaming.

Edit: Another thing you can look at that may make your distribution easier is Dotfuscator's Linking feature. This allows you to link assemblies together (similar to what ILMerge does) so that you can ship a single EXE with all of your DLL's linked into it or any other combination so that you have fewer physical files to give to your end users.

No, you definitely should not be compromising your project layout structure just for an obfuscator.

In general, obfuscators have a mode where you can say "here is my entire system, assume nobody else is doing anything" which effectively says, treat this as if it was one block of code.

Techniques like using internal together with InternalsVisibleToAttribute can be used (many obfuscators will be more agressive by default with internal stuff than public stuff.

Anything that needs to remain as-is for e.g., System.Reflection-based or dynamic-based access can be marked with ObfuscationAttribute to tell the obfuscator "Don't touch that".

There are other tradeoffs to be considered in whether one puts in facade layers that act as bridges between components and then create internal classes behind that - depending on the context that may either make it easier to reverse engineer (you're handing otu a quick summary) or harder (you had a core class and were giving away loads of clues by having some key methods on it not e.g. renamed).