Runtime: WPF project with AutoGenerateBindingRedirects enabled produces MSB3277

Created on 10 Sep 2019  ·  12Comments  ·  Source: dotnet/runtime

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.
area-System.IO
Source
picture asmichi
👍1

Most helpful comment

The version differences are due to https://github.com/dotnet/corefx/commit/4e76a6c02552422ce07967f4249acad3b71b80ef 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.

picture ericstj on 10 Sep 2019
👍2

All 12 comments

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.

asmichi picture asmichi on 10 Sep 2019

@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:

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?

dagood picture dagood on 10 Sep 2019

The version differences are due to https://github.com/dotnet/corefx/commit/4e76a6c02552422ce07967f4249acad3b71b80ef 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 picture ericstj on 10 Sep 2019
👍2

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 picture ericstj on 10 Sep 2019

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

ericstj picture ericstj on 10 Sep 2019

@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

rladuca picture rladuca on 17 Sep 2019

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 picture ericstj on 17 Sep 2019

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

ericstj picture ericstj on 17 Sep 2019

@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!

rladuca picture rladuca on 17 Sep 2019

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

asmichi picture asmichi on 21 Sep 2019

@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?

danmosemsft picture danmosemsft on 1 Oct 2019

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

Anipik picture Anipik on 1 Oct 2019
👍1
Was this page helpful?
0 / 5 - 0 ratings

Related issues

iCodeWebApps picture iCodeWebApps  ·  3Comments
sahithreddyk picture sahithreddyk  ·  3Comments
yahorsi picture yahorsi  ·  3Comments
EgorBo picture EgorBo  ·  3Comments
GitAntoinee picture GitAntoinee  ·  3Comments