Merging DLL's and changing managing namespaces

Question

I want to create a single dll that is merged with a 3rd party dll. This means end consumers will only have to deal with 1 dll instead of 2.

For augments sake lets say that the 3rd party dll is nLog. How do I deal with cases where the consumer of the merged dll already has NLog as a reference in their project?

Ideally what I would like to be able to do is change NLog namespace within my project to "XyzNLog", meaning that the user wouldn't need to do any aliasing... Any idea how I might do this?

Now I know I can add aliases to my project for NLog so that I have to refer to it as XyzNLog, but I want the same to carry over to consumers of the merged dll so that there is never a conflict.

UPDATE - Solution

http://blog.mattbrailsford.com/2010/12/10/avoiding-dependency-conflicts-using-ilmerge/

Bingo! So by using ILMerge, it becomes possible to merge the third-party libraries DLLs in with the Providers own DLL, meaning we will only have one DLL to deploy. But that’s not all, we can actually go one step further, and tell ILMerge to internalize all dependencies. What this does it converts all the third party classes to be declared as internal, meaning they can only be used from within the final DLL. Woo hoo! problem solved =)

Given this the problem where the consumer of my dll could also have NLog goes away... as my referenced NLog shifts to being all internal! This is exactly what I want.

Does anyone have any feedback or thoughts on this?

Answer 1

I have to agree with @Hans Passant (and here's some info about the oft-discussed DLL hell), but since you've asked the question, I'll try to answer it.

You can bundle the third-party DLL as a resource. Please see this question for details.

As far as your other questions, I'd just expose the relevant classes from a third-party DLL under your own namespace, and maybe use extension methods to provide whatever additional functionality you want.

For instance, you can provide access to NLog's Log() method using a static method in your class, say XyzNLog.Logger.Log(), taking care of initialization, and whatever else internally, inside your code (static constructor or whatever else you fancy up). Since you load the NLog assembly using the method above, you'll be the only one having access to the embedded NLog assembly directly and the user won't be able to access it. Now, you don't get the benefit of having all classes autoexposed from NLog, you still have to expose them manually in this case.

EDIT: Another approach would be to try to use ILMerge with /internalize flag as described here. You may not be able to completely resolve the issue, but look at this article to see if you can avoid the pitfalls the author described. Spoiler alert: it's not all peaches'n'cream on this one either, but it may work, with enough extra effort.

Answer 2

I agree with Hans, I would strongly suggest releasing with registering the DLLs separately.

Otherwise, you could be in DLL hell which would drive your consumers away.

You could then devise some clever deploy methods to detect if the DLL is already registered, etc.