Reputation: 2437
I have a .NET project with namespace MyCompany.InformixConnector
. I added a COM wrapper as a separate project/assembly that will only be deployed to a small number of clients. I am struggling with how to organize the projects / assemblies.
I currently have 2 assemblies: MyCompany.InformixConnector
and MyCompany.InformixConnector.Com
The .Com
assembly has a reference to the "core" assembly. However, it feels wrong having a lower-level assembly referencing a higher one.
I thought about 2 alternatives:
MyCompany.InformixConnector.Core
and MyCompany.InformixConnector.Com
MyCompany.InformixConnectorForCom
I suppose the fundamental question is: Should a COM wrapper live in the same namespace as the code it's wrapping?
Upvotes: 1
Views: 82
Reputation: 14099
MS naming guidelines state that there is nothing wrong for a nested namespace depend on a higher level one:
A nested namespace should have a dependency on types in the containing namespace. For example, the classes in the System.Web.UI.Design depend on the classes in System.Web.UI. However, the classes in System.Web.UI do not depend on the classes in System.Web.UI.Design.
The same logic could be applied to the assembly naming. In your particular case I would put core functionality into MyCompany.InformixConnector.Core
namespace and assembly, that would explicitly indicate where the common stuff is.
Then create a namespace for interoperability MyCompany.InformixConnector.Interop
and put there all the generic stuff needed for dealing with com and other 3d party stuff. If there is no such stuff you can skip it and add it as needed.
Then create a namespace and assembly for your com wrapper MyCompany.InformixConnector.Interop.Com
. This assembly would reference MyCompany.InformixConnector.Core
and MyCompany.InformixConnector.Interop
(if needed).
Upvotes: 1