Smartassembly playing together with Dependency Injection

kimpenhaus

Hi there,

we have several services which need to be obfuscated (name-wrangling as well as control-flow obfuscation as well as other features like embedding, pruning etc but not as necessary as first two points).

The problem we are facing is that we have some assemblies loosely coupled and no direct reference between the assemblies. While we are not able to set references inside smartassembly by hand - what can we do to set those references so that we could embed our assemblies? Or are there different ways to obfuscate more than 1 main assembly inside of smartassembly?

I am aware of the fact, that it sounds a bit controversial having dependencies which are loosely coupled embedded into assemblies. This is mainly because we face different provider for different customer and different production environments.

Thanks in advance,
kind regards,

Marcus

ShortAngry

From what I understand, SA will automatically pick up on directly referenced assemblies but it sounds like in this instance you may have to create separate projects for each of the loosely coupled assemblies.

I would start with all the SA options turned off and slowly turn features on one by one until you either get the protection you want or hit a specific problem. If you do hit a specific problem you can usually work around it by using custom attributes as detailed here: http://www.red-gate.com/supportcenter/C ... .0/toc.htm

If you find you're unable to do this, you might want to contact support @ red-gate.com directly.

nkilian

I'm encountering a similar problem.

We access some assemblies in our application only through reflection, and even though we have a project reference to the assembly in Visual Studio (and TFS builds this reference for us and deploys it to the drop folder), SA doesn't identify it as a dependency.

As a workaround, somewhere in the executing assembly we force a dependency by declaring a variable as a type in the target assembly.

But it would be great if SA would allow us to include these unused references as dependencies so we can embed and optionally obfuscate and prune them.

kimpenhaus

We went away from using Ninject.Xml Extension and are using now small binding modules. This is of course more secure (and fits {sa} needs while depenedencies are now linked in) but at cost of flexibility.
This is in case of that our production system, q&a system and development system use different adapter for binding against an archive system - so we need do deploy different builds to different systems, which is meant to make mistakes...as murphy will say.