Multiple shared dlls between applications?

SethSeth Posts: 15 Bronze 1

I'm sure this question has been asked before, but I wasn't able to locate it with a search. If this is a duplicate question, a link to the original post would be much appreciated.

My company has multiple applications that we deploy to customers. Some of these applications share many of the same core dlls, some of which are downloaded from one application to the other. We want to obfuscate the applications and the accompanying dlls without having to maintain a lot of separate SmartAssembly projects that will most likely have the same settings across them. We are integrating SmartAssembly into our MSBuild tasks.

We have a few questions about the effects of the obfuscation process that SmartAssembly ends up performing.

1. If we obfuscate one application and its dependent dlls (without merging or embedding) but not the other, will obfuscated dlls be downloaded to the other application and used correctly?
2. If we merge or embed dependent dlls into one of the applications, will they be downloaded to the other application and used correctly?
3. If we create a release branch of our software to perform patches on an obfuscated build (merged/embedded or not), can we deploy the obfuscated dependent dll? Or is patching essentially off the table?


  • SethSeth Posts: 15 Bronze 1
    I've answered the first question on my own:

    We ran a test obfuscation build. We've decided to obfuscate each .dll independently, with each project pointing to a template .saproj, and using the MSBuild obfuscation. After installing the obfuscated build, the client application that downloads the obfuscated dlls worked just fine.

    Now to see if the other two questions can be answered.
  • Hi @Seth,

    Thanks for your post!

    1. As you've found, this should be fine. When you obfuscate dlls, public members are automatically excluded from obfuscation so that other assemblies can still call on them as normal. With that, any application using obfuscated versions of dependent dlls should work correctly.

    2. This won't work, unfortunately. If you merge or embed a dependent dll, there is no longer a physical file for that dll, so any other application that tries to locate and load it will break.

    3. Patching will work for any dlls that have not been embedded or merged. (Technically though, you can patch a dll that has been embedded by placing the patched dll alonside the application that uses it. This would make it load the patched version though and not the one originally embedded one, so it may defeat the purpose of embedding.)

    Jessica Ramos | Product Support Engineer | Redgate Software

    Have you visited our Help Center?

  • SethSeth Posts: 15 Bronze 1
    Because we have decided to obfuscate each assembly independent of the application that uses it, I believe we won't hit issues 2 and 3 anyway, no merging or embedding needed. Thanks for the response!
  • Ah okay, just let us know if any other questions come up! :)

    Jessica Ramos | Product Support Engineer | Redgate Software

    Have you visited our Help Center?

Sign In or Register to comment.