C# .net - Dll Naming Conventions in Interface / Implementation Scenarios

I need some suggestions for clever naming of dll and/or a hint if any naming conventions for the following scenario exist.

I have an interface definition and several types used by that interface definition encapsulated in one dll. Then I have an implementation of this interface in another dll. The “special” thing about this situation is that I do not develop an application but more a collection of functionalities (aka framework) that is used by multiple applications of my company. These functionalities are accessed through its interface definition via MEF, so the user of this framework does usually not know开发者_开发问答, nor is it important to him, in which dll the implementation is (since he only needs to know and reference the dll containing the interface definition). Just in really uncommon cases he might want to know how the dll (the one containing the implementation) is named, because he wants to replace the implementation with his own.

I created some requirements for my dll naming:

• The dll with the interface definition needs to be well named because this is the dll the user is referencing.
• The namespace of the interface definition dll needs to be very well named (and be very intuitive) so the user really expects this definition in this namespace, where it would be the optimum that the namespace equals the solution structure.
• The implementation dll must be named very clear, so the user can identify the dll in the working directory to remove it and install an own implementation.
• The namespace of the implementation does not really matter since its only used internally.
• The dll names should not be too long.

First, I came up with the idea to group all interface definitions of a specific type in one dll, that would create a very well named namespace since I can group for example all “services” in a dll called MyCompany.Services.dll, put all definition and types in that root (which creates the namespace MyCompany.Services), and therefore have kept the solution structure equal to the namespaces (which might be alo discussed here if this is useful or not).

But that generates a big problem:

If I signature the dlls and change something in my MyCompany.Services.dll, I have to recompile all implementation dlls even if this change only affects one of this n dlls. At that point I thought about putting each interface definition and ity types in an own dll (as described in the beginning of this post).

---

My 2 cents worth:

• Use a common top-level namespace so everything that's part of your framework can be easily identified. You might not "need" it but it just seems silly not to.
• Use descriptive names. Things like Basti.SpecialFramework.Interfaces.DataAccess.Customer would make a lot of sense to me.
• Structuring the namespace around the structure / architecture of your system makes lots of sense.
• Having a well structured namespace tree will help the interpretation of key works / terms in the same place, e.g: Basti.SpecialFramework.Interfaces.DataAccess.Customer vs Basti.SpecialFramework.BaseImplementations.DataAccess.Customer
• Treat it a bit like developing Information Architecture or doing usability testing: come up with a draft set of names and see if your friends can figure it out. Do the eqivalent of a Card Sorting exercise - do you structure it: [Layer].[Interface / BaseImplementation] or [Interface / BaseImplementation].[Layer]? (I'm not sure exactly how you would do the card sorting exercise but I can see some strong parallels).
• Descriptive names tend to be long, this goes aganist your last point; I agree long names might not be "easy" and "convenient" but if they clearly convey what I need to know I would be okay with that.

By the way: I'm sure naming conventions exist for DLLs and Assembilies - I just don't know them off the top of my head. I guess I could Google / Bing them but I guess you've done that already.