-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
With UseMaui = true in class library I get a '"CopyLocalFilesOutputGroup" does not exist' error #6529
Comments
Verified this issue with Visual Studio Enterprise 17.3.0 Preview 1.0 [32414.199.main]. Repro on Windows with above project. |
My project has the same problem but does not use the CommunityToolkit. Is there a workaround known? Thanks in advance |
After I made sure, that ALL MAUI-csproj files had the current settings AND cleaned the solution, the problem went away. I used the following text:
and
I did not touch the rest of the csproj files. Please do not forget to clean the solution. |
This does not work if you have a class library that uses only
Repro steps:
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. |
Can confirm I am seeing the same thing. I'm working on a Nuget package for Maui and I usually test locally by referencing projects, but am getting build errors as described above. |
Try adding I think some defaults are only set when that is set to true as we don't want to start changing things. However, maybe it should so I will use this issue to try and reduce this unexpectedness. I am afk right now, but you can see the 3 props that is set in the SingleProject.props file, the experimental msix, library layout and then another I think. |
@mattleibow |
I have tried the same, also with IncludeCopyLocalFilesOutputGroup, but that did not change anything for me |
I edited my comment as it appears that GitHub took my mobile comment with angle brackets as literal html and removed it. You need to set SingleProject=true |
At this moment I use:
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. |
I can confirm that setting SingleProject=true in both projects (App and Library) does not solve the problem here. |
I have the same problem after upgraded to RC2. However, I resolved this issue after I changed the project file using RC2 project template as below. Please give it a try.
|
Yes, that solves the problem for "normal" MAUI projects. It does not help if you have a project that uses MAUI but no platform specific code. Then the problem persists (see comments above) |
I created all of my MAUI libs from scratch with RC2 and copied the class files over. The CSPROJ is as per shugaoye post. However. I cannot build the main project (i.e. that references the 5 MAUI libraries). 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. C:\Program Files\dotnet\packs\Microsoft.Maui.Sdk\6.0.300-rc.2.5513\Sdk\WinUI.NetCore.targets This happens for two of my 5 MAUI Libs. If I compile them only, then the compile succeeds. Currently dead in the water. :( |
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. |
Thanks for the input. But why did this work before RC2? |
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 |
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 :-) |
That did not work for me. |
Library then project :
|
After some investigation I saw this error in the Event Viewer: Application: exe Does anyone recognize this error? |
No it works fine for me now. The problem I face is that on Mac OS Visual Studio I can only buils with libraries if all of the MAUI type, impossible to build with a pure .Net 6 library :-( |
It WORKS!!! I made a mistake with a compiler directive so the following lines did not get compiled: builder.ConfigureEffects(effects =>
{
effects.AddCompatibilityEffects(AppDomain.CurrentDomain.GetAssemblies());
}); Still a problem with handling errors if an effect can not be found . There was no indication what so ever that pointed to the non-existing effects. |
@mattleibow The associated PR was merged to main six days ago. Yesterday RC.3 was released. I ran 'dotnet workload install maui macos android ios maccatalyst' but the attached solution still results in the same error. Also, I don't see the PR mentioned in the release notes. Is it not expected to be part of RC.3? If not when can we expect it? How can I monitor its release? |
Can you attach/send me a binlog? I am seeing a bunch of issues being reported but I can't reproduce it. |
Just a (very) wild guess here: |
Hi Paul, why you don't create directly a MAUI Library instead, rather than editing the csproject to set MAUI to true ? It worked for me .... |
Below is the binlog of this command: btw, I could not update Visual Studio Preview to it's new version because 'checking for updates' keeps spinning (but I did update the workloads). Also it is crucial to select 'Windows Machine' in visual studio. If I select Android it succeeds. |
Thanks @sailman342 , that way it does indeed compile. The reason I did not do this before is that I was working with an existing project that did compile correctly before. Apart from having a workaround, I think it is good to have a proper understanding of what is going on in the situation reported. |
@mattleibow I can confirm that the problem is still present for a Windows Build on my machine. VS 2022 17.3 Preview 1.0 (english UI) |
Hmmm Is there a difference in the csproj between the one that works and the one that does not? Did you define the |
Maybe this has slipped away. The problem happens under following circumstances:
Then the problem is reported for each of the libraries that have only the net6.0 target |
Does this happen in the IDE or when building on the command line? |
I'm building in the IDE |
I think this should be re-opened. I got the same error building in GitHub Actions. https://github.com/getsentry/sentry-dotnet/runs/6530062417?check_suite_focus=true#step:9:217
This is on a class library that has: <TargetFramework>net6.0</TargetFramework>
<UseMauiCore>true</UseMauiCore> Our library is intended to be used by applications targeting MAUI on any platform. Is there a better way to set that up? This only happens when building on a Windows machine with the |
A little more experimentation on a Windows box, and I've found that the error only occurs when both of the following are true:
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. |
On my machine this also happens with |
I think the fix has simply not in the rc.3 release. As I posted in the MR thread:
|
Indeed, after updating to today's GA release, this issue appears resolved. Thanks! |
Yes, I can confirm that, too. It is fixed in the GA code. Thanks a lot. |
Description
When I create a class library for reusable maui components and add
<UseMaui>true</UseMaui>
to the csproj I get this error: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. C:\Program Files\dotnet\packs\Microsoft.Maui.Sdk\6.0.300-rc.2.5513\Sdk\WinUI.NetCore.targets
Used rc2 and VS preview 5
I am not sure if I am supposed to use
<UseMaui>true</UseMaui>
for this purpose. I would like to know the alternative way if there is one. Still there may have to be a better error in this situation.Screenshot of the situation:
Minimal reproduction:
CopyLocalFilesOutputGroup-does-not-exist.zip
Steps to Reproduce
Version with bug
Release Candidate 2
Last version that worked well
Unknown/Other
Affected platforms
Windows
Affected platform versions
It is a compile problem so I guess it affects all platforms with RC 2. I compiled on Windows.
Did you find any workaround?
No
Relevant log output
The text was updated successfully, but these errors were encountered: