The mechanics of vs2005 projects

[Frank Rizzo]

Hello, I work with a vs2005 solution that has about 10 pretty heavy duty
projects. All projects have dependencies among themselves via project
references (as opposed to DLL references). As you can imagine vs2005
takes its sweet time when I press the run/debug button.

So as an experiment, I created a solution with only the top level
project and pressed Run. Even though the project had references to
other projects (e.g. .csproj files), it compiled and ran fine. So I am
trying to understand exactly how vs2005 works in this regards. Did it
simply figure based on the referenced .csproj file where its
corresponding DLL is and loaded that?

Thanks.

 

[Stephany Young]

Yes.

 

[Nick Hounsome]

Hello, I work with a vs2005 solution that has about 10 pretty heavy duty
projects. All projects have dependencies among themselves via project
references (as opposed to DLL references). As you can imagine vs2005
takes its sweet time when I press the run/debug button.

So as an experiment, I created a solution with only the top level project
and pressed Run. Even though the project had references to other projects
(e.g. .csproj files), it compiled and ran fine. So I am trying to
understand exactly how vs2005 works in this regards. Did it simply figure
based on the referenced .csproj file where its corresponding DLL is and
loaded that?

Thanks.

VS normally copies the DLLs into the same directory as the exe - but of
course they were already there from before so when you ran it the CLR had no
problem finding them to load.

The "proper" way to do this is to explicitly reference the dlls. It should
then re-copy them if they change.