WinUI3/Windows App SDK Custom Library issue: Could not copy the file "../.nuget/packages/../lib/net5.0-windows10.0.19041/../x64/LiteCore.dll"

[mlynch]

Library Version

Couchbase.Lite.Enterprise 3.0.0

(build number unsure, can't get app to run, was installed 4/16/2022)

.NET Runtime

6.0.202 (also happens on a 5.0 version which I don't have at the moment as I upgraded to 6)

Operating System / Device Details

Windows 10
Version 10.0.19042 Build 19042

Log Output

Expected behavior

When using Windows App SDK 1.x and WinUI3, a Class Library in WinUI3 should be able to include Couchbase.Lite.Enterprise and properly locate LiteCore.dll in the app project that includes that library.

Actual behavior

A "WinUI 3 in Desktop" project doesn't build when including a "Class Library (WinUI 3 in Desktop)" project that includes Couchbase.Lite.Enterprise. The build cannot locate LiteCore.dll despite it being on the filesystem. Somewhere something seems to be resolving the actual final platform-specific bin directories incorrectly.

This is what the library project looks like:

Steps To Reproduce

1. Install the Windows App SDK including Visual Studio 2022 extension to add templates to VS
2. Create a new Class Library (WinUI 3 in Desktop) project. Install Couchbase.Lite.Enterpriseinto that library, pack it as anupkg` for distribution.
3. Create a new Blank App, Packaged (WinUI 3 in Desktop) project and install the library created in step 2.
4. Build the app and notice it fails with the above error.

Reproduction Project

See PGP signed App project here (first time using PGP so let me know if I did this wrong): https://drive.google.com/file/d/14wO2o5uL6ZUSqEs7wyi6GV4xRHiACzKY/view?usp=sharing

More info

Please let me know if I'm just doing something wrong. Also, for context, we're a Couchbase partner (Ionic, we built the JavaScript versions of CBL for iOS and Android, and now Windows)

This worked fine with the Windows App SDK 0.8.x but Microsoft seems to have made a bunch of changes for 1.x that seems to have broken things like this, unfortunately.

[mlynch]

I'm not exactly sure but this looks to be an issue with the Windows App SDK specifically:

microsoft/WindowsAppSDK#1217
microsoft/WindowsAppSDK#1777
microsoft/microsoft-ui-xaml#5120

In the meantime I might have to come up with a workaround, will investigate and follow up if I figure it out.

EDIT: Issue filed with Windows App SDK microsoft/WindowsAppSDK#2413

[mlynch]

I have a workaround to fix the build.

In the library .csproj, use these settings when referencing the package:

<Project Sdk="Microsoft.NET.Sdk">
	<ItemGroup>
		<PackageReference Include="Couchbase.Lite.Enterprise" Version="2.8.6">
			<IncludeAssets>compile</IncludeAssets>
			<PrivateAssets>all</PrivateAssets>
		</PackageReference>

Then, in the actual app project, install Couchbase.Lite.Enterprise into that. This enables the library to compile but then allows the app project to include its own CBL reference which correctly builds and resolves the CBL assembly at runtime.

This isn't ideal because I'd like to not have the user have to import it again but it's a minor issue.

[borrrden]

I wrote this comment many times because I can't exactly tell what this platform is expecting. This is a platform we haven't had time to fully investigate quite yet. From the error message, it looks like there is some custom logic going on that you have pointed out as faulty to Microsoft. I'm not sure that the net desktop targets file will be entirely correct, and I believe that somehow it is drawing the whole x86 vs x64 thing from our targets file. I notice you are using the "packaged" type so I imagine this is going to draw more from UWP semantics than from Net Desktop ones. The UWP version of the targets file instead chooses a file based on the architecture currently being built. If you are adding the support library manually I'd be interested in what happens if you try to add the UWP support package instead (if such a thing is possible). Traditionally, when building a .NET application it could run in either 32 or 64 bit mode and that wouldn't be known until runtime and so both LiteCore.dll needed to be present. UWP and .NET Native changed this so you know ahead of time which architecture you are compiling for. I am suspecting that this ahead of time knowledge is continuing into WinUI. If that's the case it will expect just one copy of the native library for the correct architecture.

Let's keep an eye on what Microsoft has to say about this.

[borrrden]

As an update to this, WinUI semantics are extremely similar to UWP, but it seems that you are allowed to use the regular desktop C++ runtime. So the loading method will be like UWP, but the deliverable will be like NetDesktop. This means that there will be a new package now (Couchbase.Lite.Support.WinUI).

[borrrden]

3.1.0 was released with WinUI 3 support, so this issue should be resolved now. If you happen to submit something to the store and it fails though then please inform us since I couldn't get a straight answer on if the strict UWP Win32 requirements were still applicable.