将 C# 应用程序的引用添加到未使用 /clr 编译的 DLL？
我正在使用 Visual Studio 2008 构建一个包含两个项目的解决方案：一个 C# 控制台应用程序和一个 C++ DLL。我希望应用程序使用 P/Invoke 从 dll 调用函数。因此，我尝试添加 dll 作为对 C# 应用程序的引用。但是，当我尝试“添加引用”命令时，Visual Studio 不会让我执行此操作，除非我在 dll 上设置 /clr 属性（在“配置属性：常规”下）。现在，我认为 P/Invoke 可以处理普通的 win32 dll。事实上，如果我在没有 /clr 的情况下构建 dll，然后手动将其复制到 bin/Debug，那么应用程序运行正常。那么为什么需要/clr来添加dll作为引用呢？如果 VS 不允许我添加它，是否有一些（干净的）解决方法以便我的应用程序找到该 dll？
我看到有人在这里遇到了类似的问题（尽管使用的是第 3 方 dll）： 无法添加 VS 2008 的 DLL 引用他得到的答案是构建一个包装器。但这并不是真正必要的，因为应用程序可以很好地使用 dll；只是“添加引用”步骤不起作用。此外，包装器代码是否不需要引用 dll，从而引发与之前相同的问题？我真的很想要一个根本不涉及编写包装器的答案。
I'm using Visual Studio 2008 to build a Solution with two Projects: a C# Console App and a C++ DLL. I want the app to call a function from the dll using P/Invoke. Therefore I'm trying to add the dll as a Reference to the C# app. But when I try the Add Reference command, Visual Studio won't let me do it unless I set the /clr property on the dll (under Configuration Properties:General). Now, I thought that P/Invoke could handle plain-old win32 dlls. Indeed, if I build my dll without /clr and just copy it by hand to bin/Debug, then the app runs fine. So why is /clr required to add the dll as a reference? And if VS won't let me add it, is there some (clean) workaround so that my app finds the dll?
I see that someone had a similar issue here (though with a 3rd-party dll):
Unable to add a DLL Reference to VS 2008 The answer he got was to build a wrapper. But this isn't really necessary, since the app can use the dll just fine; it's just the Add Reference step that doesn't work. And besides, won't the wrapper code need a reference to the dll, raising the same problem as before? I'd really like an answer that doesn't involve writing a wrapper at all.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
为什么不添加一个构建后步骤将非托管 DLL 复制到项目目录呢？您不需要“引用”就能够引用非托管 DLL，听起来您遇到的唯一问题是由于文件没有自动复制到搜索路径中。
Why not just add a post-build step to copy your unmanaged DLL to your project directory? You don't need a "reference" to be able to refer to an unmanaged DLL, and it sounds like the only problem you're experiencing is due to the file not being automatically copied into the search path.
在 C++ DLL 上使用 PInvoke 时，无需添加引用。仅当您在另一个 DLL 中调用托管代码时才需要引用。只需将 C++ DLL 放在同一目录中并将其名称添加到
DllImport属性中即可When using PInvoke on a C++ DLL, it is not necessary to add a reference. References are only needed when you are calling managed code in another DLL. Simply put the C++ DLL in the same directory and add it's name to the
DllImportattribute理论上，您可以将 C++-DLL 作为链接资源添加到 C#-DLL。这将使 .NET 复制您的 C++-DLL，无论其将 C#-DLL 复制到何处，甚至复制到 GAC 中。
从理论上讲，这意味着存在一些缺点：
因此，如果以上都不适合您，您可以调用 csc.exe，如下所示：
希望这可能有所帮助！
Theoretically you could add the C++-DLL as a linked resource to your C#-DLL. This would make .NET copy your C++-DLL wherever it copies the C#-DLL even into the GAC.
Theoretically means that there are some disadvantages:
So if none of the above is a no-go for you you can call csc.exe the following:
Hope this may help!
通过执行以下操作解决了类似的问题：
在所有开发计算机上，将相关 dll-s 的路径添加到 PATH 环境变量中。这样，所有开发人员都可以调试引用非托管 dll 的程序集的所有可执行文件，而无需为每个可执行文件编写构建后脚本。
对于生产，每晚 msbuild 任务将所有内容构建到单个文件夹中，并且标记为“内容/始终复制”的非托管 dll-s 会自动包含在它们所属的一个程序集的构建中。< /p>
Solved a similar issue by doing the following:
On all development machines, added the path to dll-s in question to PATH enviromental variable. That way all the developers could debug all the executables that have a reference to the assembly with unmanaged dll-s, without the need to write a post build script for every executable.
For production, nightly msbuild task builds everything to a single folder, and the unmanaged dll-s that are marked as "Content/Always copy" are automatically included with the build of that one assembly that they are a part of.