EDN Admin
Well-known member
Hello,<br/>
we recently switched from visual studio 2008 to 2010 and faced a couple of errors<br/>
which I will describe in the following.<br/>
<br/>
The source code (~10 Million LOCs) is distributed over approx. 500 projects (95%: DLLs, 5%: Executables oder static libraries).<br/>
As visual studio is hardly capable to deal with a Solution (.sln file) that references all those<br/>
projects, we splitted em into a bunch of smaller solutions, letting visual studio breathe.<br/>
<br/>
Dependency mechanism in visual studio 2008:<br/>
-------------------------------------------<br/>
Every project has a unique ID (a.k.a GUID). Project to project dependencies are set in the hosting solution file.<br/>
In most cases, one additionally sets a linker dependency in the project file, when there is a project dependency.<br/>
To link the main exe file, we use a linker response file (.rsp), listing all the objects and static libs which are to<br/>
be linked to the exe file.<br/>
<br/>
<br/>
Upgrading to (MSBuild using) visual studio 2010, it has created project to project
<br/>
dependency definig "project references" which is absolutely OK. <br/>
As this new dependency definig mechanism makes the old solution based project to project dependency definition
<br/>
mechanism obsolete, we removed the corresponding entries from the solution file.<br/>
We additionally removed the linker dependency settings from projects as the new "project references" promise
<br/>
to do the job automatically.<br/>
<br/>
To illustrate the problem, we have set up a small test scenario having the following structure:<br/>
<br/>
+---bin<br/>
+---Win32<br/>
+---Debug<br/>
+---A<br/>
+---B<br/>
+---Test1<br/>
+---Release<br/>
+---B<br/>
+---Test1<br/>
+---src<br/>
+---components<br/>
+---A<br/>
+---B<br/>
+---mainApp<br/>
+---Test1<br/>
+---ipch<br/>
+---test1-3926509a<br/>
<br/>
<br/>
Directory src/components has a solution file (components.sln) which lists the projects [A] and .<br/>
<br/>
Directory src/components/A has a vcxproj file (A.vcxproj) creating A.dll.<br/>
<br/>
Directory src/components/B has a vcxproj file (B.vcxproj) creating B.dll (B depends on A).<br/>
There is a project reference definition from to [A].<br/>
Copy local is set to False.<br/>
Link library dependencies is set to True.<br/>
<br/>
---------------------------------------------------------<br/>
<br/>
Directory mainApp/Test1 has a solution file (Test1.sln) listing the project [Test1].<br/>
<br/>
Directory src/mainApp/Test1 has a vcxproj file creating an exe file (and dependending on and [A]).<br/>
There is a project reference definition from [Test1] to and [A] even though and [A] are in an other solution file.<br/>
Copy local is set to False.<br/>
Link library dependencies is set to True.<br/>
<br/>
<br/>
<br/>
Build order: <br/>
1) components.sln<br/>
2) Test1.sln<br/>
<br/>
Building the above solutions according to the specified build order in Debug|Win32 mode succeeds.<br/>
<br/>
Performing a clean on both solutions in debug mode, switching to Release|Win32 <br/>
and building again both solutions fails, though !<br/>
components.sln successfully creates A.dll and B.dll.<br/>
Building Test1.sln fails as it obviously tries to link agains the debug versions ob A and B which are of course absent<br/>
due to the clean in debug mode.<br/>
<br/>
We circumvent the circumstance by the following method:<br/>
- "Project references" are used to specify dependencies and defining the build order<br/>
- Copy local is still set to False.<br/>
- Link library dependencies is set to False.<br/>
- Linker dependencies are specified again manually <br/>
<br/>
<br/>
If someone has experienced the same problems, we would appreciate to exchange experiences<br/>
in order to figure out whats going wrong.<br/>
<br/>
If desired, I can package the test scenario and send it to whoever is interested.<br/>
<br/>
Cheers,<br/>
<br/>
Babak Sayyid Hosseini<br/>
View the full article
we recently switched from visual studio 2008 to 2010 and faced a couple of errors<br/>
which I will describe in the following.<br/>
<br/>
The source code (~10 Million LOCs) is distributed over approx. 500 projects (95%: DLLs, 5%: Executables oder static libraries).<br/>
As visual studio is hardly capable to deal with a Solution (.sln file) that references all those<br/>
projects, we splitted em into a bunch of smaller solutions, letting visual studio breathe.<br/>
<br/>
Dependency mechanism in visual studio 2008:<br/>
-------------------------------------------<br/>
Every project has a unique ID (a.k.a GUID). Project to project dependencies are set in the hosting solution file.<br/>
In most cases, one additionally sets a linker dependency in the project file, when there is a project dependency.<br/>
To link the main exe file, we use a linker response file (.rsp), listing all the objects and static libs which are to<br/>
be linked to the exe file.<br/>
<br/>
<br/>
Upgrading to (MSBuild using) visual studio 2010, it has created project to project
<br/>
dependency definig "project references" which is absolutely OK. <br/>
As this new dependency definig mechanism makes the old solution based project to project dependency definition
<br/>
mechanism obsolete, we removed the corresponding entries from the solution file.<br/>
We additionally removed the linker dependency settings from projects as the new "project references" promise
<br/>
to do the job automatically.<br/>
<br/>
To illustrate the problem, we have set up a small test scenario having the following structure:<br/>
<br/>
+---bin<br/>
+---Win32<br/>
+---Debug<br/>
+---A<br/>
+---B<br/>
+---Test1<br/>
+---Release<br/>
+---B<br/>
+---Test1<br/>
+---src<br/>
+---components<br/>
+---A<br/>
+---B<br/>
+---mainApp<br/>
+---Test1<br/>
+---ipch<br/>
+---test1-3926509a<br/>
<br/>
<br/>
Directory src/components has a solution file (components.sln) which lists the projects [A] and .<br/>
<br/>
Directory src/components/A has a vcxproj file (A.vcxproj) creating A.dll.<br/>
<br/>
Directory src/components/B has a vcxproj file (B.vcxproj) creating B.dll (B depends on A).<br/>
There is a project reference definition from to [A].<br/>
Copy local is set to False.<br/>
Link library dependencies is set to True.<br/>
<br/>
---------------------------------------------------------<br/>
<br/>
Directory mainApp/Test1 has a solution file (Test1.sln) listing the project [Test1].<br/>
<br/>
Directory src/mainApp/Test1 has a vcxproj file creating an exe file (and dependending on and [A]).<br/>
There is a project reference definition from [Test1] to and [A] even though and [A] are in an other solution file.<br/>
Copy local is set to False.<br/>
Link library dependencies is set to True.<br/>
<br/>
<br/>
<br/>
Build order: <br/>
1) components.sln<br/>
2) Test1.sln<br/>
<br/>
Building the above solutions according to the specified build order in Debug|Win32 mode succeeds.<br/>
<br/>
Performing a clean on both solutions in debug mode, switching to Release|Win32 <br/>
and building again both solutions fails, though !<br/>
components.sln successfully creates A.dll and B.dll.<br/>
Building Test1.sln fails as it obviously tries to link agains the debug versions ob A and B which are of course absent<br/>
due to the clean in debug mode.<br/>
<br/>
We circumvent the circumstance by the following method:<br/>
- "Project references" are used to specify dependencies and defining the build order<br/>
- Copy local is still set to False.<br/>
- Link library dependencies is set to False.<br/>
- Linker dependencies are specified again manually <br/>
<br/>
<br/>
If someone has experienced the same problems, we would appreciate to exchange experiences<br/>
in order to figure out whats going wrong.<br/>
<br/>
If desired, I can package the test scenario and send it to whoever is interested.<br/>
<br/>
Cheers,<br/>
<br/>
Babak Sayyid Hosseini<br/>
View the full article