Magick.NET
Magick.NET copied to clipboard
Magick.NET does not copy libraries to the correct location on macOS (or Linux)
Magick.NET version
10.1.0
Environment (Operating system, version and so on)
macOS Big Sur 11.6.3
Description
Magick.NET does not copy libraries to the correct location on macOS (or Linux).
When running I get the following error:
Magick.NET-Q8-AnyCPU: The type initializer for 'ImageMagick.MagickFormatInfo' threw an exception.
Magick.NET-Q8-AnyCPU: The type initializer for 'NativeMagickFormatInfo' threw an exception.
Magick.NET-Q8-AnyCPU: Unable to load shared library 'Magick.Native-Q8-x64.dll' or one of its dependencies.
In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(libMagick.Native-Q8-x64.dll, 1): image not found.
It can be solved by (with the output directory as current directory) copying runtimes/osx-x64/native/Magick.Native-Q8-x64.dll.dylib to bin/Magick.Native-Q8-x64.dll.
In my Azure Function Dockerfile that uses this library I have the following in the runtime image which solves the problem there:
RUN cp /home/site/wwwroot/bin/runtimes/linux-x64/native/Magick.Native-Q8-x64.dll.so \
/home/site/wwwroot/bin/Magick.Native-Q8-x64.dll
This has been an issue for years now, it would be great if a real fix could be implemented. If the project maintainers do not wish to do this, please give me some pointers on where the logic that fixes this should be introduced and I'll give it a whack.
Steps to Reproduce
Use the Magick.NET package on anything that isn't Windows.
I have no idea what is causing this. This could also be something in dotnet or VisualStudio that is not working properly. Feel free to do some research on why this is happening.
~~@dlemstra Can you update the documentation on how to build the package? I'm at a loss here, I'm supposed to prepare the Magick.Native directory somehow, but the scripts don't run on Windows, and throw lots of errors on macOS, there are some undocumented arguments that I'm supposed to supply to the install.* scripts as well.~~
~~I'm primarily on macOS but I have Windows available to me if that actually is necessary to build the package.~~
Nevermind I replaced some calls to my installed version of nuget instead of the checked in version, and was able to finally figure it out.
~@dlemstra Can you update the documentation on how to build the package? I'm at a loss here, I'm supposed to prepare the Magick.Native directory somehow, but the scripts don't run on Windows, and throw lots of errors on macOS, there are some undocumented arguments that I'm supposed to supply to the install.* scripts as well.~
~I'm primarily on macOS but I have Windows available to me if that actually is necessary to build the package.~
Nevermind I replaced some calls to my installed version of nuget instead of the checked in version, and was able to finally figure it out.
could you give more details
~@dlemstra Can you update the documentation on how to build the package? I'm at a loss here, I'm supposed to prepare the Magick.Native directory somehow, but the scripts don't run on Windows, and throw lots of errors on macOS, there are some undocumented arguments that I'm supposed to supply to the install.* scripts as well.~ ~I'm primarily on macOS but I have Windows available to me if that actually is necessary to build the package.~ Nevermind I replaced some calls to my installed version of nuget instead of the checked in version, and was able to finally figure it out.
could you give more details
Sorry I meant that I managed to build the package, I haven't figured out the problem, was toying with the targets file that specifically mentions .NET Framework and nothing else. An earlier version also configured rules for unix there, but never macOS, and I wonder if it copies to the right directory at all.
No issues on my Mac; but alpine was giving me the same headaches as so many others.
Until I downgraded from alpine3.15 to alpine3.15
Well I have issues on my Mac. I use this package in a subproject to an Azure Function, whenever I try to debug the Azure function using the Azure Functions runtime utilities I have to quickly copy the bin/output/runtimes/osx-x64/native/Magick.Native-Q8-x64.dll.dylib to the bin/output/ directory otherwise .NET doesn't find it.
@abjugard Interesting, ... I'm not using Azure Functions so there might be some differences in setup; but the tiny test project I used to test Magick on alpine images runs fine on my mac. Perhaps you can see this runs on yours as well?
https://github.com/woutervanvliet/test-magick-problems
All it does is create a new ImageMagick instance and ConsoleLog the very non-informative "Channels" property.
I've got same error on macOs Monterey 12.4 but I am not using any docker or azure functions. I want to be able to run app locally. Just switched to macOS from windows and only problems :D Anybody has solution? It can be even temporary.
The same issue (The type initializer for 'ImageMagick.MagickFormatInfo' threw an exception.) is happening with version 12.0.1 on Imgbot , I reverted to the previous working version here: https://github.com/imgbot/Imgbot/commit/7a407243c760ed20db3ba4d85fdd130c41390865 . Let me know if you have any input on how to fix this so we can update to the latest Magick.NET version. @dlemstra
I have same issue on both linux x64 and arm64, missing the native library Magick.Native-Q16-x64.dll.so. From what I found in https://github.com/dlemstra/Magick.NET/blob/main/publish/Magick.NET.targets, there should be $(MagickCopyNativeLinux) defined somewhere, although both linux-x64 and linux-arm64 use the same variable name and copy native .so file with same name in the output dir, presumably overwriting each other. I couldn't find where the $(MagickCopyNativeLinux) is supposed to be set, @dlemstra
I should add an explanation about this to the documentation. You can now do the following in your .csproj file:
<Project>
<PropertyGroup>
<MagickCopyNativeLinux>true<MagickCopyNativeLinux>
</PropertyGroup>
</Project>
And then it should copy the binaries.
I can confirm that those properties are having the desired effect, nice job @dlemstra!
Leaving this issue open for you to close when you add documentation about this.
I still don't understand why it does not happen but I am happy to hear that this resolved your issue @abjugard. The documentation has been updated so I will close this issue now.