An XLL add-in for Excel was developed in C++ (by someone else) some time ago (originally late 1990s, with some modifications in 2013). While I can compile the addin with no reported errors using VS2019 and the Platform Toolset "vs142" (associated with VS2019), when the xll is added to Excel with the Add-In Manager, Excel complains that "...xll is not a valid add-in." If I revise the project, in VS2019, solely such that the configuration property Platform Toolset is "vs100 (Visual Studio 10)" then the add-in compiles and can be registered as a correctly working add-in in Excel.
The main difference I see in the list of warnings after the solution is rebuilt with Platform Toolset vs142 (there are no errors) is that everywhere there is a directive in the code "#pragma EXPORT" there is a warning "expected 'string'; found 'user-defined string literal'. this is not a warning when the solution is rebuilt using Toolset vs100.
The EXPORT is defined in the project as follows (boilerplate following some example in the Dalton book about C/C++ and financial add-ins for Excel, I think.)
// to the world without having to maintain a .def file. Look in any exported
// function for how to use it.
#define EXPORT comment(linker, "/EXPORT:"__FUNCTION__"="__FUNCDNAME__)
I'm not really sure where to begin to reconcile this difference due to the Platform Toolset (and version of C++?) To maintain this project going forward I would like to be able to use the latest versions of VS and the latest toolset, so help in understanding what and why modifications must be made would be greatly appreciated.
This warning/error appears to be related to the different ways various versions of the MSVC compiler's pre-processor handle string-literal concatenations in #pragma comment() lines (see note below). By adding spaces between the (quoted) literals and the __FUNCxxx__ macros, the warning disappears (and this would most likely fix the linker issue causing the "not a valid add-in" problem).
Assuming the 'problem' appeared in the VS-2015 release, one can get round this using the following code:
#if (_MSC_VER >= 1900) // This is for VS-2015 - see link below for others versions
#define EXPORT comment(linker, "/EXPORT:" __FUNCTION__ "=" __FUNCDNAME__)
#else
#define EXPORT comment(linker, "/EXPORT:"__FUNCTION__"="__FUNCDNAME__)
#endif
You may be able to use the 'space-added' version with earlier compilers but, I've added the conditional following the philosophy, "If it ain't broke, don't fix it!"
Values of the _MSC_VER macro to use for other versions are listed here.
NOTE: The example given on this Microsoft web-page includes spaces between string literals and pre-defined macros:
For comments that take a comment-string parameter, you can use a macro in any place where you would use a string literal, provided that the macro expands to a string literal. You can also concatenate any combination of string literals and macros that expand to string literals. For example, the following statement is acceptable:
#pragma comment( user, "Compiled on " __DATE__ " at " __TIME__ )