title: Best practices for merging assemblies?
body: <p>I am wondering what are the heuristics when creating releases of libraries to be included in other projects in relation to dependencies and if I should include them or not.</p>
  
  <p>My problem is the following:</p>
  
  <p>I have a CommonUtilities library that provides as the name implies a set of utilities that can be used in more than one place. Dependencies of CommonUtilities include log4net.dll (the logging framework) and Oracle.DataAccess.dll (database driver). </p>
  
  <p>I have another project called MyProject that I want to include CommonUtilities in. MyProject also depends on Oracle.DataAccess.</p>
  
  <p>If I use ILMerge and merge CommonUtilities into a single assembly CommonUtilities.dll and reference that from MyProject everything compiles but I am sure I should explicitly reference Oracle.DataAccess from MyProject as it is a dependency and not use the assembly merged into CU. Adding a reference to Oracle.DataAccess as well results in ambiguous using statements as there are two Oracle.DataAccess assemblies referenced.</p>
  
  <p>Using ILMerge /Internalize in my case results in compile errors as types from the internalized Oracle.DataAccess assembly are being returned from CommonUtilities and as they are marked internal MyProject does not recognize the type returned.</p>
  
  <p>The only way to make this work is simply to not merge this particular assembly (Oracle.DataAccess) into CommonUtilities and only reference that from MyProject. 
  This in turn creates a new problem: Which Oracle.DataAccess.dll should I reference - the dependency distributed with CommonUtils or not?</p>
  
  <p>Are there other ways to go about all this?</p>