I’m writing applications and libraries simultaneously, and whenever I update a library it’s a bit hard to get it recognized in the consumer application. I have open a separate Visual Studio instance for each library and application. After rebuilding a library I get in the consumer applications the warning/error below. I then either have to remove the reference and add it again. Or I have to clean and build the library solution 3-4 times, for such warning/error to disappear in the consumer app VS solution. Why would doing that 4 times make any difference to doing it 1 or 2 times..?
Would like to understand why this happens and if something can be done to make this work more smoothly?
Not sure if it’s relevant but most of my applications I write in VB.NET and libaries in C# (as I’m in progress of changing everything to C#). I also have C# files from the libraries open in the consumer application VS, as it pops up during debugging. I also reference library dlls in the library project /bin/Debug folder, because I’m making a lot of changes at this point of development.
Warning 1 Namespace or type specified in the Imports ‘somelibrary’
doesn’t contain any public member or cannot be found. Make sure the
namespace or the type is defined and contains at least one public
member. Make sure the imported element name doesn’t use any
aliases. ‘local path’
..
Error 72 Unable to load referenced library ‘path\somelibrary.dll’: The
process cannot access the file because it is being used by another
process.
This is the fundamental source of your problem. Visual Studio does not like it when things outside it’s control change. You should have a single solution open with all the relevant projects included in it. Then when something changes, all the projects which depend on that project will automatically be rebuilt. (At least, that’s the default.)
I don’t think it has anything to do with how many times you clean and rebuild it, but how long it’s been since you last made a change – you have to wait long enough for the VS instance building the dll to release the lock on the file, before the VS instance that is using it is able to access it.