Condition on ProjectReference Is Not Respected in Visual Studio

---

Issue moved from microsoft/msbuild#5410

• Please respond to @aolszowka.

---

From @aolszowka on Friday, June 5, 2020 6:51:14 PM

Steps to reproduce

Here is a repository that reproduces the issue: https://github.com/aolszowka/ProjectReferenceConditionalTest

The jist of it is this project will still show up and build within Visual Studio even when a condition is used in this manner:

<ProjectReference Include="..\A\A.csproj" Condition="'1'=='2'">
   <Project>{679190e5-cd34-4391-85de-9031f04f50a5}</Project>
   <Name>A</Name>
</ProjectReference>

Calling Pure MSBuild works as expected, should this be a Developer Community Bug?

Expected behavior

Visual Studio and MSBuild should behave identically.

Actual behavior

Visual Studio will attempt to build/reference the project, whereas MSBuild will not.

Environment data

msbuild /version output:

Microsoft (R) Build Engine version 16.6.0+5ff7b0c9e for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

16.6.0.22303

OS info: Windows 10 Enterprise 1909

If applicable, version of the tool that invokes MSBuild (Visual Studio, dotnet CLI, etc): Visual Studio 2019 Enterprise 16.6.1

[shuffle2]

I’ve also hit this on a C++ project (https://github.com/dolphin-emu/dolphin/blob/55c931d6248c6dda5a8a9cbd332131255d62bc3f/Source/Core/DolphinQt/DolphinQt.vcxproj#L524) curious how this:

This limitation has been removed in the new project system (.NET Core projects) and .NET Framework projects will benefit when we move those projects to open with it in a future Visual Studio version.

applies to C++ projects.

Edit: I’m pretty sure this is actually a regression in this case - this vcxproj was working in the past.

Edit2: It actually seems to be some regression with how VS handles the “batch build” and configuration manager UI. For example, if the target Platform is set to ARM64 when VS is launched, VS seems to cache the project reference settings and does not update them, even if a Batch Build targets x64, or if you change the current Platform to x64 in the UI and start a build. So, not sure where this bug should get routed to…however, if there’s a “proper” way to solve it for VS and msbuild (this C++ project’s CI server uses msbuild), it would be great to know. The above-mentioned <Choose><When> trick didn’t change the behavior for me.

[zuckerthoben]

I have a similar issue, but its the inverse situtation: ProjectReference Condition is supported in Visual Studio but not in commandline dotnet build:

Here is a commit that works it around: openmod/openmod@df876c8

In short, I had to move the ProjectReferences to their own ItemGroup and apply the condition to the ItemGroups instead.

Visual Studio Version: 16.3.1 dotnet --version: 3.1.100

I have the same problem, but moving the conditions to an ItemGroup is not helping. I can build my solution locally in VS, but not with the DotNetCoreCLI or the MSBuild task in Azure DevOps.

Also the project is already using the current project system and if I understand correctly it should not be a problem there?