The tenet is: reduce
the number of your .NET assemblies to the strict minimum. Having a single assembly is the ideal number. This is for example
the case for Reflector or NHibernate that both come as a
single assembly.
A lot have been said on
this topic. I dig in this article why using more namespaces and less
assemblies for componentization is a good thing. Jeremy Miller does it so in
this blog post. The point is that assemblies are physical while namespaces are logical. As a consequence, having N
assemblies multiplies by N the burden of dealing with physical things. This
burden consists of referencing N assemblies from a Visual Studio project, slowing
down significantly compilation of N Visual Studio projects, managing the
deployment for N files, need for the CLR to do N CAS security checks at startup
time, etc… Personally I have seen applications with up to 750 assemblies! Quote from Jeremy Miller: I took 56 projects one time and consolidated them down to 10-12 and cut
the compile time from 4 minutes to 20 seconds with the same LOC
I would like to discuss
here the motivations behind creating an assembly. I will then illustrate these
reasons through the choices we did for assemblies of the NDepend code base. In an effort to reduce
the number of assemblies in your shop, it is a good thing to find a valid reason for the existence of each assembly of your code base. If no solid reasons can be
found you’ll find room for merging assemblies.
Valid and Invalid reasons to create an assembly
Valid reasons to create
an assembly:
- Tier separation: Need to
run some different pieces of code in different AppDomain or process. The idea is
to avoid overwhelming the precious Window
process memory with large pieces of code not needed.
- Potential for loading large
pieces of code on-demand. This is an optimization made by the CLR: assemblies are loaded on-demand. In other
words, the CLR loads an assembly only when a type or a resource contained in it
is needed for the first time. Here also you don’t want to overwhelm your Window process memory with large pieces
of code not needed most of the time.
- Framework features
separation. In case of very large framework, users shouldn’t be forced to embed
every features into their deployment package. For example, most of the time an
ASP.NET process doesn’t do some Window Forms and vice-versa, hence the need for
2 assemblies System.Web.dll and System.Window.Forms.dll. This is valid only
for large framework with assemblies sized in MB. For example the NUnit http://www.NUnit.com framework certainly does
not need 25 assemblies for 15.000 Lines of Code! Quote from Jeremy Miller: Nothing is more irritating to me than using 3rd party toolkits that
force you to reference a dozen different assemblies just to do one
simple thing.
- AddIn/PlugIn model, need
for interface/factory/implementation physical separation.
- Test/application code separation. If you are not releasing source code but only assemblies, you likely don’t want to release tests. Not releasing test assemblies make this easy.
- When several assemblies have
been created for the reasons above, they likely need to share some common code.
Such shared code must be placed in a dedicated shared assembly.
We could add assembly as a
unit of versioning but IMHO, the need for versioning is a subset of all these
reasons enumerated above.
Invalid reasons to create
an assembly:
- Assembly as unit of
development, or as a unit of test. Modern Source Control Systems make it easy
for several developers to work simultaneously on the same assembly (i.e the
same Visual Studio project). The unit should be here the source file.
- Automatic detection of
dependency cycles between assemblies by MSBuild and Visual Studio. There are tools
such as NDepend that
can detect dependency cycles between namespaces or types of an assembly.
- Usage of internal
visibility to hide implementations details. This public/internal visibility
level is useful when developing a framework where you want to hide
implementation details to the rest of the world. Your team is not the rest of
the world, so you don’t need to create some assemblies especially to hide some implementations
details.
- Usage of internal
visibility to prevent usage from the rest of the application. If you want to
prevent usage and thus control the structure/dependencies of your code base, you should
better use some dedicated tools such as NDepend .
If you are interested in
reducing the number of your Visual Studio projects/assemblies, I would suggest
reading this blog post Hints on how to componentized existing code.
It shows how to use some NDepend dependencies features to get some hints about
which sets of assemblies should be merged.
A case study
NDepend code base is
split across 11 assemblies and here is the dependency diagram of NDepend assemblies
(made by NDepend itself):
Something you might
notice is the XDepend term. We are currently building the XDepend product (aka NDepend for Java), that will be released in 2009. More information are
available on the official website http://www.XDepend.com and I will talk more about this in
the future. This XDepend/NDepend duality leads to 2 different deployment
packages for the 2 products and this is why there are NDepend.Console.exe, VisualNDepend.exe,
NDepend.Platform.DotNet.dll on one
hand and XDepend.Console.exe, VisualXDepend.exe, XDepend.Platform.Java.dll on the other hand.
The need for 4 exe
instead of 2 was needed mostly for terminology. XDepend.Console.exe certainly makes more sense for an XDepend user than NDepend.Console.exe. All
these 4 executables are almost empty in terms of code. The console ones
initialize the platform (Java or .NET) and start the analysis implemented in NDepend.Analysis.dll while the Visual
ones initialize the platform and start the UI, implemented in NDepend.UI.dll.
The need to initialize
the platform (.NET or Java) is a motivation for isolating the code specific to
each platform. Hence the need for the 2 assemblies NDepend.Platform.DotNet.dll and XDepend.Platform.Java.dll.
This separation will also make easy potential future platform support (C++,
Delphi…).
The tool comes with 2
primary usages, analyze code and digging into analysis results through the UI.
This is the motivation for having 2 different executable assemblies: NDepend.Console.exe and VisualNDepend.exe on one hand, and 2
different libraries, NDepend.Analysis.dll
and NDepend.UI.dll on the other hand.
The idea is to avoid having both these assemblies loaded inside the same
process.
NDepend.Analysis.dll and NDepend.UI.dll both rely
on a lot of common code, core domain objects + many helper/util code, hence the
need for creating the NDepend.Framework.dll
assembly.
NDepend.CQL.dll is a lightweight assembly (less than 10KB) that contains the plumbing for
declaring CQL rules directly inside the source code.
Not only this assembly NDepend.CQL.dll
is used by NDepend users who harness this possibility, but also we use it
extensively to declare our own constraints in our code. For users who which to
declare CQL constraints inside their source code, it is more convenient to link
with a single and lightweight assembly, hence the need for NDepend.CQL.dll.
Finally, the NDepend.AddIn.dll assembly contains the
plumbing needed to register the NDepend VisualStudio and Reflector addin. This assembly references big assemblies such as the Reflector.exe assembly. In order to prevent loading by mistake Reflector.exe in one of the NDepend process, it was a good thing to create a dedicated NDepend.AddIn.dll assembly. Also, addin assemblies are registered in VisualStudio and Reflector
through their names and the name NDepend.AddIn is well-suited.