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

[rainersigwald]

This was filed as microsoft/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

[pranavkm]

Fixed in https://github.com/aspnet/AspNetCore-Tooling/commit/43776c1864780c87435a8ae85cf2877658238079

[miloush]

If I am to migrate some of the web applications into core, I would also need to call WPF stuff. Is the suggested way just to reference the assemblies, or has the fact that WPF is now running on .NET Core 3.0 changed things? Is there a "Framework" to add to the project? I tried to put <UseWPF> property into the project file but was told it's not supported in the current SDK (it is a bit unclear to me though how much is that needed).

[LeeDumond]

@miloush
I have a little app here in Github that might help.

https://github.com/LeeDumond/Ais.ImageSplitterCore3

It demonstrates the use of WPF Desktop APIs in .NET Core 3, and how to reference them from an ASP.NET Core 3 project. It's on Preview 6 or 7 still I think, I need to update it when I have time...

[miloush]

Thanks Lee, that seems to be through another library, I am looking for options of referencing directly from the ASP.NET Core project. Adding assembly references seems to compile, I was just wondering whether there is e.g. a FrameworkReference I should add rather than individual assemblies.