Ouch. I’ve hit a snag in an app where I’m trying to load assemblies in an Add-in fashion. I’m running into a problem that I can’t seem to get around where I have circular assembly references where Assembly A uses pieces of Assembly B and B requires references to assembly A. Visual Studio is not letting me do this.

 

Scenario looks like this:

 

I have a Windows Forms app that has a startup EXE which is a really small EXE assembly that basically contains a startup class. I have all of my UI separated into a separate UI DLL because I need to be able to reference the UI classes from the add-in manager interface, and you can’t set a reference to an EXE. So I broke everything out into separate projects. I now have:

 

  • Startup (exe)
  • UI (dll)
  • Components (the non-UI ‘business’ layer) (dll)
  • Add-in related stuff (exe)

 

The problem is that the add-in code needs access to both the UI and Components DLL. But the UI component also needs to have access to the Add-in DLL since the add-in loader sets up the handlers and passes it forward to the actual add-in for processing.

 

So, how would I deal with this?

 

Right now I’m thinking I HAVE TO stick the add-in base interface and loader code into the UI DLL. Which is Ok for me but kind of weird when you ask developers to set a reference to the UI dll to build an add-in?

 

The actual add-ins won’t be a problem because they will be dynamically loaded into another AppDomain. So as long as I can get a reference to the Add-In interface I will be fine.

 

Later...

 

Ok so that worked ugly as it is. However, now I’m getting one of my assemblies locked into VS.NET. It’s locking files in the OBJ directory. I can see the UI DLL loaded INSIDE of the DevEnv process. Not sure how it's getting loading into VS.NET. No, no user or custom controls loaded onto the toolbox either. Hmmm…

 

Anybody have any ideas what's going on here? Now everytime i touch the UI dll I have to shut down VS, delete the OBj directory so I can recompile.

 

Aaarrgh...