7

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.

Community
  • 1
  • 1
Marcin Wisnicki
  • 4,511
  • 4
  • 35
  • 57

2 Answers2

0

I encountered something similar in VS2012. For me, it was related to the ShouldUnsetParentConfigurationAndPlatform property of the AssignProjectConfiguration target being set to true during the build. This resulted in "GlobalPropertiesToRemove = Configuration;Platform" which caused the Configuration and Platform properties to be cleared for the project reference.

I was able to see this occurring by looking in the Build output window after setting Tools -> Options -> Projects and Solutions -> Build and Run -> MSBuild project build output verbosity -> Diagnostic.

With a blank Configuration/Platform, this caused the following line in some of my projects to match, resulting in Debug assemblies in the project output even in a Release build:

<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>

The solution was to modify those csproj files to specify Release as the configuration to use when the Configuration variable was empty/blank:

<Configuration Condition=" '$(Configuration)' == '' ">Release</Configuration>
J c
  • 6,387
  • 3
  • 29
  • 29
0

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:

  1. Just set each project's properties manually (ie. hard-coding via a dynamic ItemGroup element inside your injected target).
  2. Call the AssignProjectConfiguration task yourself from your injected target, collect the unassigned outputs to assign them all a default configuration / platform of your choosing.

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).

tintoy
  • 605
  • 4
  • 9