Accessing LibreOffice From IIS 10 Hangs on bootstrap

I have a VB.Net application that opens an ODT file, performs a number of replace operations then saves it as a PDF. When I try to use the same code under IIS 10 as a web service the call to bootstrap does not return. Process Explorer shows that soffice.exe and office.bin are in memory. I have to kill the two processes to continue.

I’ve tried various suggestions related to compiling the application in 32 bit or telling IIS to allow 32 bit applications. Those only produce other errors. I’m using the 4.6.2 dot net framework and the 6.2.5.2 x64 version of LibreOffice and SDK. I’m running Windows 7 on my development machine and have gotten the same results on Windows Server 2019.

What do I need?

To answer my question “What do I need?”, I need a drink. This was horrible. The amount of searching and fiddling required to find out how to run the Libre API deserves an award if you can get it to work. The problems were several.

Libre needs to be initialized. It has a first start wizard. That’s what I think made it not work when running under a different user within IIS. To overcome that required starting soffice.exe with a process where arguments could be provided. Also figuring out which paths need to be forward slashes and which ones need to be back slashes and when to prefix the path with “file:///” was frustrating. It appeared that using pipes was the wrong communication method to connect to the running process. Some errors could only be seen when running outside of IIS. In that environment a command box would pop showing the error. There are so many different versions and kinds of open office that any online help for starting soffice.exe was confusing. In one case prefixing the parameter with 2 dashes threw an error. In other cases it didn’t seem to make a difference. Once I got a list of parameters from the command line call to my version soffice.exe things got a little better.

I want to post a simple example of how this worked for me on IIS 10 using MVC and VB.Net but using the exact same calls I can’t get it to work. I’ve combed through it for an hour and can’t find the difference. It’s a house of cards.

OK. I feel your pain, and I appreciate that your post was 3 years ago, but I have an answer.

It took me hours of research to get this working, and there are many steps involved:

  1. Find the IIS AppPool\ApplicationIdentity (for me it was IIS AppPool\DefaultAppPool on the local IIS Server)
  2. Give that identity read+execute permissions to C:\Program Files\LibreOffice
  3. Create a folder for saving files/PDFs/etc. Grant Full Control permissions to the same identity.
  4. You don’t need to enable 32 bit applications for the application pool - if you’re using the 64 bit version of LibreOffice. It is advised to set Load User Profile to True, but IIS defaulted it to True for me.
  5. Use DCOMCNFG.exe to modify the LibreOffice Service Manager (Ver 1.0) to grant launch, activation and access permissions to the identity.
  6. Note the application identity in DCOMCNFG. For me it was {82154420-0FBF-11d4-8313-005004526AB4}
  7. In RegEdit, go to HKEY_CLASSES_ROOT\CLSID{82154420-0FBF-11d4-8313-005004526AB4}\LocalServer32 (as per the ID you noted in step 6).
  8. Change the default value of the key to include the appropriate start up command line parameters. For me, this was C:\Program Files\LibreOffice\program\soffice.exe -env:UserInstallation=file:///C:/LibreOffice --nodefault --nologo --headless
    Note that C:\LibreOffice was the folder I created for step 3. Also note the URL format of the folder name in the command line.
  9. Voila! IIS can now CreateObject(“com.sun.star.ServiceManager”). Everything else follows nicely from there.
2 Likes

You likely would also want to use --norestore command line parameter. OTOH, --nodefault and --nologo are not needed, when you use --headless.

Excellent suggestion! I was so obsessed with just getting it to work, I didn’t think too much about making it work elegantly. I am still having some problems with w3wp.exe throwing some unexpected exceptions… I don’t think its marshalling the soffice.exe process properly… but I’ll tidy that up as time progresses.

Note that soffice.exe is a launcher, the actual working process is soffice.bin; also note that soffice.exe is a window-mode application, and so the possible console output from soffice.bin will not come to a process that monitors soffice.exe. There is a console launcher, to be used for console case: soffice.com, which tunnels the console output correctly; I don’t know if this is applicable to IIS case, but thought I’d mention it just in case.

1 Like

Thank you Wolfling & Mikekaganski for this lifesaving page. It looks like all the correct info is there but perhaps not explained clearly enough, so here is a quick write-up of the 3 gotchas I had to solve to get it to work, aside from giving read/write permission to IIS AppPool\DefaultAppPool on the working folder:

  1. You MUST run soffice.com instead of soffice.exe, otherwise StdOut can’t be captured and you will also end up with a pop-up window demanding the enter key be pressed, causing a hang.
  1. You MUST manually set the output folder as, strangely, it does NOT default to the folder of the *.docx but instead a folder IIS doesn’t have access to.
  1. You MUST manually set a different environment/profile folder as the default one will be some folder LibreOffice auto-decides is right for the IIS AppPool user which of course the IIS AppPool user won’t have write access to. Otherwise, LibreOffice will hang. This was devilishly difficult to figure out and only was revealed via web research.

(LibreOffice auto-creates the profile folder if it is not present - cool! I made it a sub-folder of my work folder which already had the right permissions set.)

Aside from this, note that I didn’t need to mess with DCOMCNFG.exe because my application just used System.Diagnostics.Process.Start() to launch LibreOffice.

As with any command line tools, the default is the working directory, which is defined by the caller.

Well… It just uses the current user’s profile directory (more specifically, APPDATA), as reported by the operating system. There’s no other reasonable default choice :wink:

Sorry, I didn’t mean my message to be a “critique” of LibreOffice. Logically, you are absolutely correct. But the things in my list could easily be overlooked, especially frustrated programmers working multiple hours on something. Particularly the environment/profile path. Newbies to LibreOffice may be thinking of a typical command line tool and not realizing that a massive desktop package is being loaded into memory behind the scenes (complete with “desktop” settings). I say, the more education we can provide the better!

Sure; and I took your words as a guidance, and added respective things to the documentation.

1 Like

AWESOME. And, if you are part of the LibreOffice team, as a bonus it may be even better to change the software so it produces an error like, “Cannot launch LibreOffice: Cannot open the file C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\LibreOffice\user\registrymodifications.xcu for write access”, rather than just hanging forever. Rather than guessing about the hang, the message would be a giant clue and even Google’able.