Build error APPX1101 (.NET 6 WinUI 3 and Microsoft.EntityFramework.Tools)

[BluVeneziano]

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

1. Create a WinUI 3 app.
2. Add Microsoft.EntityFrameworkCore.Tools 6.0.0 from NuGet.
3. 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

[andrewleader]

Thanks @BluVeneziano, we're working with the EntityFrameworkCore team to investigate this, we'll update you when we have figured out more!

[hachadwick]

This is stopping my development in WINUI 3. This has had no forward motion since Nov. of last year. Has there been an update?

[adixon501]

@andrewleader is there any progress on this bug? I am having the same error on a WinUi 3 WPF app

[riverar]

@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.

[hachadwick]

wow, that did the trick. @riverar I sure appreciate the help!

[scott-moxham]

I'm also having this problem.
However, I added Microsoft.EntityFrameworkCore.Design 6.0.1 instead of Tools from GitHub.

[kmgallahan]

@andrewleader

Could you clarify if this issue or the newly created one under WinUI should be used for this problem:

#2237

EF Core team stated it is a WinUI issue.

dotnet/efcore#27576 (comment)

[andrewleader]

I no longer work on WinAppSdk, @mikebattista would you be the right person to help with the question above?

[mikebattista]

I created https://task.ms/38479087 to track this. We'll take a look.

[kmgallahan]

@mikebattista This issue was supposedly already being tracked internally:

dotnet/efcore#26973 (comment)

dotnet/efcore#27576 (comment)

I was just trying to prevent it from being duplicated in both the WinUI and WindowsAppSDK repos:

#2237

[mikebattista]

Confirmed still reproes with latest internal builds.

[sjb-sjb]

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.

[Marren85]

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

[DefaultRyan]

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 Build error APPX1101 (.NET 6 WinUI 3 and Microsoft.EntityFramework.Tools)  #1856 (comment)
• 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

[Ika59]

see workarround: #2524 (comment)

[rxDietel]

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 .deps.json files being generated.
Is there any progress in this matter or a workaround I could use?

[EricJohnson327]

@rxDietel Fix is coming in 1.2. For workarounds there are two possibilities: #1856 (comment)
#2524 (comment)
Please follow up if neither of these work for you.

[dotMorten]

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

[julianadormon]

@Scottj1s Hi.
I placed your above code in my Maui csproj file just above the tag but I still get the same error.

Do I have it in the right spot? Thanks.

[Scottj1s]

@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.

[MikeHillberg]

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>

[sjb-sjb]

This is still a problem, the standard templates still result in two deps.json as of today.

[fabiocannas]

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

[timseverson]

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?

[mjfara]

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.

[Scottj1s]

@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.

[HakamFostok]

This should not be closed

[Jimex]

I encountered a similar issue while compiling my app with .NET 8, WINUI 3, and Native AOT. Unfortunately, the workaround mentioned above did not resolve the issue in this case either.

2>D:\AppCache.nuget\microsoft.windowsappsdk\1.4.231008000\buildTransitive\Microsoft.Build.Msix.Packaging.targets(1500,5): error APPX1101: Payload contains two or more files with the same destination path 'DictTango.exe'. Source files:
2>D:\AppCache.nuget\microsoft.windowsappsdk\1.4.231008000\buildTransitive\Microsoft.Build.Msix.Packaging.targets(1500,5): error APPX1101: E:\Work\Development\Android\DictTango\DotnetSrc\DictTango\DictTangoWinUI\obj\x64\Release\net8.0-windows10.0.19041.0\win-x64\apphost.exe
2>D:\AppCache.nuget\microsoft.windowsappsdk\1.4.231008000\buildTransitive\Microsoft.Build.Msix.Packaging.targets(1500,5): error APPX1101: E:\Work\Development\Android\DictTango\DotnetSrc\DictTango\DictTangoWinUI\bin\x64\Release\net8.0-windows10.0.19041.0\win-x64\native\DictTango.exe

[kmgallahan]

@Jimex AOT isn't supported at this time

#3856 (comment)

[robinwilson16]

You still cannot use WinUI 3 alongside Microsoft.EntityFramework.Tools as both contain Microsoft.Web.WebView2.Core.dll and it leads to the error above when trying to publish your app whilst it builds and runs fine. This is because it tries to copy the dll file from both repositories.

The app is NET MAUI but it triggers this error as soon as you add Microsoft.EntityFramework.Tools to your project.

The errors have been here since 2021 but the file it fails on has changed from the json file to the dll file (perhaps it was briefly fixed in between).
When two repositories have the same dependency (in this case Web View 2) then Visual Studio just needs to be able to cope with this without just failing, especially if both files are identical or split web view off into its own repository rather than include it in the base WinUI one and one of the ones commonly added to projects for database connectivity.
Linux package manage handles this sort of thing easily but VS just fails then you waste hours researching workarounds.

A check was added to Visual Studio to fail on duplicated files whereas before they just used to overwrite each other but then no mechanism for how to deal with it was added and this overlap on dependencies was never addressed and the issue is closed.

I can't publish a self-contained app whilst this bug still remains but can publish it requiring NET 8 to be installed on the machine already with a workaround which is to add this to the project file which disables the check added to check for duplicated files:

<PropertyGroup>
  <ErrorOnDuplicatePublishOutputFiles>false</ErrorOnDuplicatePublishOutputFiles>
</PropertyGroup>

Please could it be re-looked at?

[Scottj1s]

There are two distinct errors noted in this issue.

The first is that the logic to address conflicting build vs publish deps.json files was incomplete. The next release of Windows App SDK will include a fix that covers project references (transitive deps.json conflicts). Meanwhile, the problem can be worked around with this *.csproj excerpt:

  <!-- Temporary workaround until WinAppSDK 1.5.2 provides fix -->
  <Target Name="RemoveConflictingDepsJsonFiles" AfterTargets="GetPackagingOutputs">
    <!-- If conflicting build and publish deps.json files exist in this or referenced projects,
        use only the publish deps.json files, and remove the corresponding build deps.json files. -->
    <ItemGroup>
      <_PublishPackagingOutputs Include="@(PackagingOutputs->HasMetadata('CopyToPublishDirectory'))"/>
      <_PublishDepsJsonFiles Include="@(_PublishPackagingOutputs)"
        Condition="'@(_PublishPackagingOutputs)' != '' and $([System.String]::Copy(%(FileName)%(Extension)).EndsWith('.deps.json'))" />
      <PackagingOutputs Remove="@(_PublishDepsJsonFiles)" MatchOnMetadata="TargetPath"/>
      <PackagingOutputs Include="@(_PublishDepsJsonFiles)"/>
    </ItemGroup>
  </Target>

The second issue has to do with WebView2 implementation file conflicts (e.g., Microsoft.Web.WebView2.Core.dll). The ultimate cause of this was the embedding of WebView2 into Windows App SDK. The solution is to factor the WebView2 dependency out of Windows App SDK, and replace it with a standard Nuget package reference. This will also permit a la carte updates to WebView2 outside the Windows App SDK ship cycle. Our intent is to include this fix in Windows App SDK 1.6. We'll keep this issue open to track this work.

[Scottj1s]

Closing this issue in favor of #4249 for tracking EntityFramework build errors

[kmgallahan]

Resolving this as a dup of #1856

Closing this issue in favor of #4249 for tracking EntityFramework build errors

but 4249 is also closed without any permanent fix committed.

😅

[robinwilson16]

So with both issues now closed in favour of each other does this mean we are now stuck in an infinitive loop of uncertainty?
Hopefully it's still on someone's fixing lists in the depths of Microsoft.

[Scottj1s]

Reopened #4249 and retitled for clarity