Question

I have a class library which I maintain in it’s own project/solution. It contains a few basic functions I’ve written, that I use in some older VB.NET applications mainly.

I’m doing some work on one such application, and it has required changes to the Library assembly as well as the main application. However, I’m finding that when I change and compile the library, when I come to re-compile the main application I get an error:

Error 8 Unable to load referenced library 'myLibrary.dll': The process cannot access the file because it is being used by another process.

I’ve specified the ‘myLibrary\bin\Release\myLibrary.dll’ as the reference in the main project. I know in the past that I had the library project in the same solution, thus I could specify the project as a reference, rather than the release DLL, but I’d prefer to keep the projects separate.

Re-specifying the reference or reloading the main project solves the problem (temporarily at least), but I’d rather find a more sophisticated solution.

Answer 1

Why prefer to keep them separate? If they’re part of the same codebase, they should be in the same solution. By short-circuiting this you’re effectively limiting the development capabilities of Visual Studio with regards to the referenced assembly in the codebase. Additionally, referencing the bin output is very messy. If you want it to be a standalone library, have it build its output and copy that output to a lib folder somewhere. Then you can reference the final output, not the highly-transient bin directory.

Essentially, in terms of “find[ing] a more sophisticated solution,” it’s a matter of using the tooling that Visual Studio provides. Organizing code into solution files is part of that tooling.