Assembly references and dependencies – Part II

I did finally fix the problem in my last blog post after a late night session of VS2008. It turns out the culprit was the Entity Framework model. How I did figure this out? Using good old Holmesian powers of deduction.

I started by creating a simple data model in Visio – I picked any old Software diagram – just so that I could visually map out all the assembly dependencies graphically (how I would have liked VS2010 architectural modeller here!). I then took a close look at the build order of my solution when doing a build of the unit test project. I noticed that one project actually did not need a rebuild when I amended my unit test project. All my other projects did, but not this one (let’s call this one Framework).

What I then did was create a single Unit Test project and referenced Framework. Sure enough, amending my unit test project did NOT require a rebuild of the Framework project. This immediately told me that the problem I was facing was nothing to do with my PC e.g. virus scanner / solution settings or such. It must have been something specific to a project, or projects, within my solution.

I looked at my architectural diagram and realised that all my projects, except for Framework, were dependant on a single assembly in some way – my Data assembly, which contains my business entities.

image The screenshot above illustrates this sort of dependency chain. The way that Visual Studio works (and this makes good sense), the only time an assembly needs to be rebuilt is either if that assembly itself has changed, or if any dependent assembly has changed. In this case, any change in Data would cause ClassLibrary1 and 2 to be rebuilt.

The upshot is that after going through adding and removing references one-by-one to my unit test project, I determined that the Data assembly was getting rebuilt every time, even if it hadn’t changed. This was having a knock-on effect on all my other assemblies, which is where the long build time came from.

Why was the Data assembly rebuilding? Because of my Entity Framework object model in the assembly. To prove this, just create an empty project and add an EF model to it. As soon as you do this, every rebuild of any assembly will cause a rebuild of that one as well. I need to understand why this is  – I think that it’s to do with how it adds the underlying XML files that make up the EF model into the assembly at build time rather than leave them as files lying around in the bin folder – but not sure. So, for the meantime I have removed all project references to the Data assembly and replaced them with assembly  references – this eliminates the problem.

Either way, I’ve now reduced my build time from ~20 seconds to ~7 seconds 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s