Microsoft.NETFramework.ReferenceAssemblies Framework resolution in WPF temporary project

[KeRNeLith]

Hello,

I was trying to use the Microsoft.NETFramework.ReferenceAssemblies package in a solution to be able to retrieve the .NET Framework from package.

So I basically took the example from this page.

I tried on my machine to use the package to build an application targetting .NET Framework 4.8, which developer pack is not installed on my machine on purpose.

So I put the package on some WPF application project because that's what I tried to achieve and noticed that is was not working. I got the message:

I created a solution (ReferenceAssembliesBug.zip) that showcase the problem which is attached. I put in it a ClassLibrary, a ConsoleApp and a WPFApp. The ClassLibrary and the ConsoleApp are compiling well with the same setup, only the WPFApp does not work.

I used the MSBuild Structured Log Viewer (v2.1.117) in order to try explain why it is not working.

If run on the solution we get an interesting result. I will forget the case of the ClassLibrary, and focus on Console and WPF apps.
So for the ConsoleApp I had a look at the Target GetReferenceAssemblyPaths. :

We can notice there that it explain why it is working because the resolved path is indeed the one of my NuGet cache.

Now for the WPFApp it is not the same:

We can notice in this case that the WPFApp is using a temporary project (I'm not really knowing why but I imagine it is something done when using WPF and the Microsoft.NET.Sdk.WindowsDesktop), and there the resolution of reference assemblies is failing. It seems that the project did not get the behavior we have when doing Console application.

So I don't know how to workaround this but this make this package unusable for WPF projects.

Furthermore, I'm not sure the problem is limited to the usage of this package but maybe is a more general bug.

[jairbubbles]

@KeRNeLith Have you checked if the issue is still present with .NET 5 Preview 3 ?

[jairbubbles]

@rainersigwald Do you know where the tmp WPF project generation is done? I'm not sure if it should go to WPF or MsBuild.

[KeRNeLith]

@KeRNeLith Have you checked if the issue is still present with .NET 5 Preview 3 ?

I didn't check with the .NET 5 preview, and I'm not sure I can do such test for now. If you have the setup for this, maybe you can pick the sample solution I sent to check it out?

EDIT: wrong closing manipulation.

[rainersigwald]

@dsplaisted is this expected to be supported?

[dsplaisted]

It looks like the problem is that the WPF temporary project doesn't import .props or .targets files from NuGet packages, which is how the reference assembly packages work.

I think this would need to be a fix in https://github.com/dotnet/wpf.

So I would move this issue there, but the issue mover tools I have don't seem to support this for me. FYI @vatsan-madhavan @rladuca

[vatsan-madhavan]

@fabiant3, @microsoft/wpf-developers fyi.

[KeRNeLith]

Is there any news on this?

[aelij]

Here's a workaround. Note it assumes the name of the directory and the name of the project are the same (e.g. Foo/Foo.csproj).

In Directory.Build.props:

  <PropertyGroup>
    <NuGetPrefix>$(MSBuildProjectDirectory)/obj/$([System.IO.Path]::GetFileName($(MSBuildProjectDirectory)))$(MSBuildProjectExtension)</NuGetPrefix>
    <NuGetProps>$(NuGetPrefix).nuget.g.props</NuGetProps>
    <NuGetTargets>$(NuGetPrefix).nuget.g.targets</NuGetTargets>
  </PropertyGroup>

  <Import Condition=" $(MSBuildProjectName.Contains('wpftmp')) and Exists('$(NuGetProps)') " Project="$(NuGetProps)" />

In Directory.Build.targets:

  <Import Condition=" $(MSBuildProjectName.Contains('wpftmp')) and Exists('$(NuGetTargets)') " Project="$(NuGetTargets)" />

[dsplaisted]

I believe the root issue that props and targets aren't imported from NuGet packages for the WPF temporary project has been fixed. @ryalanms

[aelij]

@dsplaisted has this fix been released? I encountered this issue in the latest SDK, v5.0.302.

[dsplaisted]

@ryalanms @microsoft/wpf-developers What's the status of IncludePackageReferencesDuringMarkupCompilation?

Some related links:

dotnet/wpf#810
dotnet/sdk#15395
dotnet/sdk#15790

[ryalanms]

The attached repro project ReferenceAssembliesBug.zip compiles successfully on .NET 6.0 rc1.

@ryalanms @microsoft/wpf-developers What's the status of IncludePackageReferencesDuringMarkupCompilation?

The default behavior for WPF in .NET 6.0 is to include the PackageReferences and import their props and targets files. The property IncludePackageReferencesDuringMarkupCompilation needs to be set to get the same behavior in .NET 5.0. (It is not supported in 3.1.)

[KirillOsenkov]

If you're targeting .NET Framework, the workaround is to add this to the beginning and end of your .csproj:

at the beginning:

  <PropertyGroup>
    <!--
    This is needed to make sure Microsoft.NETFramework.ReferenceAssemblies net47 gets picked up
    by WPF markup compilation (GenerateTemporaryTargetAssembly task).
    Microsoft.NETFramework.ReferenceAssemblies.net47.targets gets inserted before TargetFrameworkIdentifier
    is set.
    -->
    <TargetFrameworkIdentifier>.NETFramework</TargetFrameworkIdentifier>
    <TargetFrameworkVersion>v4.7</TargetFrameworkVersion>
    <MainProjectNuGetGProps>$(BaseIntermediateOutputPath)$(_TargetAssemblyProjectName)$(MSBuildProjectExtension).nuget.g.props</MainProjectNuGetGProps>
    <MainProjectNuGetGTargets>$(BaseIntermediateOutputPath)$(_TargetAssemblyProjectName)$(MSBuildProjectExtension).nuget.g.targets</MainProjectNuGetGTargets>
  </PropertyGroup>

  <Import Project="$(MainProjectNuGetGProps)"
          Condition="$(_TargetAssemblyProjectName) != '' and $(ImportProjectExtensionProps) != false and Exists('$(MainProjectNuGetGProps)')" />

at the end:

  <Import Project="$(MainProjectNuGetGTargets)"
          Condition="$(_TargetAssemblyProjectName) != '' and $(ImportProjectExtensionTargets) != false and Exists('$(MainProjectNuGetGTargets)')" />