According to this it should be possible to reference projects outside solution and have it working in VS and command line but not TFS.
Unfortunately, when I’ve tried to partition my solution this way, it didn’t work neither in VS2010/devenv nor in msbuild.
In both cases the error was:
The OutputPath property is not set for project ‘Common.csproj’.
Please check to make sure that you have specified a valid combination
of Configuration and Platform for this project. Configuration=’Debug’
Platform=’AnyCPU’. This error may also appear if some other project
is trying to follow a project-to-project reference to this project,
this project has been unloaded or is not included in the solution, and
the referencing project does not build using the same or an equivalent
Configuration or Platform.
However, current Platform is “x86” and no matter which platform and configuration I set in VS or msbuild it’s always trying Debug|AnyCPU. In case of msbuild if I set /p:OutputPath=bin\x86\Debug it propagates to child projects correctly.
Is this a bug, can I work-around it ?
UPDATE
Found the bug in MS Connect. Unfortunately closed as Won’t Fix 🙁
UPDATE 2
Found workaround: set ShouldUnsetParentConfigurationAndPlatform=false. Both on command line for msbuild and in project file (before any imports) to fix Visual Studio.
If I understand the problem correctly, it’s actually because the AssignProjectConfiguration target is not correctly setting the configuration / platform properties for those projects.
If you know what their configurations and platforms should be, you could always just inject a target to run right after the AssignProjectConfiguration target, and override the SetConfiguration and SetPlatform properties on each item representing an unresolved (meaning not part of the solution configuration) inter-project reference.
For some stupid reason, the Microsoft-provided target stores the list of unresolved project references in the same collection as the resolved ones (but nowhere else), which leaves you with 2 options:
Either way, once you have your list of correctly configured project references, you can simply replace the unresolved items in the ProjectReferenceWithConfiguration item group with their manually modified counterparts (using another dynamic ItemGroup element with a Remove and then an Include).
Mind you, I wouldn’t do things the way you are doing them. If you want to split your product into several solutions, then I would just have each solution publish shared outputs into a common staging area and have .proj scripts to link them together. I’ve learnt the hard way that command-line-style MSBuild and inside-VS-style MSBuild do not mix (they have made some odd compromises to ensure interoperability with non-MSBuild project systems, of which the whole AssignProjectConfiguration-with-VS-provided-solution-config-XML process is one).