I am creating a class library (MyLib), which contains a public class A. That class specifies a public methods M returning an instance of a class B from an external class library (ExtLib).
In order to use MyLib.A.M(), the user that will use my class library will have to reference both MyLib and ExtLib.
My question is, it that possible to somehow make the ExtLib.B class accessible directly through MyLib (ex: MyLib.B) so the user won't have to reference both libraries, but only MyLib?
You should just accept that your user should reference your assembly and the supporting one.
Yes, you can probably get ilmerge to work, so that the supporting assembly is incorporated in whole into your own assembly. But this completely ties your assembly's release schedule to the supporting assembly's. There would be no way for the supporting assembly to be updated for use with your assembly without re-releasing your own as well.
There is also the question of copyright and licensing. If you wrote the supporting assembly as well, I guess you should have no trouble at all. But otherwise, merging the supporting assembly with your own may at the very least be frowned upon by that assembly's author, if not prohibited outright.
Another unsavory option might be to return dynamic objects from your assembly's APIs instead of the types declared in the supporting assembly. This would of course have possible performance impacts, and would as well negate any possible compile-time type-safety that would otherwise be a normal benefit of using a language like C#. But it could be done.
If you really cannot stand the idea of the user adding a reference to the supporting library, a reasonable option from a software engineering point of view would be change your assembly's API so that it doesn't return types from the supporting library. They will still need that assembly at run-time if you use it, but at least the user's code wouldn't need the explicit reference. Instead, your API would return types your own assembly declares and which wrap the supporting assembly's types, possibly modifying those types' interfaces (removing unneeded members, adding new extensions, etc.) to suit your own users' needs better. That way the supporting assembly's types are hidden from view and so don't require an explicit reference by your users' assemblies.
IMHO it is worth taking note that your user is already referencing lots of other assemblies your assembly depends on, i.e. if nothing else, then the various .NET assemblies at least. Granted, many of these are required for any .NET code to work at all so the users' projects would have these references already, but they still represent additional assembly references. Other non-default .NET assemblies might or might not be required, depending on what else your own assembly uses and returns to the user's code. Regardless, this sort of thing is quite common and not really something one should be investing any significant amount of time trying to avoid.
Again, the fact is that the supporting assembly is going to be required at run-time anyway. So it does not seem like much of a hardship to require that assembly to be referenced by the user's own projects. Referencing assemblies that declare types one's own code depends on is just how .NET works. Why fight it? What compelling problem is it that could possibly motivate putting any real effort at all into avoiding this extra reference by users' projects?
