Hey all,
I need to integrate a dll released by SautinSoft that allows the conversion of an Excel file to a PDF. The extension that exists on the forge (ExcelToPdf) is very old and I need to use the newest version.
I created a new extension having a method with 2 inputs and 1 output:- intput parameter -> ExcelFile binary- input parameter -> License Key (not using it at the moment but ready for the future)- output parameter -> PdfFile binary
After opening the extension in Visual Studio 2026 I added a NuGet reference directly to the dll
The other dependent dlls were added automatically.Then I programmed the code to convert the file and tested the compiled dll with a .NET MSTest project and it worked fine. I removed the test project and compiled the solution and published the extension.I consumed the extension in an Outsystems app but it returns this error:
If someone can take a look at this and help I would appreciate it.The xif file is too large to attach here (almost 40MB), but I created a wetransfer link for those who can help me: https://we.tl/t-j4aRS90Yq76zXYpQ
regards
I manually copied the DLL to the bin (instead of the bin2) directory, and now it works! Although it is extremely, extremely slow (takes over a minute for a fairly simple XLSX), it does work, kinda (the output doesn't look very good).
So, concluding, it seems that although SautinSoft is in the bin2 directory, it only looks for the bin directory for DLLs (or Windows does, I'm not sure how that stuff works).
Ha, wait, of course. The solution is simple: instead of copying it to the binaries directory, copy it to the application directory:
It will then be copied to the application root (just tested it), and then it works! Still dreadfully slow though...
Some extra info I forgot to mention on the main post.
The dll mentioned in the error: "libHarfBuzzSharp" is included in the project BUT Visual Studio doesn't put it in the bin folder like all the other dlls.He created 3 extra folders inside the bin folder
and each one has a version of the libHarfBuzzSharp.dll.
I believe the runtime error I'm getting is because of this.
The issue is happening because the latest SautinSoft library depends on native libraries like HarfBuzzSharp, and OutSystems extensions do not automatically deploy those native dependencies correctly. Your DLL works fine in the MSTest project, which means the implementation is correct, but inside OutSystems the runtime cannot find libHarfBuzzSharp. Most likely the required native DLLs from the NuGet package (such as HarfBuzzSharp.dll, SkiaSharp.dll, and files inside runtimes/win-x64/native) are not being copied to the deployed extension folder or there is an x64/x86 mismatch. Try setting all dependent DLLs with Copy Local = true, make sure the IIS app pool and extension are running in x64, and manually include the native runtime DLLs in the extension deployment. If the newer package still causes issues, the best approach is to create a separate .NET Web API/microservice for Excel-to-PDF conversion and call it from OutSystems instead of hosting the library directly inside the extension.
Hey there,
Thank you for your answer. Since Outsystems is running on the cloud I don't have access to the frontend to check IIS, unfortunately. But since it's an Outsystems cloud environment and it's a relative new installation (it was setup in 2024) the pools should be running in 64 bits. But I'll try to find a way to check it out by talking with our Outsystems account manager.
Regarding the extension itself, if I check the Resources tab in service center, all the dlls are there.
But I guess the Outsystems engine for some reason doesn't i know how to get libHarfBuzzSharp.dll from the x64 folder.Your suggestion on creating a .NET Web API has some merit. But I don't know if that's possible in the time we have because it would require some research since I've nver done that.
Yes, from the screenshot it looks like the DLLs are correctly deployed in Service Center, including the x64 native libraries. The problem is probably that OutSystems is not automatically resolving native dependencies from the x64 subfolder during runtime. This is common with libraries like SkiaSharp and HarfBuzzSharp because they expect the native DLLs to exist in the main execution path, not inside architecture folders. A common workaround is to manually copy the x64 native DLLs (libHarfBuzzSharp.dll and libSkiaSharp.dll) directly into the main NETBin folder instead of keeping them only under x64. Another option is adding custom load logic using AppDomain.CurrentDomain.AssemblyResolve or native DLL resolver code inside the extension startup. Since your environment is cloud-managed, checking IIS settings may help, but the issue is more likely related to native DLL resolution rather than missing files. If timelines are tight, trying the manual DLL placement workaround is probably the fastest option before moving to a separate .NET Web API solution.
Hi Gonçalo,
Unfortunately, the WeTransfer has expired, so I cannot take a look. Did you explicitly mark the right DLL as to be included on deploy? On the Resources tab, you need to select the DLL and set the Deploy Action to "Copy to Binaries directory".
Hello Kilian,
I've generated a new link for you to download: https://we.tl/t-ZyKTVUetvCU3GfcK
Yes, I've set those properties on the DLLs. These have the "Ignore" setting:
These have the "Copy to Binaries directory" setting:
And these have the "Ignore" setting:
So he should be forced to use the X64 dlls. But it still returns the same error.
I tried to publish the downloaded Extension, but it gives an error on publish: "The type or namespace name 'SautinSoft' could not be found". When I open the project in VS, it indeed shows SautinSoft is not present. Which is kinda strange, as when I open NuGet, it says it's installed.
If you uninstall the SautinSoft DLL and install it again, the publish error still happens ?
I needed to reference the DLL again, then it published fine. Now trying to see where the DLLs end up, stay tuned...
Ok, the DLLs do end up in the bin2 directory (the directory where external DLLs end up), so that's not the problem:
Ok, can confirm I get the same error as you did now ("Unable to load library").
Yep, the error is very strange. Can't wrap my head around this one. I'm not the most savy when it comes to pure .NET and this one is beyond me.
Thank you for your help Kilian. It works "fine". It's not slow for me (under 5 seconds), though I have some issues with the images. But that's a whole different story. I'll mark your last comment as the solution.And again, thanks for the help.
Regards
You're most welcome, glad I could be of help!