WPF project with AutoGenerateBindingRedirects enabled produces MSB3277

[asmichi]

WPF project with AutoGenerateBindingRedirects enabled produces a MSB3277 warning, which is a similar issue to https://github.com/dotnet/corefx/issues/40012#issuecomment-522209519:

C:\Program Files\dotnet\sdk\3.0.100-preview9-013908\Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3277: Found conflicts between different versions of "System.IO.Pipes.AccessControl" that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed.

I started to get this MSB3277 warning after migrating my WPF project from 3.0 preview 7 to 3.0 preview 9.

Workaround

Disable AutoGenerateBindingRedirects when targeting netcoreapp. Normally you do not need it on .NET Core.

Steps to reproduce

dotnet build the following project: WpfApp.zip

or

dotnet new global.json --sdk-version "3.0.100-preview9-014004"
dotnet new wpf -f netcoreapp3.0 --name WpfApp --output .
* Add <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> to WpfApp.csproj *
dotnet build

Expected behavior

No warning.

Actual behavior

Build generates an MSB3277 warning.

.NET Core 向け Microsoft (R) Build Engine バージョン 16.3.0-preview-19426-01+faf5e5d75
Copyright (C) Microsoft Corporation.All rights reserved.

  C:\tmp\a\WpfApp.csproj の復元が 14.68 ms で完了しました。
  You are using a preview version of .NET Core. See: https://aka.ms/dotnet-core-preview
C:\Program Files\dotnet\sdk\3.0.100-preview9-014004\Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3277: "System.IO.Pipes.AccessControl" の異なるバージョン間で、解決できない競合が見つかりました。これらの参照上の競合は、ログの詳細度が詳細に設定されている場合にビルド ログにリストされます。 [C:\tmp\a\WpfApp.csproj]
  WpfApp -> C:\tmp\a\bin\Debug\netcoreapp3.0\WpfApp.dll

ビルドに成功しました。

Environment data

• .NET Core SDK 3.0.100-preview9-014004
• Windows 10 Pro 1903 (18362.295)

Notes

• The detailed-level log states that C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\3.0.0-preview9-19423-09\ref\netcoreapp3.0\System.IO.Pipes.AccessControl.dll is 4.0.3.0 while C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\3.0.0-preview9-19423-09\ref\netcoreapp3.0\System.Core.dll references 4.0.4.0.

  "System.IO.Pipes.AccessControl, Version=4.0.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" と "System.IO.Pipes.AccessControl, Version=4.0.4.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" の間で競合が発生しました。
  ...

• System.IO.Pipes.AccessControl, Version=4.0.3.0 is the one published at https://www.nuget.org/packages/System.IO.Pipes.AccessControl/4.5.1.
• System.IO.Pipes.AccessControl, Version=4.0.4.0 is not publicly published as a NuGet package.

[asmichi]

I fixed my actual project by disabling AutoGenerateBindingRedirects when the TFM is netcoreapp3.0 because I do not need it on .NET Core anyway. However, something looks wrong.

[dagood]

@vatsan-madhavan, @ericstj, any ideas?

The manifests in the 3.0 preview 9 packages seem to match up with this note:

• The detailed-level log states that
  C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\3.0.0-preview9-19423-09\ref\netcoreapp3.0\System.IO.Pipes.AccessControl.dll
  is 4.0.3.0 while
  C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\3.0.0-preview9-19423-09\ref\netcoreapp3.0\System.Core.dll
  references 4.0.4.0.

  "System.IO.Pipes.AccessControl, Version=4.0.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" と "System.IO.Pipes.AccessControl, Version=4.0.4.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" の間で競合が発生しました。
  ...

netcoreapp:

PlatformManifest
System.IO.Pipes.AccessControl.dll|Microsoft.NETCore.App.Runtime.win-x64|4.0.4.0|4.700.19.42104

RuntimeList:
<File Type="Managed" Path="runtimes/win-x64/lib/netcoreapp3.0/System.IO.Pipes.AccessControl.dll" AssemblyName="System.IO.Pipes.AccessControl" PublicKeyToken="b03f5f7f11d50a3a" AssemblyVersion="4.0.4.0" FileVersion="4.700.19.42104" />

windowsdesktop:

FrameworkList:
<File Type="Managed" Path="ref/netcoreapp3.0/System.IO.Pipes.AccessControl.dll" AssemblyName="System.IO.Pipes.AccessControl" PublicKeyToken="b03f5f7f11d50a3a" AssemblyVersion="4.0.3.0" FileVersion="4.6.26606.5" Profile="WindowsForms;WPF" />

Did Core-Setup miss an update? Did CoreFX not mark the package to service properly?

[ericstj]

The version differences are due to dotnet/corefx@4e76a6c which removed the package. Now the reference assembly is built in CoreFx and not shipped anywhere, but is a seed for the desktop facades. In the past we used assembly-rewriting to 0.0.0.0-out all the references from these facades, but now in 3.0 they reference the exact version. The fix here would be to freeze the reference assembly to the version that was shipped in the package. That should have been done when the package was removed.

Alternatively we could decide to add this assembly (and its closure) to the shared framework in 5.0. The implementation is already part of the shared framework, we're just not exposing the references since it doesn't make sense to do so on unix since this API is not supported there.

I'll move this to corefx.

[ericstj]

We should see if this means that you cannot use a desktop library that exposes types in this assembly. If so, this may meet the bar for 3.0 / 3.1. The types forwarded in this assembly are PipeSecurity, PipesAclExtensions, PipeAuditRule, PipeAccessRule, PipeAccessRights.

[ericstj]

Looks like the compiler is permitting this, so it is not a blocking issue, however we should clean this up in 5.0.

[rladuca]

@ericstj I just hit this in WPF's test repository when trying to flow 3.1 bits and build off of them.

If you clone this branch and then build you should hit this issue. Building the below project is sufficient.

build -project {full path to repo}\src\test\Common\CompilerServices\CompilerServices.csproj

FYI @vatsan-madhavan

[ericstj]

Yep we understand the issue and it’s not blocking. Setting AutoGeneratBindingRedirects isn’t even relevant for .NetCoreApp projects. You can work around the warning by conditioning that property to only be set for desktop TargetFrameworks.

We’ll fix up the warning in 5.0.

If you’re hitting this warning without setting AutoGenerateBindingRedirects then open a new issue.

[ericstj]

@Anipik since you are touching versions of these assemblies in 3.1 can you address this here?

[rladuca]

@ericstj In our case, we're using the Microsoft.Build.Locator package which includes a props file that sets AutoGenerateBindingRedirects to true. I'll play around with overriding this and see if it causes any issues, thanks!

[asmichi]

Added the workaround to the summary. (Please feel free to edit further!)

[danmoseley]

@Anipik is this still a 3.x issue? I don't know why your PR above didn't resolve it since it says "fixes dotnet/corefx#40978".

Although reading above it sounds like there's work for 5.0 so this should stay open?

[Anipik]

yes we need to port the change it to 5.0 as well. i will do that.