C++ Excel Add-in loading error: XLL file is loaded by Excel as text file

Question

I'm building XLL add-ins for Excel, using C++ and XLW library.

It works fine on my PC, and on many others. But in some cases, when I drag the XLL into a new Excel window, this error shows up:

The file you are trying to open, 'my_addin.xll', is in a different format than specified by the file extension. Verify that the file is not corrupted and is from a trusted source before opening the file. Do you want to open the file now?

If click yes, then Excel will open the XLL as a text file, showing something like this:

MZÿÿ¸@ Í!¸LÍ!This program cannot be run in DOS mode.

right at the first row. This is not expected to happen. What could be the reason for that?

This is the system configuration of all machines:

• Microsoft Windows 7 Professional 64-bit (operational system)
• Microsoft Excel 2010 32-bit

Demogorgon

a missing external dll or runtime dll ? did you build with the MT flag ? can you check with dll dependency ? Also you need a x86 xll for excel 32 bits and a x64 xll for excel 64 bits. – Catch

Figured it out that I built under MT but by mistake linked with a lib meant to be used in MD. But why some users can use it some cannot? – Demogorgon

Ok, I think that for the users for whom it works, they must have the lib installed by another software. – Catch

This one is not the same, but is closely related: https://mcmap.net/q/1482330/-c-64-bit-excel-add-in-xll-is-not-loading-correctly-in-64-bit-excel – Ethelynethene

Answer 1

To summarize, the error code This program cannot be run in DOS mode. is usually related to one of the following issues:

1. The XLL is built with the /MD flag, but end-users do not have the required CRT DLLs.

2. The XLL is compiled with the wrong platform; e.g. Platform x64 being used for building your XLL, and then it is loaded in 32-bit Excel (or vice-versa).

3. There is a missing external DLL dependency.

4. There is an external DLL dependency which has been built with the /MD flag (multithread-specific and DLL-specific version of the run-time library). In this case, there is no problem if end-users have the correct version of the CRT (the one that has been used to build the external DLL). Otherwise it is strongly recommended to rebuild your external DLL (if possible) with the /MT flag (multithread, static version of the run-time library). Or even better, to statically link it to your XLL (using static .lib file as the output of the build of your third party component).

I believe the last one might be your case.

Catch