I mentioned a couple of days ago that I have an application where I was trying to avoid circular references. After some back and forth I managed to get around the issue, but now it turns out I have another really weird problem in Visual Studio.

Visual Studio is locking one of my DLLs into memory as soon as the project loads. 

After checking a little closer into this it turns out that this is normal. Apparently Visual Studio loads referenced assemblies into memory in order to be able to provide Intellisense and the class browser etc.

It turns out that my problem was related to the way I had rearranged my projects. Let me explain <g>…

I had a relatively simple project oringinally for West Wind Web Monitor which consisted of two components:

• WebMonitor (Main Exe)
• WebMonitorComponents  (non-UI core components)

When I decided to add Add-In support I had to break up the main EXE so that the Add-in can set a reference to the UI. .NET cannot set a reference to an EXE (I have to wonder why not?), so I had to create a Startup EXE project and relegate my Main project to a WebMonitorUi DLL project. It worked but after a few compiles back and forth I ended up with locking problems.

The issue is that I didn’t move the projects physically on disk, so I cheated a little here, by still using the UI projects output directory as the main directory where everything gets built. So the Startup EXE now built its output in to this directory as well…

Well, somewhere along that train of events a file gets compiled twice and tries to overwrite a file that VS.NET is apparently trying to load at the same time.

When a new assembly gets compiled it looks like VS is reloading the project files into VS.NET. If you watch the DLL loaded list with Process Explorer you’ll see that the DLLs get unloaded and then immediately reloaded into VS.

The problem is intermittent but my guess is it only occurs when VS is trying to load the DLL while the second build is trying write the DLL to disk at the same time.

Moral of the story: Be very careful when you change output paths for your assemblies especially if the output goes into directories where other project files are being built as well.

In my case the solution was to rearrange the projects so that everything is indeed building into their respective bin\debug directories rather than trying to have the satellite assembly try to build into the Exe’s directory.

Moral #2: It's probably a real good idea to build your UI for an application into a DLL rather than into the main Exe just in case you need to later expose any of the UI functionality externally like an Add-in.

Trying to be too tricky or taking a shortcut can cost you as it did me – I wasted a few hours on this trying to understand why the heck VS was loading my DLL into DevEnv. I still don’t see why VS was loading only one of the DLLs (the UI one, but not the Components one)… <shrug>