Note: this post is derivative of ‘Using 64-bits Ghostscript dll with Unity’ by CipherZero, but it is not the same question. His was one of getting the dll to work in Unity, which I have working. My question is getting the dll to work in the Hololens.
Please know I’m using a 64-bit version of ghostscript in the Unity Editor (as the Editor is an x64 environment), and I’m using an 32-bit version in the Hololens as its an x86 (x32) environment. I’m doing this using directives,
I’m integrating the ghostscript dll into my project. I’ve followed the instructions, copying the dll file from the ghostscript install and putting it under “Assets/Plugins” (and I’ve tried bin/Debug/) in my project folder.
When I play the scene, the x64 dll works great as intended. When I build and deploy on the Hololens everything still works great. But when I try to call the code utilizing the Ghostscript x32 bit dll in the Hololens, it returns the following:
Exception thrown: ‘System.DllNotFoundException’ in Assembly-CSharp.dll
Exception thrown: ‘System.ApplicationException’ in Assembly-CSharp.dll
ApplicationException: The gsdll32.dll wasn’t found in default dlls search path or is not in correct version (doesn’t expose the required methods). Please download at least the version 8.64 from the original website
I’ve tried putting the dll in every single folder in the App directory.
I’ve tried redownloading Ghostscript from their website and using a fresh dll from the download.
No matter where I place the x32 dll, it always give a “DllNotFoundException”.
Please, any ideas are more then welcomed at this point.
Not really, sorry. It’s been a few years since I’ve had to support both x86 and x64 libraries in the same application, and it was a continual source of sanity loss. If my application threw a BadImageFormatException just one more time…
Ultimately it was a deciding factor in getting rid of all 32bit dependencies we had (even switching to other libraries and fixing up the code base) so it was fully 64 bits from bottom to top.
In your case, that doesn’t sound like a solution, so disregard what I just said
When you make a build, check the /<app_Data>/Plugins path. Did gsdll32.dll get copied there? Does it even exist?
Also (I’m assuming you use Visual Studio) open the solution and check the Plugins project. Look under References. Is the ghost script DLL listed there? Are there any warning/error icons on it? Right-click on it to show its properties. Is it pointing at the correct path? Is “Copy Local” true?
If all else fails, then why not try using the 32bit editor since the target platform is 32 bits? At the very least that should help you get your project organized once you’ve confirmed it’s working on the Hololens, then you can try migrating that project over to the 64bit editor at a later point.
Yeah same. The imageformat/notfound errors are driving me absolutely bonkers.
It does get copied! When I build it in Unity, I tried clicking Copy References too and that didn’t seem to help either.
Interestingly enough, it does not appear under References. It is in the Solution Explorer window, but with a yellow warning icon. If I double click on it, it says, “The item ‘gsdll32.dll’ does not exist in the project directory. It may have been moved, renamed, or deleted”.
In this instance, it is looking here, C:\Users\jvh\Desktop\HoloVI\App\HoloVI\gsdll32.dll
Which is quite odd considering it is located,
C:\Users\jvh\Desktop\HoloVI\App\HoloVI\Plugins\X86
In any case I tried copying it to the location it was wanting, still didn’t work and I can’t add it as a reference in VS as it returns, “A reference to dll path could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component”.
I don’t see a copy local option. I see a Copy to Output Directory option.
Put simply: Native libraries are written in a language like C or C++ and compiled into machine language code.
Managed libraries are built using some .Net language like C#, Visual Basic, etc. and are encoded into IL (intermediate language).
So let’s go back to the basics: As far as I know, you can’t load a 32bit library in a 64 bit process without doing some workarounds, doing inter-process communication, etc.
That brings me to my first question: Are you building and deploying the Hololens application as a 32bit application, or 64bit? Can you doublecheck the output .exe using Dependency Walker that it is in fact a 32 bit application?
If you’re using DW, you first do a build to generate the application .exe file. Then you drag ‘n’ drop that into DW. Ignore all the errors. In the tree view starting from your .exe file listing all the modules, there’s an icon next to the .exe name.
If the icon has “64” on it, it’s a 64bit application. Otherwise it’s 32.
My apps ‘Target framework’ is .NET Framework 3.5 when running in the Editor, but I’m confident the HoloLens deploys apps as UWP (Universal Windows Platform) apps.
I’m thinking gsdll32.dll (the GhostScript dll) is not compatible with UWP apps and here’s why. I know the program can see both my dlls because when I try to load the 64 bit dll on the HoloLens it returns a BadImageFormat exception. This is expected as the HoloLens has an x86 processor and can only run in that environment. It returns a DllNotFound exception when attempting to load the 32 bit dll. This leads me to believe that DllImport[dllname] works for UWP apps, but that means ghostscripts dlls are not compatible for UWP apps.
Running through ghostscripts documentation, https://ghostscript.com/doc/9.21/Make.htm, there is a section on how to build Ghostscript from source. Of interest is a section for the Microsoft Environment for WinRT. I’m familiar with NETFX_CORE/WINRT being preprocessing directives used for UWP apps. So my question is then, is this the conversion that I’m looking for?
If not, is it possible to convert the ghostscript dll to work on UWP apps? Thoughts?
EDIT Update 2: When I try to build the ghostscript dll winrt solution in Visual Studio 2015 it says I don’t have the build tools for Visual Studio 2012 (v110) and to install Visual Studio 2012 (v110) to use the build tools. Attempting to install VS2012… can’t seem to find v110 listed specifically on Visual Studios older version downloads.
I’m not quite sure how to mark as ‘content’ and I don’t know how to build dlls (tried following microsofts link, similar to what you found), but it returned errors (see attach).
How do I check if it has dependencies on other libraries, and if those libraries are located in the solution already?
Any ideas how to port the code to UWP? Is that inline with building the dll for WinRT apps?
I agree this is beyond the Unity scope but I really don’t know where else to go. I’ve posts on stack overflow with similar info so I’m hoping someone knows how to build a DLL as I really don’t have a clue and tutorials aren’t very helpful as any that I find specify creating a new project and going from their but the GS source files come with a winRT solution.
Sorry to dump all this random info on you for something that sounds like we both know nothing about, just dont know where else to go after trying to get this dang dll to work for the past week.
When you build for WinRT, you’re building for UWP. WinRT was supposed to be “the way forward” in Windows 8, and, well, that didn’t exactly work out. So Microsoft decided that UWP is now “the way forward”, which is basically WinRT on steroids.
My recommendation is to follow a couple of tutorials on building DLLs and accessing them from a UWP application. Nothing more than a couple of functions and printfs. Once you have a solid understanding of that, then revisit ghostscript.
I know it’s frustrating. DLL Hell is a very real term for good reasons.
