[SOLVED] Pipeline extension 3.8 Unable to load DLL 'FreeImage'

Gronk · January 16, 2021, 12:26pm

So… I am probably going to embarrass myself again(1) with something easy I forgot to do in my project but…

Trying to migrate a pipeline extension that manipulates image data using FreeImage nuget extension i get the following error.

unable to load DLL ‘FreeImage’

I have made a minimal solution and uploaded it to git that replicates the problem(2): https://github.com/gronken/TestFreeImage

The solution has two projects the FreeImagePipline and a TestFreeImage.OpenGL.

Everything is standard(ish) from the templates except for Line 14 in the FreeImageEditImporter.cs that just allocates some mapdata using FreeImage.Standard.

FIBITMAP image = FreeImage.Allocate(100, 100, 24);

The FreeImagePipline project builds fine.
If you build the file.bmp from the Content.mgcb in the TestFreeImage.OpenGL project it builds fine
If you try to run the TestFreeImage.OpenGL project you get the unable to load DLL ‘FreeImage’ error.
To make the TestFreeImage.OpenGL run you can delete line 14 from the FreeImagePipline (https://github.com/gronken/TestFreeImage/blob/master/FreeImagePipline/FreeImageEditImporter.cs)

So my observation is that i can’t do anything with freeimage in the pipeline extension 3.8 but it worked in 3.7.

I’m guessing it’s something easy like i have to tell the FreeImage.Standard dll to work with .Net Core 3.1 in some capacity but i have no idea how… or why

Any help would be much appreciated.

(1) [SOLVED] Pipeline extension 3.8 not finding nuget files
(2) Disclaimer: The pipeline project don’t do anything constructive besides throw the exception for simplification. It doesnt use the file.bmp its there to prove the point thats all.

persn · October 21, 2020, 11:25pm

Interestingly enough it built when I used the mgcb editor, it did not build when I used the mgcb from the command line. The error message seems to indicate that it has difficulties loading a native .dll so maybe the editor is able to load it because it’s built with the .NET windows SDK? Hard to say, but my gut feeling says that it’s likely there’s some native dependency issue at play here.

I don’t know exactly what you intend to do with FreeImage, but maybe you could consider using ImageSharp instead? It’s built in pure .NET so dependency issues on native .dll’s are not something you have to struggle with. It’s fairly multifunctional. Maybe a tad slower than the native alternatives, but probably not by much. Just something to consider. https://github.com/SixLabors/ImageSharp

Gronk · October 22, 2020, 12:42am

Just to hear that you have the same experience as me confirms that I’m not completely insane. So Thank you.

That makes some sens i guess

The image format I import saves the layers as separate files. I use Freeimage to merge them to one file.

Switching to another library is definitely an option. Speed isn’t that important during build time unless it takes too long.

The only reason i used Freeimage was because monogame uses it for texture imports. So i used the same.

github.com

MonoGame/MonoGame/blob/develop/MonoGame.Framework.Content.Pipeline/TextureImporter.cs

// MonoGame - Copyright (C) The MonoGame Team
// This file is subject to the terms and conditions defined in
// file 'LICENSE.txt', which is part of this source code package.

using System;
using System.IO;
using Microsoft.Xna.Framework.Content.Pipeline.Graphics;
using Microsoft.Xna.Framework.Graphics.PackedVector;
using FreeImageAPI;
using MonoGame.Framework.Utilities;
using StbImageSharp;

namespace Microsoft.Xna.Framework.Content.Pipeline
{
    /// <summary>
    /// Provides methods for reading texture files for use in the Content Pipeline.
    /// </summary>
    [ContentImporter(".bmp", // Bitmap Image File
                        ".cut", // Dr Halo CUT
                        ".dds", // Direct Draw Surface

This file has been truncated. show original

Ill look in to ImageSharp tomorrow.

Gronk · October 28, 2020, 9:05pm

I reported an issue as i cant find any reason this isnt working.

I might not need FreeImage but maybe someone else will in the future.

Gronk · January 16, 2021, 12:25pm

The issue was closed with with this explenation below. I dont know why it changed between 3.7 and 3.8 but i dont care any more as i rewrote my processing step with ImageSharp as surgested by @persn

"Since MGCB also uses freeimage, and you are referencing another freeimage version, you will cause a lot of conflict between those 2 native libs so its no wonder that stuff starts crashing right away.

If you really wanna use one of the same native libraries MonoGame.Content.Pipeline already uses, you are gonna have to either reference the native library already in the MG.C.P folder or make your pipeline extension create another process."