STA、MTA 冲突警告 重要吗？
我最近开始为本机 C++ 库编写 C++/CLI 包装器。我现在收到此编译警告
“警告 LNK4249：指令 '/CLRTHREADATTRIBUTE:STA' 与命令行冲突；被忽略”
我的 c++/cli 包装器在链接器的命令行参数中为 MTA 设置，但我不知道是什么文件或项目正在尝试发出 STA 指令。
我读了足够多的书，开始担心 .NET 会强制库变成多线程。我读到这主要影响我的应用程序对 COM 的使用，但我不太确定我的 DLL 是否或在何处使用 COM。我使用互操作服务来编组字符串数据，并使用“msclr\auto_gcroot.h”从非托管类指向托管类。在正在包装的本机 C++ 库中，我包含以下标头：
#include <afxwin.h> // MFC core and standard components
#include <afxext.h> // MFC extensions
#include <afxmt.h>
#include "Winsock2.h."
#include <time.h>
是否有人有任何建议可以帮助我避免将来的痛苦经历，或者我应该不担心它？
I recently started writing a C++/CLI wrapper for a native c++ library. I'm now getting this compile warning
"warning LNK4249: directive '/CLRTHREADATTRIBUTE:STA' conflicts with command line; ignored"
My c++/cli wrapper is set up for MTA in the linker's command line arguments, but I have no idea what file or project is trying to give the STA directive.
I did enough reading to get worried about .NET forcing libraries to become multi-threaded. I've read that this mostly affects my application's use of COM, but I am not really sure if or where my DLL uses COM. I use the interop services to marshal string data and am using 'msclr\auto_gcroot.h' to point to managed classes from unmanaged ones. In the native c++ library that is being wrapped, I include the following headers:
#include <afxwin.h> // MFC core and standard components
#include <afxext.h> // MFC extensions
#include <afxmt.h>
#include "Winsock2.h."
#include <time.h>
Does anybody have any advice that could help me avoid painful experiences in the future, or should I just not worry about it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
到目前为止，一切都很好。我还没有看到任何真正的问题；我认为这只是因为MFC是一个单线程库，所以它想这样编译。因此，就我而言，我认为只要我处理所有 MFC 对象以及非线程安全的对象，我就可以了。
So far so good. I haven't seen any real problems with this; I think it is just because MFC is a single threaded library, so it wants to compile that way. So, for my case, I think as long as I treat all MFC objects and such as not thread-safe I'll be okay.