couchbase-lite-net
couchbase-lite-net copied to clipboard
couchbase
(3.2.0) LiteCore.dll not copied to correct folders when building with SelfContained
Library Version
3.2.0
.NET Runtime
net8.0-Windows net8.0
Log Output
DllNotFoundException: Could not find LiteCore.dll! Nothing is going to work! Tried searching in: C:\Users\Vince\source\repos\CouchbaseLiteBuild\bin\Debug\net8.0\win-x64\runtimes\win-x64\native\LiteCore.dll C:\Users\Vince\source\repos\CouchbaseLiteBuild\bin\Debug\net8.0\win-x64\x64\LiteCore.dll C:\Users\Vince\source\repos\CouchbaseLiteBuild\bin\Debug\net8.0\win-x64\bin\x64\LiteCore.dll
Expected behavior
LiteCore.dll is copied to output in the folders: x64 and arm64
Actual behavior
LiteCore.dll is not copied to the folders specified above.
Steps To Reproduce
- Create new console application
- Reference latest CouchbaseLite nuget package
- Set SelfContained = true in .csproj
Note:
With 3.1.7 LiteCore.dll is copied to buildoutput/, buildoutput/x64, buildoutput/arm64 With 3.2.0 LiteCore.dll is copied to buildoutput/
By self contained, this means compiled to run without the .NET runtime on a single architecture right? I think rather than copy the files again the correct solution would be to add an additional lookup directory being buildoutput after x64 and arm64 are considered because the only reason they exist is because .NET can run on multiple architectures and you don't know which one until after you are already running.
Otherwise if it still needs to run on multiple architectures, then I'm not quite sure what the strategy is supposed to be because it's a waste to copy them otherwise.
Ok doing a quick test I see that my former assumption is correct and self contained implies one runtime architecture to target. This will be a simple fix I believe. Tracking in CBL-6236
In the meantime, you probably have already realized this but you can workaround this by adding a postbuild step to move the buildoutput/LiteCore.dll file to buildoutput/<arch>/LiteCore.dll