WindowsAppSDK
WindowsAppSDK copied to clipboard
Build error APPX1101 (.NET 6 WinUI 3 and Microsoft.EntityFramework.Tools)
Describe the bug
When building my app, I get this error:
APPX1101 Payload contains two or more files with the same destination path 'App4.deps.json'. Source files: C:\Users\bluve\source\repos\App4\App4\obj\x86\Debug\net6.0-windows10.0.19041.0\win10-x86\App4.deps.json C:\Users\bluve\source\repos\App4\App4\bin\x86\Debug\net6.0-windows10.0.19041.0\win10-x86\App4.deps.json App4 C:\Users\bluve.nuget\packages\microsoft.windowsappsdk\1.0.0\build\Microsoft.Build.Msix.Packaging.targets 1370
Steps to reproduce the bug
- Create a WinUI 3 app.
- Add Microsoft.EntityFrameworkCore.Tools 6.0.0 from NuGet.
- Run the app.
Expected behavior
No response
Screenshots
No response
NuGet package version
1.0.0
Packaging type
Packaged (MSIX)
Windows version
May 2021 Update (19043)
IDE
Visual Studio 2022
Additional context
No response
Thanks @BluVeneziano, we're working with the EntityFrameworkCore team to investigate this, we'll update you when we have figured out more!
This is stopping my development in WINUI 3. This has had no forward motion since Nov. of last year. Has there been an update?
@andrewleader is there any progress on this bug? I am having the same error on a WinUi 3 WPF app
@adixon501 @hachadwick To unblock you for now, open your .csproj and make the changes indicated below.
+ <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="6.0.1" />
- <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="6.0.1">
- <PrivateAssets>all</PrivateAssets>
- <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
- </PackageReference>
@andrewleader Seems all <developmentDependency>true</developmentDependency> packages are affected. (It appears to be related to the explicit runtime asset include (i.e. <IncludeAssets>runtime; ...</IncludeAssets>)). Not sure why but perhaps a useful hint.
wow, that did the trick. @riverar I sure appreciate the help!
I'm also having this problem. However, I added Microsoft.EntityFrameworkCore.Design 6.0.1 instead of Tools from GitHub.
@andrewleader
Could you clarify if this issue or the newly created one under WinUI should be used for this problem:
microsoft/WindowsAppSDK#2237
EF Core team stated it is a WinUI issue.
https://github.com/dotnet/efcore/issues/27576#issuecomment-1064304575
I no longer work on WinAppSdk, @mikebattista would you be the right person to help with the question above?
I created https://task.ms/38479087 to track this. We'll take a look.
@mikebattista This issue was supposedly already being tracked internally:
https://github.com/dotnet/efcore/issues/26973#issuecomment-993885102
https://github.com/dotnet/efcore/issues/27576#issuecomment-1064304575
I was just trying to prevent it from being duplicated in both the WinUI and WindowsAppSDK repos:
microsoft/WindowsAppSDK#2237
Confirmed still reproes with latest internal builds.
Commenting that while the .csproj lines cited by @riverar also occur in libraries ("Class Library (WinUI 3 in Desktop)" template), the compile error only occurs for the app, not the libraries.
Does anything on this turd known as WinUI 3 actually work as it's supposed too? Is it safe to say this shouldn't have been released in the state it's in? 6 months and EF Core still doesn't work, still no designer, figured out today that it can't even detect circular dependency injection which was why my app wouldn't launch, WinUI is the future is it?!? Sticking with WPF
I’ve tracked down the task invocations responsible for generating the two differing deps.json files. They are both calls to GenerateDepsFile in C:\Program Files\dotnet\sdk\6.0.203\Sdks\Microsoft.NET.Sdk\targets..\tools\net472\Microsoft.NET.Build.Tasks.dll.
The first file to be generated is the deps.json under the bin folder. That comes from target GenerateBuildDependencyFile, with this dependency chain:
- GenerateBuildDependencyFile (Microsoft.NET.sdk.targets; .NET SDK)
- CopyFilesToOutputDirectory (Microsoft.Common.CurrentVersion.targets; VS)
- GenerateProjectPriFile (Microsoft.Build.Msix.Pri.targets; WinAppSDK Nuget)
- PrepareForRun
The second file to be generated is the deps.json under the obj folder. That comes from target GeneratePublishDependencyFile, with this dependency chain:
- GeneratePublishDependencyFile (Microsoft.NET.Publish.targets; .NET SDK)
- ComputeFilesToPublish (Microsoft.NET.Publish.targets; .NET SDK)
- __GetPublishItems (Microsoft.Build.Msix.Packaging.targets; WinAppSDK Nuget)
- GetPackagingOutputs (Microsoft.Build.Msix.Packaging.targets; WinAppSDK Nuget)
- PrepareMsixPackage
The supplied parameters are almost identical. Aside from the output file being different, there are two differences:
- In GenerateBuildDependencyFile, the parameter ResolvedNuGetFiles contains a bunch of dlls that come from EntityFramework-related packages. In GeneratePublishDependencyFile, those files are absent, because this target filters out items that have “CopyToPublishDirectory” set to “False”. This seems to be related to the EntityFramework package using DevelopmentDependency and the explicit runtime asset used in PackageReference as mentioned by Rafael Rivera in this comment https://github.com/microsoft/WindowsAppSDK/issues/1856#issuecomment-1006882973
- The parameter “IsSingleFile” is not set for GenerateBuildDependencyFile, but it is set and defaults to “False” in GeneratePublishDependencyFile.
I suspect it’s mostly the first difference to blame here, based on this line in the GenerateDepsFile task that adds ResolvedNuGetFiles to ResolvedRuntimeTargetsFiles.
Handing over further investigation to @evelynwu-msft
see workarround: https://github.com/microsoft/WindowsAppSDK/issues/2524#issuecomment-1129733373
Hello, we are trying to migrate a Xamarin App to MAUI. We don't use entity Framework and are running into the exact same problem of two <App>.deps.json files being generated. Is there any progress in this matter or a workaround I could use?
@rxDietel Fix is coming in 1.2. For workarounds there are two possibilities: https://github.com/microsoft/WindowsAppSDK/issues/1856#issuecomment-1006882973 https://github.com/microsoft/WindowsAppSDK/issues/2524#issuecomment-1129733373 Please follow up if neither of these work for you.
I'm hitting this over and over today as well with my maui app. This is a bit of showstopper as I keep not being able to build and run my apps. I'm not using entity framework. This is a fairly vanilla maui app with a few simple project references: https://github.com/Esri/arcgis-toolkit-dotnet/blob/754d62a66fff9245cbd825f656cde5a0d74a65ff/src/Samples/Toolkit.SampleApp.Maui/Toolkit.SampleApp.Maui.csproj
Fix is checked in and will ship with 1.2
Getting rid of privateassets="all" from the package ref worked for me
Reopening until @BluVeneziano and other customers can confirm the fix, which will be available in WinAppSDK 1.2 Preview 2. In the meantime, here is a workaround to drop into your csproj or directory.build.targets:
<Target Name="RemoveCollidingDepsJson" AfterTargets="GetPackagingOutputs" BeforeTargets="_ComputeAppxPackagePayload">
<!-- If conflicting build and publish deps.json files are present, use only the publish deps.json,
and remove the corresponding build deps.json. -->
<ItemGroup Condition="'@(PackagingOutputs)'!=''" >
<_PublishDepsJson Include="@(PackagingOutputs->WithMetadataValue('OutputGroup', 'PublishItemsOutputGroupOutput'))"
Condition="'$([System.String]::Copy(%(FileName)%(Extension)).EndsWith('.deps.json'))" />
<_BuildDepsJson Include="@(PackagingOutputs->WithMetadataValue('OutputGroup', 'GetCopyToOutputDirectoryItemsOutputGroup'))"
Condition="'$([System.String]::Copy(%(FileName)%(Extension)).EndsWith('.deps.json'))" />
<PackagingOutputs Condition="'@(_PublishDepsJson)'!='' and '@(_BuildDepsJson)'!=''" Remove="@(_BuildDepsJson)"/>
</ItemGroup>
</Target>
@Scottj1s Hi. I placed your above code in my Maui csproj file just above the </Project> tag but I still get the same error.
Do I have it in the right spot? Thanks.
@julianadormon I'd recommend updating to WindowsAppSDK 1.2 Preview 2, which contains this fix. If that would prevent you from publishing to the store, then you can produce a binlog and examine it with the https://msbuildlog.com/ tool to ensure that the RemoveCollidingDepsJson target above is executing correctly.
I'm getting syntax errors on that Target, on the two String.Copy lines. I fixed it by removing the single quote at the front of it (in Condition="'$([System.String] ...), and adding single quotes to the Copy call (in ::Copy(%(FileName)%(Extension)))
<Target Name="RemoveCollidingDepsJson" AfterTargets="GetPackagingOutputs" BeforeTargets="_ComputeAppxPackagePayload">
<!-- If conflicting build and publish deps.json files are present, use only the publish deps.json,
and remove the corresponding build deps.json. -->
<ItemGroup Condition="'@(PackagingOutputs)'!=''" >
<_PublishDepsJson Include="@(PackagingOutputs->WithMetadataValue('OutputGroup', 'PublishItemsOutputGroupOutput'))"
Condition="$([System.String]::Copy('%(FileName)%(Extension)').EndsWith('.deps.json'))" />
<_BuildDepsJson Include="@(PackagingOutputs->WithMetadataValue('OutputGroup', 'GetCopyToOutputDirectoryItemsOutputGroup'))"
Condition="$([System.String]::Copy('%(FileName)%(Extension)').EndsWith('.deps.json'))" />
<PackagingOutputs Condition="'@(_PublishDepsJson)'!='' and '@(_BuildDepsJson)'!=''" Remove="@(_BuildDepsJson)"/>
</ItemGroup>
</Target>
This is still a problem, the standard templates still result in two deps.json as of today.
I'm getting syntax errors on that Target, on the two String.Copy lines. I fixed it by removing the single quote at the front of it (in
Condition="'$([System.String] ...), and adding single quotes to the Copy call (in::Copy(%(FileName)%(Extension)))<Target Name="RemoveCollidingDepsJson" AfterTargets="GetPackagingOutputs" BeforeTargets="_ComputeAppxPackagePayload"> <!-- If conflicting build and publish deps.json files are present, use only the publish deps.json, and remove the corresponding build deps.json. --> <ItemGroup Condition="'@(PackagingOutputs)'!=''" > <_PublishDepsJson Include="@(PackagingOutputs->WithMetadataValue('OutputGroup', 'PublishItemsOutputGroupOutput'))" Condition="$([System.String]::Copy('%(FileName)%(Extension)').EndsWith('.deps.json'))" /> <_BuildDepsJson Include="@(PackagingOutputs->WithMetadataValue('OutputGroup', 'GetCopyToOutputDirectoryItemsOutputGroup'))" Condition="$([System.String]::Copy('%(FileName)%(Extension)').EndsWith('.deps.json'))" /> <PackagingOutputs Condition="'@(_PublishDepsJson)'!='' and '@(_BuildDepsJson)'!=''" Remove="@(_BuildDepsJson)"/> </ItemGroup> </Target>
Thank you @Scottj1s and @MikeHillberg. Had the same problem with Microsoft.Web.WebView2.Core.dll
I'm getting syntax errors on that Target, on the two String.Copy lines. I fixed it by removing the single quote at the front of it (in
Condition="'$([System.String] ...), and adding single quotes to the Copy call (in::Copy(%(FileName)%(Extension)))<Target Name="RemoveCollidingDepsJson" AfterTargets="GetPackagingOutputs" BeforeTargets="_ComputeAppxPackagePayload"> <!-- If conflicting build and publish deps.json files are present, use only the publish deps.json, and remove the corresponding build deps.json. --> <ItemGroup Condition="'@(PackagingOutputs)'!=''" > <_PublishDepsJson Include="@(PackagingOutputs->WithMetadataValue('OutputGroup', 'PublishItemsOutputGroupOutput'))" Condition="$([System.String]::Copy('%(FileName)%(Extension)').EndsWith('.deps.json'))" /> <_BuildDepsJson Include="@(PackagingOutputs->WithMetadataValue('OutputGroup', 'GetCopyToOutputDirectoryItemsOutputGroup'))" Condition="$([System.String]::Copy('%(FileName)%(Extension)').EndsWith('.deps.json'))" /> <PackagingOutputs Condition="'@(_PublishDepsJson)'!='' and '@(_BuildDepsJson)'!=''" Remove="@(_BuildDepsJson)"/> </ItemGroup> </Target>Thank you @Scottj1s and @MikeHillberg. Had the same problem with Microsoft.Web.WebView2.Core.dll
@fabiocannas How did you fix the Microsoft.Web.WebView2.Core.dll?
How was this closed? It is still an issue, latest SDK, latest VS updates, latest everything. Been having a really poor experience with WinUI3 thus far.
@mjfara, sorry you're still having trouble. Are you seeing the same issue as reported here, with a duplicate deps.json file specifically? There were a few similar scenarios, which were addressed in the latest release, 1.3 Preview 1.
This should not be closed