Hi Tom
I assume you mean "... does *not* cause all the dll locking issues ...".
Microsoft have confirmed that there is a problem with referencing the dll
directly, so it is better to do it the way you are doing it.
That said, I haven't noticed any significant delay in building my solutions
(I have nine projects in the current solution). In fact, I noticed a marked
improvement in compile time when I switched to referencing the projects
rather than the dlls. I am using VB.NET, which might make a difference, but
I wouldn't have thought so. Perhaps someone else can suggest a reason.
Charles
"Tom" <ts******@gmail.com> wrote in message
news:c7*************************@posting.google.co m...
I did it from the projects Tab with a local copy. The reason being
this does cause all the dll locking issues that you get when you
reference the dll directly. Also the compiler should know what dlls it
needs to build when changes are made. Otherwise I would have to figure
out what assemblies I had to build manualy corrrect?
"Charles Law" <bl***@nowhere.com> wrote in message
news:<uS**************@TK2MSFTNGP14.phx.gbl>... Hi Tom
How did you add the projects as references to your solution? Of the two
ways: select the dll output from each project and add as a reference OR
select from the Projects tab on the Add Reference dialog, I have found
that
the latter is significantly quicker when building a large solution. It
also
eliminates some problems that occur with resolving references.
HTH
Charles
"Tom" <ts******@gmail.com> wrote in message
news:c7**************************@posting.google.c om... >I have a large soultion 20+ projects C++ MC++ and C#. When I hit F5 no
> matter what. It checks to see if it needs to build every project.
> "projectX" is up to date. It takes like 10 seconds. I know other
> people must of had this problem. Does anyone have a solution, Aside
> for turning off projects in the configuration manager?
