maui: With UseMaui = true in class library I get a '"CopyLocalFilesOutputGroup" does not exist' error

Yeah. 😦 Windows errors are crazy hard to debug. Usually when this happens I check the C++ and CLR check boxes in the Exception Settings window - not perfect, but catches more exceptions (be warned WinUI throws a bit but you have to continue through as they are caught elsewhere):

At this moment I use:

	<UseMaui>true</UseMaui>
	<SingleProject>true</SingleProject>
	<ImplicitUsings>enable</ImplicitUsings>
	<EnablePreviewMsixTooling>true</EnablePreviewMsixTooling>

these are settings in my Windows project. But still no succes, I am getting a little frustrated now. Everything worked till de Release Candidates.

When RC1 was released I had some problems but I fixed them. But since RC2 (when you think it should getting better) the project can not be build.

This does not work if you have a class library that uses only <UseMaui>true</UseMaui> (no platform specific code) and is referenced by a Maui application. The building of the library then fails with

C:\Program Files\dotnet\packs\Microsoft.Maui.Sdk\6.0.300-rc.2.5513\Sdk\WinUI.NetCore.targets(188,5): error MSB4057: The target "CopyLocalFilesOutputGroup" does not exist in the project.

Repro steps:

• Create a Maui Application.
• Add a Maui class library
• Reference the class library from the application
• Modify the csproj of the class library as follows:

<Project Sdk="Microsoft.NET.Sdk">

	<PropertyGroup>
		<TargetFrameworks>net6.0</TargetFrameworks>
		<UseMaui>true</UseMaui>
		<ImplicitUsings>enable</ImplicitUsings>
	</PropertyGroup>

</Project>

Build the project. The build of the library will fail with the above error but only if it is referenced from the main project. If it is not referenced the build succeeds.

I think the fix has simply not in the rc.3 release. As I posted in the MR thread:

The rd.3 release tag is set 12 days ago: https://github.com/dotnet/maui/tags While the MR was merged 10 days ago. https://github.com/dotnet/maui/pull/6767

What was confusing for my is that the actual release of rc.3 is 5 days ago. I assumed it was released from master on that same day but apparently it was released 7 days before. Not sure what happens in those 7 days.

A little more experimentation on a Windows box, and I’ve found that the error only occurs when both of the following are true:

• The MAUI app references a MAUI class library (a class library that has <UseMaui> or <UseMauiCore>)
• The MAUI app uses <TargetFrameworks> instead of <TargetFramework>

It does not seem to matter whether the class library is targeting one or more platforms, or which platform it is. It also doesn’t seem to matter whether the app is targeting Windows or Android or something else - but the build error only occurs when building on Windows.

Maybe this has slipped away. The problem happens under following circumstances:

• Multi Platform Executable; MAUI; Building for Windows
• Single Platform Library; MAUI:

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <RootNamespace>Prism</RootNamespace>
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
    <UseMaui>true</UseMaui>
    <ImplicitUsings>true</ImplicitUsings>
  </PropertyGroup>

Then the problem is reported for each of the libraries that have only the net6.0 target

I had the same problem.

I Started with a single project then I decided to split it into project and library.

It took me some time but close to end I was stuck with the same message …

The problem was that when the library was created it automatically used

$(TargetFrameworks);net6.0-windows10.0.19041.0

while the project was using

$(TargetFrameworks);net6.0-windows10.0.19041

Deleted the .0 then it build and worked fine 😃

Hope it helps 😃

I have been digging some more and there are a few issues that all come together. So the real issue why it is broken is still the fact that the WinUI targets assume the TFM is exactly the same.

However, the one difference before is that the targets used to be located in the WindowsAppSDK nuget, so when the app called a specific target in the library that was NOT winui, it actually fell through to a dummy target. However, due to a few bugs in certain situations, we moved some of the targets from the nuget into MAUI temporarily. This fixes a few issues with resources and packaging, but exposed this issue.

We have a condition now in the targets that was checking if the library was a maui app and a windows TFM, however, because the app lies to us and tells us we are a windows library, it starts down the wrong path.

I have a PR that should make things much better: #6767

But, the current workaround is to make sure you have the windows TFM and then you might also have to set EnablePreviewMsixTooling=True and GenerateLibraryLayout=True.

I believe this is an issue with the Windows App SDK that assumes that the class libraries have the same windows TargetFramework as the app project. It doesn’t do a compatible check.

If the app is net6.0-windows10.0.19041.0, then that tfm must exist exactly in the class library.

It even matters with the last .0 in the version as the app just says get the bits using my tfm.

I think the solution would be to also add the windows tfm to the class library.

I’ll be trying to repro this on a Windows only project and log an issue with them.

I have tried the same, also with IncludeCopyLocalFilesOutputGroup, but that did not change anything for me