Legacy project format doesn't respect conditions in Directory.Build.props and targets for PackageReference

[rainersigwald]

From @Styxxy on October 23, 2018 21:0

Description

When having a Directory.Build.props and/or Directory.Build.targets file, where you include a <PackageReference /> these files are also included (by MSBuild, also Visual Studio) for legacy based project files (non-sdk format project files). This is great, except that when you set a condition on the <PackageReference /> or it's <ItemGroup>, even if the condition would evaluate to false (and thus it should be skipped), the package is still included in the project. This doesn't happen for an SDK based project.

Reproducable sample repository

https://github.com/Styxxy/Issue-BuildPropsTargets

Environment details

msbuild /version

C:\Users\Styxxy>msbuild /version
Microsoft (R) Build Engine version 15.8.169+g1ccb72aefa for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

15.8.169.51996

dotnet --info

C:\Users\Styxxy>dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   2.1.402
 Commit:    3599f217f4

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.402\

Host (useful for support):
  Version: 2.1.4
  Commit:  85255dde3e

.NET Core SDKs installed:
  1.0.4 [C:\Program Files\dotnet\sdk]
  1.1.0 [C:\Program Files\dotnet\sdk]
  2.0.3 [C:\Program Files\dotnet\sdk]
  2.1.2 [C:\Program Files\dotnet\sdk]
  2.1.4 [C:\Program Files\dotnet\sdk]
  2.1.201 [C:\Program Files\dotnet\sdk]
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.302 [C:\Program Files\dotnet\sdk]
  2.1.400 [C:\Program Files\dotnet\sdk]
  2.1.401 [C:\Program Files\dotnet\sdk]
  2.1.402 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.3-servicing-26724-03 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Visual Studio 2017

Microsoft Visual Studio Community 2017
Version 15.8.7
VisualStudio.15.Release/15.8.7+28010.2046
Microsoft .NET Framework
Version 4.7.03056

Installed Version: Community

Copied from original issue: dotnet/msbuild#3874

[rainersigwald]

Can you clarify what you mean by "the package is still included in the project"?

[rainersigwald]

From @Styxxy on October 23, 2018 21:19

The package is still restored and referenced in the (legacy) project. This doesn't happen for the SDK based project (= correct behaviour). In the sample repository, I referenced the FxCop analyzers, so they are executed on build (while I forced the condition to be false, the package shouldn't be referenced).

Screenshot from Visual Studio (to visualize it a bit):

As you can see, in the old style project the nuget package is added (= faulty behaviour); in the sdk style project the nuget package is not added (= correct behaviour).

[rainersigwald]

I tried this:

diff --git a/LegacyBased/LegacyBased.csproj b/LegacyBased/LegacyBased.csproj
index 5305a2f..573af30 100644
--- a/LegacyBased/LegacyBased.csproj
+++ b/LegacyBased/LegacyBased.csproj
@@ -12,6 +12,7 @@
     <TargetFrameworkVersion>v4.7</TargetFrameworkVersion>
     <FileAlignment>512</FileAlignment>
     <Deterministic>true</Deterministic>
+    <RestoreProjectStyle>PackageReference</RestoreProjectStyle>
   </PropertyGroup>
   <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
     <DebugSymbols>true</DebugSymbols>

And it appears to be working as expected from the command line but still fails in VS.

I think this is related to NuGet's in-VS handling of the restore operation, so I'm going to move the issue to the NuGet repo.

[Styxxy]

@rainersigwald Thanks for moving.

Bigger problem is when the (legacy) project uses still packages.config, this behaviour causes the project to switch of restore method and thus breaking the packages.config references
-> This is not included in the sample repository (but I'll add it in a few hours).

[jainaashish]

This is legacy project system issue since NuGet relies on VSProject4 implementation to provide list of package references and they're the ones who should skip these references based on conditional evaluation. So moved to dotnet/project-system#4175