Just dealt with another Visual Studio 2008 “feature”.
You can specify all the necessary “Project Dependencies” in Visual Studio, but will get “CSC : error CS0006: Metadata file FooBar.dll could not be found“. Even if your csproj files have correct references to other solution projects, msbuild will fail.
Maybe it appears only if project output path is outside of project directory.
It appears that Visual Studio keeps the dependencies in two ways, only one of which is read by MSBuild. I see that because I still can specify dependencies in GUI, copy solution to other machine and build it with VS in correct order.
Not with MSBuild.
The data needed by MSBuild is a “ProjectSection(ProjectDependencies) = postProject” section of SLN file. Like this:
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "make_versioninfo", "make_versioninfo.vcproj", "{F0E0541E-F17D-430B-97C4-93ADF0DD284E}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "pythoncore", "pythoncore.vcproj", "{CF7AC3D1-E2DF-41D2-BEA6-1E2556CDEA26}"
ProjectSection(ProjectDependencies) = postProject
{F0E0541E-F17D-430B-97C4-93ADF0DD284E} = {F0E0541E-F17D-430B-97C4-93ADF0DD284E}
EndProjectSection
EndProjectNote where to take the GUID of a referenced project.
If you create this section by hand, your project will build.
Not too much fun, if you have over 20 projects, where you can have up to 190 project dependencies… Have fun.
12 Comments
Thanks for the post – it helped me out
– what a !@#$ mess !!
Unfortunately, this does not seem to work with my MSBuild.
vs2008, sp1
Doug,
This might be tricky. Check if you’re using right GUIDs in right order (in the line with “} = {“), and that you caught all necessary dependencies.
My MSBuild is of the same version.
?????, ??? ?????????, ???????! 🙂
I mean, chuvak, eto genialno, spasibo!
MSBuild actually only uses the build ordering when you build a solution from the command line, or when you build in the IDE. You can set this in the IDE with the menu option “Build Order…” in the Project menu.
However, what MSBuild creates and uses are what we refer to as P2P’s (or Project to Project references). These can be created in the IDE by right clicking the References node (C# application) and selecting “Add Reference…”. Go to the Projects tab, and choose the project that this project depends on. You can add multiple. This adds XML to the .csproj file that looks like:
{EF60F047-304C-4684-9278-E8DD8C7618F8}
Microsoft.Build.BatchBuild
This project reference allows MSBuild to make sure that the referenced project is built prior to building this project. This works on solutions or projects, in the IDE and on the command line.
Note that you can also get to the References dialog by choosing “Add Reference…” from the project menu with the appropriate project selected in solution explorer.
Chuck England
chuckeng@microsoft.com
Visual Studio Platform
Program Manager – MSBuild
THANK YOU – you are a life saver
Chuck, thank you for explaining.
I don’t know why wasn’t I able to find it in VS. Sadly, I have no Visual Studio now and can’t check if it was there in 2005 version: I was sure it wasn’t the thing project reference did.
I have inherited a project with both C# and C++ projects. I understand setting dependencies and references in and between C# projects. How should references/dependencies be set between C++ projects or from a C# to a C++ project or vice versa? There seem to be several places in the Properties of a C++ project where another project can be referenced or “linked.”
Joe, I believe it’s the same as for ???? .NET projects.
Linking is not about build order, it’s about physical usage of one project functions in another.
Prior to Visual Studio 2010, C++ projects were build using VCBuild, and not MSBuild. As a result, you would either need to use “DevEnv.exe /build” (which uses the same Solution Build Manager as the IDE) to build the projects, or create your own traversal type project.
And example of writing a traversal target may be found in Figure 7 of this article: http://msdn.microsoft.com/en-us/magazine/dd483291.aspx
Thanks Chuck for a good piece of knowledge.
I cannot remember for sure now, but it feels like it was a purely C# solution, and I was running it with /build. Well, anyway.
One Trackback/Pingback
[…] *.sln is not a native MSBuild file type, unlike *.??proj files. I myself have run into the problem described here; I’ve also seen the opposite behavior on […]
Post a Comment