Databases
StackOverflow2013
Postsdbo
POC# .net - Dll Naming Conventions in Interface / Implementation Scenarios
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POC# .net - Dll Naming Conventions in Interface / Implementation Scenarios
    primarykey
    data
    text
    <p>I need some suggestions for clever naming of dll and/or a hint if any naming conventions for the following scenario exist. </p> <p>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. </p> <p>I created some requirements for my dll naming:</p> <ul> <li>The dll with the interface definition needs to be well named because this is the dll the user is referencing.</li> <li>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.</li> <li>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.</li> <li>The namespace of the implementation does not really matter since its only used internally.</li> <li>The dll names should not be too long.</li> </ul> <p>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). </p> <p>But that generates a big problem: </p> <p>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).</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USBasti
    1. USBasti
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POC# .net - Dll Naming Conventions in Interface / Implementation Scenarios
      1. This table or related slice is empty.
      1. VTUpMod
    1. COAdding a couple of paragraphs wouldn't be a bad idea.
      singulars
      1. POC# .net - Dll Naming Conventions in Interface / Implementation Scenarios
      1. USdevoured elysium
    2. COi just did it, the editor seems not be able to handle copied text from ms word=)
      singulars
      1. POC# .net - Dll Naming Conventions in Interface / Implementation Scenarios
      1. USBasti
    3. CO.Net (I think, due to MEF being mentioned)? C++? Tags don't specify this...
      singulars
      1. POC# .net - Dll Naming Conventions in Interface / Implementation Scenarios
      1. USMerlyn Morgan-Graham
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload