Hello all, I’m using Gembox.Spreadsheet 49.10.1153 and I want to save an ExcelFile as PDF…when I invoke the method (which it worked up to now and I haven’t made any changes to that part) it throws the following error “An attempt was made to load a program with an incorrect format. (0x8007000B)” has anyone encountered this issue before. This is on a web app using .NET 6 and Angular 14. The funny thing is that it does save as xlsx. Could some one please point me to the right direction in order find what’s causing the issue ?
The app is deployed in IIS on Windows server 2019 and the build uses “AnyCPU” configuration.
I’ve trying changing the app pool to allow 32bit app but without success.
Please let me know what further info is needed.
Thank you in advance.
Hi Tony,
Does the issue occur locally or only when you make a deployment?
Also, how are you deploying your application exactly?
Anyway, please create a small Visual Studio project that reproduces your issue so that we can investigate it.
Regards,
Mario
The issue occurs when deployed in the cluster. not in my personal web server used for testing purposes or the dev environment.
I’m deploying the application using VS 2022 Publish, as a framework dependent application (NET 6.0), target runtime is portable and the configuration is AnyCPU. (i’ve tried explicitly x64 and x86…the latter worked but we’re in a 64bit environment altogether)
After some digging I found out that the Gembox.Spreadsheet dll file is 32 bit compiled. This is what caused the issue and could not work in the specific deployed environment. The problem is that this environment is a cluster of IIS servers and I cannot tamper with it.
I’m saying this because In a local single IIS test environment, there is no such issue, which made me wonder why would it work there and not on the cluster.
At the end what I did was to allow 32-bit apps in the application pool and restart both the pool and the web app from within IIS (which finally made it work).
Is there by any chance a 64-bit compiled nuget Gembox.Spreadsheet that I’m missing?
Thank you in advance
How did you find that out?
I’m afraid that is not true, GemBox.Spreadsheet is build with “AnyCPU” option.
I’ve opened the dll file with notepad++ after i’ve stumbled upon this article here
and i’ve checked the follwing
PE L = 32-bit (x86)
· PE d† = 64-bit (x64)
the first occurrence as the article denotes was PE L …stating that it is 32 bit.
Can you please verify ?
Thank you in advance
Hi Tony,
I don’t think that is correct.
I just tried creating the default ClassLibrary1 project and built it with the “Any CPU” option and the resulting DLL contains that “PE L” that the article mentions.
However, if I open that same DLL with ILSpy I see this:
And if you open GemBox.Spreadsheet, you’ll get that same “Architecture: AnyCPU (64-bit preferred)”.
Also, if you run the following:
var assembly = typeof(ExcelFile).Assembly;
var architecture = assembly.GetName().ProcessorArchitecture;
Console.WriteLine(architecture);
You’ll notice that GemBox.Spreadsheet is defined with ProcessorArchitecture.MSIL which indicates that it’s neither 32-bit nor 64-bit, instead, it’s neutral with respect to processor and bits-per-word.
In other words, the same GemBox.Spreadsheet.dll file works on both 32-bit and 64-bit machines. GemBox.Spreadsheet is a fully managed .NET library that is independent of the system architecture. If the application that is using GemBox.Spreadsheet targets 64-bit then GemBox.Spreadsheet will also use 64-bit architecture since it is JIT compiled when the application runs, and if it targets 32-bit GemBox.Spreadsheet will use 32-bit architecture instead.
Anyway, perhaps some other DLL in the application is 32-bit?
Nevertheless, I’m afraid that without investigating your environment and your application I cannot say anything for sure.
Regards,
Mario
Hi Mario,
My thoughts exactly, I couldn’t imagine a nuget package not to be built with anyCPU option, for the exact reason that you do not know if the deveoper using it will build the app for 32 or 64 bit. However, The issue appears only when I invoke the method ExcelFile.Save(path) and that’s what makes me wonder. Can you please let me know what should I check in the application and/or environment and let you know ?
Thank you in advance
Tony, please create a small Visual Studio project that reproduces your issue and send it to us.
I’ll try to reproduce your issue by deploying it on a Windows Server 2019.
