I've seen this problem before and as a result I <exec> devenv.com to
compile my master solutions. The following analysis applies to Visual
Studio .NET 2003. I've not tried Visual Studio .NET 2005 and thus do not
know if it differs from what I've seen with Visual Studio .NET 2003.
The Visual Studio project files use a GUID to "identify" the projects
(ProjectGuid in C#, ProjectGUID in VC++). The Visual Studio solution
files also use a GUID to "identify" the projects in the solution.
Usually the GUID in the solution file and the GUID in the project file
match. I've seen situations where the GUID in the solution file doesn't
match the one in the project file and the error reported is the error
you're seeing.
The <solution> task parses the solution file using the GUIDs there as
keys to identify projects. Somewhere along the line (I forget the exact
spot) the <solution> task parses the project files and finds a GUID that
is not already a key (not in the solution file) and it barks that the
project must be included for the build to work.
Visual Studio obviously uses a slightly different mechanism because it
works there. I've seen a more interesting error which might shed some
light into how Visual Studio handles this. I've gotten an error very
similar to the one you're getting but the GUID is empty (''). When I've
tried to track down the offending project file I've discovered that the
project file in question does not contain the ProjectGUID entry (for
some reason it's only happened with VC++ projects). It seems that Visual
Studio doesn't care what GUID is specified in the project files. The
only GUID that matters is the solution GUID. The <solution> task
requires that the GUIDs match and that's why we get inconsistent
behavior.
Visual Studio keeps track of project dependencies in the solution files.
Within a particular solution file each GUID is unique and used to
identify a single project. Clearly, when Visual Studio parses the
project files it simply ignores the ProjectGuid and continues to
"identify" the project using the GUID in the solution file. Perhaps that
is the mechanism that the <solution> task should follow.
This error is due to a logical data corruption, the solution and project
GUIDs do not match, but fixing the error in the solution and project
files is a lot of work and there is no easy way to automate it. If
you're development workspace looks similar to ours you'll notice that
most projects exist in their own "personal" solutions (most of our
projects are COM components). There also exist a number of "master"
solutions with different cross-sections of the code. For example, in our
case our software handles a number of hardware categories and we have a
solution with those projects relevant to each category, plus a master
solution with all the projects. (Actually, due to some Visual Studio
annoyances our "master" solution is divided up into 4 solutions. Visual
Studio appears to load some of the outputs from some dependent projects
if all the projects are in the same solution and we can't successfully
clean the whole solution...) The fix would require to build a dependency
graph of project files and solution files and then make sure that all
the GUIDs which are meant to identify each individual project are
identical across all solution and project files. If any new solutions
are created one must remember to verify that the correct GUID was used
in the new solution.
This simply becomes a really nasty management problem. Our solution and
project files somehow became logically corrupt by no external source
other than Visual Studio itself. Our code has been converted over the
years from different versions of Visual Studio so perhaps the conversion
process is at fault but I can't be sure of that. What I do know is that
nobody here makes any changes to the solution or project files by hand
(using a text editor). All changes to those files are done via Visual
Studio through the appropriate properties.
I hope that this will help others with this problem to find the true
cause of the error. I propose to the NAnt team that they review the
solution parsing mechanism and consider ignoring the GUIDs in the
project files. The GUID stored in project files are not relevant when a
solution file has been specified.
--Edwin
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Foster,
Richard - PAL
Sent: Thursday, January 27, 2005 1:57 PM
To: Eric Fetzer; Nant Users
Subject: RE: [Nant-users] Project References
Eric,
When we encountered a similar problem it usually boiled down to one of
two things:
1) A referenced project was the one that actually needed the project in
question.
2) The reference path was incorrect (typically a typo).
The easiest way I have found to determine which is the case is to find
out what that project is. (A simple search should be able to tell you).
Once you know that, check and see if that project is among the
referenced projects for whichever assembly fails to build. If it isn't
then you are looking at option 1. If it is, then check your paths again.
Hope this helps,
Regards,
Richard
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric Fetzer
Sent: Thursday, January 27, 2005 11:54
To: Nant Users
Subject: [Nant-users] Project References
I have been having trouble trying to get Project References to work with
the Solution Task. I'm running version "NAnt 0.85 (Build 0.85.1732.0;
net-1.0.win32; nightly; 9/28/2004". We just changed all of our
references to Project vs. DLL references.
The projects build via VS.Net (with a master solution), but won't with
NAnt (Solution Task pointing to all of the projects). The following
error is
given:
Project with GUID
'{3ACFB63F-F1C7-46B2-A17E-5B4D76840D7D}' must be included for the build
to work.
Any help would be greatly appreciated (i.e. How to trouble shoot this
issue especially)!
Thanks,
Eric
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Nant-users mailing list
Nant-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-users
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Nant-users mailing list
Nant-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-users
