如何在C+中定义入口点+/具有命令行参数/条目的CLI DLL

cl.exe中有一个选项，可以使用命令行属性/entry在DLL中定义自定义入口点。不幸的是，它没有提供如何使用它的示例

< P>创建了支持/CLR的托管C++ DLL，用“开始”替换主函数名：

然后，我尝试使用以下BAT命令从命令行编译此DLL：

"c:\Program Files\Microsoft Visual Studio 12.0\VC\bin\cl.exe" ^
    /clr /Fo /Z7 /D "NDEBUG" ^
    /ENTRY:Start ^
    "..\Links\Links.cpp"

不幸的是，我遇到了以下错误：

LNK1561: Entry point must be defined

问题：我到底应该传递什么作为/ENTRY参数

编辑：正如Hans在下面的评论中提到的，曾经是DLL入口点的函数需要有另一个签名，所以我更正了上面的示例。下面介绍的函数是EXE文件的入口点示例，特别是因为它的参数中包含托管类型

int Start(array<String ^> ^ argc)
{
    return 0;
}

int开始（数组^argc）
{
返回0；
}
我真傻。选项/条目是link.exe的参数，而不是cl.exe的参数

使用下面的BAT脚本，我可以强制我的程序集具有自定义入口点。唯一的问题是，出于某种原因，在这种情况下，链接器需要直接使用/SUBSYSTEM选项设置项目的类型

"c:\Program Files\Microsoft Visual Studio 12.0\VC\bin\link.exe" ^
    /DLL /ENTRY:Start ^
    /SUBSYSTEM:CONSOLE ^
    /WX ^
    /OUT:Links.dll ^
    "Links.obj"

在托管程序集上指定/Engult>代码是一个非常糟糕的想法，因为现在C++运行库中的所有.NETFramework支持代码都不会执行。全局C++对象的初始化器也不会有机会运行。您可能会在工作者线程上获得内存泄漏，因为C++运行库在需要时足够智能地执行线程本地初始化，但因为它没有接收线程分离事件，所以它无法清理。另一方面，C++/CLI程序集始终动态链接到运行时DLL，因此至少库
DllMain
将接收线程通知，并且运行时本身使用的资源不会泄漏

只需保留库提供的
DllMainCRTStartup
入口点，并提供库入口点将调用的名为
DllMain
的函数

关于MSDN，有大量关于C++/CLI托管程序集中初始化代码的文档：




需要从中去掉的一个重要内容是
DllMain
签名（它也不是实际的入口点，它是从库提供的入口点调用的）是

DLL的入口点一直是，现在仍然是C++/CLI程序集的入口点，一个名为“DllMain”的函数。其签名与Start（）方法完全不同。链接器没有警告您的错误。结果会很糟糕，你得不到字符串，返回值很重要，它会被多次调用。@Hans Passant:没错，我试图用两种方式编译这个项目-作为DLL或EXE，如果输出是EXE文件，这个问题的第一个版本中提到的函数可以被编译，如果我尝试将其编译为DLL，它会通知我函数的签名错误，因此我将其更正为DLL的函数。对于DLL入口点，这仍然不是正确的签名。此外，在托管程序集上指定 > />条目< /代码>是一个非常糟糕的想法，因为现在C++运行库中的所有.NETFramework支持代码都不会执行。只需保留库提供的入口点，并提供一个名为
DllMain
的函数，库入口点将调用该函数。谢谢，尽管，无论如何，我想提及的是，我能够将新的C#WinForms项目添加到我的解决方案中，并从我的自定义入口点调用它，因此我认为DllMainCRTStartup中的代码并不是那么重要，即使建议使用它。@SkyScanner:我添加了一些关于某些特定分支的更多解释。
"c:\Program Files\Microsoft Visual Studio 12.0\VC\bin\link.exe" ^
    /DLL /ENTRY:Start ^
    /SUBSYSTEM:CONSOLE ^
    /WX ^
    /OUT:Links.dll ^
    "Links.obj"

BOOL WINAPI DllMain(
  _In_  HINSTANCE hinstDLL,
  _In_  DWORD fdwReason,
  _In_  LPVOID lpvReserved
);