Stack Overflow in ReferenceResolver.cs when web project references WPF library

[rainersigwald]

This was filed as dotnet/msbuild#4560, but the proximate cause of the failure is here, as described below.

Describe the bug

Using .NET Core SDK 3.0.100-preview7, when a web project references a library that uses WPF, the build fails with a stack overflow (and very little information).

To Reproduce

msbuild4560.zip

Steps to reproduce the behavior:

1. Using .NET Core SDK 3.0.0-preview8-27919-09 (also reported on public preview7)
2. Build the attached zip with dotnet build WebApp\WebApp.csproj

$ dotnet build
Microsoft (R) Build Engine version 16.3.0-preview-19369-03+db6ae5a0d for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 84.2 ms for S:\repro\microsoft\msbuild\issues\4560\WebApp\WebApp.csproj.
  You are using a preview version of .NET Core. See: https://aka.ms/dotnet-core-preview
  LibWithWpf -> S:\repro\microsoft\msbuild\issues\4560\LibWithWpf\bin\Debug\netcoreapp3.0\LibWithWpf.dll
Stack overflow.

Expected behavior

Successful build or actionable error.

Additional context

I caught this in the debugger and found that it's recursing at

https://github.com/aspnet/AspNetCore-Tooling/blob/7c5826c2abfe90e20acc3715cf9e939db1b1a442/src/Razor/src/Microsoft.NET.Sdk.Razor/ReferenceResolver.cs#L89

I added a tracepoint to indicate what is being resolved and got this: https://gist.github.com/rainersigwald/791d5ead4580da117f55886cfd1e6bd8

The tail end of that log points out the problem, I think: ReachFramework.dll depends on PresentationFramework.dll depends on ReachFramework.dll in a cycle.

[blowdart]

Out of interest what do you need to do on a server that requires WPF? Nothing really changed with regards to GDI etc in Core, it's still something we say is a nope.

[rainersigwald]

Guessing @pranavkm is the right person here based on the edit history of that file.

Looks like ReferenceResolver.Resolve needs to become tolerant of circular references.

While I was in there, I noticed a lot of repetition of looking at, say, netstandard.dll. It might be worth considering caching lookups, perhaps using a depth-first search and caching lookups at each level. But that's somewhat orthogonal to this problem.

[rainersigwald]

@blowdart from the OP by @peter-bull:

I have a project which has a shared Class Library Project that uses the Windows Desktop SDK, this library which is used by a WPF Desktop Project (to offer desktop based ui but with functionality in core class library) and a ASP.NET Core Project (to offer web-based ui but re-used all other functionality)

(also cc @LeeDumond from the MSBuild issue)

[pranavkm]

Thanks @rainersigwald. @peter-bull while we resolve this bug, you could workaround the issue by disabling the feature. Here's what you need to set in your project file:

<PropertyGroup>
    <GenerateMvcApplicationPartsAssemblyAttributes>false</GenerateMvcApplicationPartsAssemblyAttributes>
</PropertyGroup>

in your project

[LeeDumond]

Out of interest what do you need to do on a server that requires WPF? Nothing really changed with regards to GDI etc in Core, it's still something we say is a nope.

@blowdart In my case, we are building a little utility API that splits multipage TIF files. We are using a WPF project to access the decoding/encoding functionality form the System.Windows.Media.Imaging namespace, and referencing that from a .NET Core Web API project.

[LeeDumond]

Thanks @rainersigwald. @peter-bull while we resolve this bug, you could workaround the issue by disabling the feature. Here's what you need to set in your project file:

<PropertyGroup>
    <GenerateMvcApplicationPartsAssemblyAttributes>false</GenerateMvcApplicationPartsAssemblyAttributes>
</PropertyGroup>

in your project

Yes this definitely worked for me :)

[peter-bull]

I can confirm that using that setting "GenerateMvcApplicationPartsAssemblyAttributes" also worked for me, thanks for a solution for now and a resolution in the near future