>If you use multiple solutions to access your shared files you'll likely get those kind of errors if for whatever reason the shared assembly breaks (ie. doesn't compile). It'll then break in all the projects that depend on it.

In this case, this is not related. Because, the framework always compile but still, out of about 40 compiles, will break the client project which has a reference to it. So, the client project looses its reference thus ends up by showing the maximum number of errors it could, thus 102. Restarting the client project resolves the issue. It is just the restarting which is irritating me. Of course, if there would be something not allowing the framework to compile, thus generating an error, I would understand that it could affect the dependencies. But, everytime it happens, it is not the case.

>How you develop depends on your setup. I prefer to add all the projects that I own to my solution so that I can step through all code and then add references to all the projects as needed to any of the other projects. So when I'm working on a Web project I typically have a Web project, a business project, and then 4 or 5 support projects that are 'framework' projects that I've loaded into this solution.

So, in all your client application, the ones that depend on the framework, you have a reference to the project, but the framework project is also included as part of the solution. Is that correct?