wpf: PackageReference broken in WPF projects due to tmp_proj not importing Package-supplied build authoring

.NET Core Version: 3.0-preview5
Windows version: Windows 10, 1903
Does the bug reproduce also in WPF for .NET Framework 4.8?: No

Problem description: Trying to use a gRPC service as shown in the AspNetDocs-repo in a WPF app, <UseWPF>true</UseWPF>, results in a build error. Visual Studio and VSCode does not report the problem in intellisense but it appears when doing a dotnet build .sln.

Actual behavior: Results in a

error CS0246: The type or namespace name 'Greet' could not be found (are you missing a using directive or an assembly reference?)

When building. Greet here is the gRPC service defined in a .proto file.

Expected behavior: Build & run with no error.

Minimal repro: I made a repro-repo here.

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 7
Comments: 45 (17 by maintainers)

Commits related to this issue

Get WPF inner-builds to import NuGet packages' imports Workaround for https://github.com/dotnet/wpf/issues/810 — committed to AArnott/Library.Template by AArnott 4 years ago
fixed package for wpf code generation / build process more info: https://github.com/dotnet/wpf/issues/810 — committed to 6bee/aqua-tools by 6bee 3 years ago

Most upvoted comments

Just a note that this is not limited to gRPC only. I have a PackageReference that has some source codes (*.cs files) that I want to include in my project. The files are not picked up (although are shown correctly in the IDE) at compile time.

HEskandari on Jul 3, 2020

The fix is in the .NET 5 SDK, the targets don’t matter.

clairernovotny on Feb 23, 2021

Possible solutions:

Refactor WPF Xaml compilation to avoid tmp_proj generation
When creating tmp_proj, also copy nuget.g.props and nuget.g.targets from source project to corresponding file names for tmp_proj (in the task which creates the tmp_proj)
Run restore on the tmp_proj

dsplaisted on Jun 8, 2020

If indeed this is the issue that will track NuGet/Home#5894 going forward, please update the title of this issue to match the other one or somehow similarly reflect the general problem instead of its current title which suggests a far more limited scope.

AArnott on Jun 1, 2020

@mikkqu and @ccifra: Please see @uecasm’s comment above for the grpc bug and workaround. Thanks.

ryalanms on Jul 9, 2021

I don’t get it, people here mentioning that it’s been fixed, however I still have the original issue (.proto compiled files aren’t included into WPF build) and can’t compile the demo with the latest .NET 5 SDK 2.0.202. IncludePackageReferencesDuringMarkupCompilation property has no effect on my build. The only option left for me is to fallback to creating a class library project and reference it, which looks like a bad practice.

Could someone confirm that it’s actually been fixed?

mikkqu on May 5, 2021

@markrendle @grubioe link to the workaround

gsantopaolo on Oct 22, 2019

The problem for gRPC is that it hooks onto BeforeCompile which is never called in CompileTemporaryAssembly. To solve this, gRPC would have to hook onto CoreCompile, which is called in CompileTemporaryAssembly. A quick workaround would be to add this to the project that uses gRPC: <CoreCompileDependsOn>Protobuf_Compile;$(CoreCompileDependsOn)</CoreCompileDependsOn>.

EDIT: I completely missed the comment by @uecasm who provided the same diagnostic/fix:

The problem seems to be that Grpc.Tools hooks into BeforeCompile, which appears to not be executed for the temporary project.

Hooking it into CoreCompile instead (eg. by defining <CoreCompileDependsOn>$(CoreCompileDependsOn);Protobuf_Compile</CoreCompileDependsOn> in an imported targets file) successfully works around the problem.

ThomasGoulet73 on Jan 4, 2022

This is in .NET 6.0 and .NET 5.0. Thanks.

ryalanms on Aug 26, 2021

We’ve also run into this: https://github.com/dotnet/wpf/issues/3308. It looks like .NET/Roslyn itself has a specific workaround to avoid this:

https://github.com/dotnet/arcade/blob/cbfa29d4e859622ada3d226f90f103f659665d31/src/Microsoft.DotNet.Arcade.Sdk/tools/Workarounds.props#L14. https://github.com/dotnet/arcade/pull/2003/files#diff-da13dd1a6eaacec825fa32a6a7f776bfR7

davkean on Aug 5, 2020

FYI I’m experiencing this same issue on .NET Framework 4.7.2 as well. WPF projects create a temporary project that does not include the Protobuf targets in the build.

The problem seems to be that Grpc.Tools hooks into BeforeCompile, which appears to not be executed for the temporary project.

Hooking it into CoreCompile instead (eg. by defining <CoreCompileDependsOn>$(CoreCompileDependsOn);Protobuf_Compile</CoreCompileDependsOn> in an imported targets file) successfully works around the problem.

uecasm on Feb 19, 2020

@grubioe I’m working on a gRPC e-book for Microsoft Docs and I’ve run into this issue. Since you’ve moved it to the 5.0 milestone, should I document the workaround of using a separate client library in my book for 3.0?

markrendle on Sep 2, 2019