XLL "not a valid add-in" 使用 Platform Toolset Visual Studio 2019 编译
XLL is "not a valid add-in" compilation with Platform Toolset Visual Studio 2019
Excel 的 XLL 加载项是在一段时间前（最初是 1990 年代后期，在 2013 年进行了一些修改）用 C++（由其他人）开发的。虽然我可以使用 VS2019 和平台工具集 "vs142"（与 VS2019 关联）编译插件而没有报告错误，但当使用插件管理器将 xll 添加到 Excel 时，Excel抱怨“...xll 不是有效的加载项”。如果我修改项目，在 VS2019 中 仅 使得配置 属性 Platform Toolset 为 "vs100 (Visual Studio 10)" 然后加载项编译并可以正确注册Excel.
中的工作加载项
在使用 Platform Toolset vs142 重建解决方案（没有错误）后，我在警告列表中看到的主要区别是代码“#pragma EXPORT”中的任何地方都有一个指令，有一个警告
“预期 'string'；发现 'user-defined string literal'。
这是使用 Toolset vs100 重建解决方案时不是的警告。
EXPORT 在项目中定义如下（我认为样板遵循 Dalton 书中关于 C/C++ 和 Excel 的财务插件的一些示例。）
// 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__)
由于平台工具集（和 C++ 版本？），我不太确定从哪里开始调和这种差异？为了继续推进这个项目，我希望能够使用最新版本的 VS 和最新的工具集，因此帮助理解必须进行修改的内容和原因将不胜感激。
这 warning/error 似乎与各种版本的 MSVC 编译器的预处理器处理 #pragma comment() 行中的字符串文字连接的不同方式有关（见下面的注释）。通过在（引用的）文字和 __FUNCxxx__ 宏之间添加空格，警告消失（这很可能会解决导致 "not a valid add-in" 问题的链接器问题）。
假设 'problem' 出现在 VS-2015 版本中，可以使用以下代码绕过此问题：
#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
您 可能 能够将 'space-added' 版本与早期编译器一起使用，但是，我添加了遵循哲学 "If it ain't broke, don't fix it!"
用于其他版本的 _MSC_VER 宏的值为 listed here。
注意：this Microsoft web-page 中给出的示例包括字符串文字和预定义宏之间的空格：
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__ )
Excel 的 XLL 加载项是在一段时间前（最初是 1990 年代后期，在 2013 年进行了一些修改）用 C++（由其他人）开发的。虽然我可以使用 VS2019 和平台工具集 "vs142"（与 VS2019 关联）编译插件而没有报告错误，但当使用插件管理器将 xll 添加到 Excel 时，Excel抱怨“...xll 不是有效的加载项”。如果我修改项目，在 VS2019 中 仅 使得配置 属性 Platform Toolset 为 "vs100 (Visual Studio 10)" 然后加载项编译并可以正确注册Excel.
中的工作加载项在使用 Platform Toolset vs142 重建解决方案（没有错误）后，我在警告列表中看到的主要区别是代码“#pragma EXPORT”中的任何地方都有一个指令，有一个警告 “预期 'string'；发现 'user-defined string literal'。 这是使用 Toolset vs100 重建解决方案时不是的警告。
EXPORT 在项目中定义如下（我认为样板遵循 Dalton 书中关于 C/C++ 和 Excel 的财务插件的一些示例。）
// 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__)
由于平台工具集（和 C++ 版本？），我不太确定从哪里开始调和这种差异？为了继续推进这个项目，我希望能够使用最新版本的 VS 和最新的工具集，因此帮助理解必须进行修改的内容和原因将不胜感激。
这 warning/error 似乎与各种版本的 MSVC 编译器的预处理器处理 #pragma comment() 行中的字符串文字连接的不同方式有关（见下面的注释）。通过在（引用的）文字和 __FUNCxxx__ 宏之间添加空格，警告消失（这很可能会解决导致 "not a valid add-in" 问题的链接器问题）。
假设 'problem' 出现在 VS-2015 版本中，可以使用以下代码绕过此问题：
#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
您 可能 能够将 'space-added' 版本与早期编译器一起使用，但是，我添加了遵循哲学 "If it ain't broke, don't fix it!"
用于其他版本的 _MSC_VER 宏的值为 listed here。
注意：this Microsoft web-page 中给出的示例包括字符串文字和预定义宏之间的空格：
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__ )