move Akka.DistributedData.LightningDb onto vendored package #5180
Conversation
only until CoreyKaylor/Lightning.NET#141 gets resolved close akkadotnet#5174
Aaronontheweb
added
the
akka-ddata-durable
|
So I'm able to get LightningDb.NET working just fine on Windows in this PR, so there must be a binary copy issue that's hitting the MNTR. Between LightningDb v0.13 and this vendored version they moved to using two different .DLLs for LightningDb on Windows. That might be part of it. I'll take a closer look at the binary output on a local development machine. |
|
I was able to reproduce the issue locally - in does indeed appear to be an issue with the MNTR being unable to resolve the native assembly paths at runtime. I'm not sure why this wasn't an issue before - it could have to do with the .NET Standard 2.0 version of the package resolving different than the .NET Core 3.1 and .NET 5.0 versions since CoreyKaylor/Lightning.NET#138 |
| @@ -4,6 +4,7 @@ | |||
| <PropertyGroup> | |||
| <AssemblyTitle>Akka.DistributedData.Tests.MultiNode</AssemblyTitle> | |||
| <TargetFrameworks>$(NetFrameworkTestVersion);$(NetTestVersion);$(NetCoreTestVersion)</TargetFrameworks> | |||
| <Platforms>x64</Platforms> <!-- target x64 only due to LightningDb support --> | |||
There was a problem hiding this comment.
I think AnyCPU might have something to do with the issues here. Going to see if I can get this all to work under x64.
There was a problem hiding this comment.
Doesn't appear to have helped, based on the data from my local machine
There was a problem hiding this comment.
LOL, applied this to the wrong project....
|
On this PR, the structure of my folders from the build output of |
|
Alright, figured this one out - looks like the |
|
Looks like this is an MSBuild issue with the latest Lightning.NET sources: CoreyKaylor/Lightning.NET#143 Definitely an edge case in how native .DLLs get resolved. |
|
Might have to specify the Other possibility I'm going to look at is that the MNTR's Runtime Identifier (RID) is at issue. |
|
I've tested this locally and changing the RIDs does not help at all - those directories simply aren't being searched for these DLLs. |
|
Looks like this resolved the issue but I need to refine this a tad more.... |
…ries for MNTR specs
| @@ -0,0 +1,48 @@ | |||
| <?xml version="1.0" encoding="utf-8"?> | |||
| <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> | |||
There was a problem hiding this comment.
Had to resolve this by re-using the .targets file from the original projects.
Everything using the original LightningDb package runs just fine in a stand-alone project, but the MNTR isn't able to resolve these DLLs when it's running. Best bet is to just stick the DLLs in a folder adjacent to the .NET dlls, which is how things work in the current dev branch.
There was a problem hiding this comment.
Note: this targets file is only necessary because of the quirks of the MNTR, transitive dependencies, and multi-targeting in MSBuild. A normal software application using Akka.Cluster.Sharding will not have this issue.
|
Bah, looks like I broke the .DLL copying again by trying to share it. I'll need to tweak that again. |
only until CoreyKaylor/Lightning.NET#141 gets resolved
close #5174