-
-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expected icu*.dlls are not loaded at runtime #20
Comments
The first two bullet points will be fixed by #21. Thanks for mentioning the third one. That's something we'll have to remember and fix when we have a .NET Core version. |
Capture the third bullet point in #23. |
@ermshiperete I pulled the latest from master and am still experiencing the same issue where I expect 56.1 to be loaded, but it is loading version 57.1 when running that test. This is because the dynamic loading starts from version 60 downwards to 56. So it will check for the existence of icu 57 on my computer before the version my assembly has packaged. |
If there are unmanaged ICU libraries in the same directory as icu.net.dll we will now use those even if we find a higher versioned ICU elsewhere on the path. This fixes most of #20.
Description
The code for dynamically loading the icu libraries at runtime is causing some unexpected behaviour.
Icu4c.Win.Full.Lib.54.1.3-beta3
. Repro below.D:\git\tools\nunit3-console.exe D:\git\icu.net\output\Debug\icu.net.tests.dll
when from a directory that is not whereicu.net.tests.dll
is located.)packages
folder). It is stored in a NuGet cache (ie.%USERPROFILE%\.nuget\packages
). As a result, when running on .NET Core, the dependencies are resolved in their cache folder and not actually copied to the program's binary output folder. The .NET runtime knows how resolve these runtime dependencies when you use[DllImport]
but since we are calling a Windows functionLoadLibrary
, it bypasses that logic.Repro Steps:
Expected Behaviour
The test passes because the Icu4c.Win.Full.Lib contains v54.1 libraries.
Actual Behaviour
Test fails because it loads
C:\Program Files (x86)\MiKTeX 2.9\miktex\bin\icuuc57.dll
and outputs 57.1.Proposed Solution
One solution is to revert the dynamic loading with
[DllImport]
and manage the native library names with an approach that LibGit2Sharp uses. They have a setup that allows for theNativeDllName.Name
to be generated at build time so it is not hard-coded. Consequently, their NativeMethods looks like the one below:They have two packages similar to icu.net called LibGit2Sharp.NativeBinaries and LibGit2Sharp.
LibGit2Sharp.NativeBinaries contains:
<dllmap>
attributes for Monolibgit2_filename.txt
to the consuming project as an embedded resource. And adds links to native binaries in the consuming project.The LibGit2Sharp project has a dependency on the LibGit2Sharp.NativeBinaries package. At build time, it has a couple of .targets that run to generate the correct native library name.
libgit2_filename.txt
and calls their custom build task to generate the NativeDllName class.NativeDllName
class.Considerations
Two nuget packages of icu.net would have to be made. One for the minimal ICU build and other for the full ICU build because the dependencies are linked to the project.
The text was updated successfully, but these errors were encountered: