如何将本地DLL与托管应用程序捆绑在一起？ [英] How to bundle native DLLs with a managed application?

问题描述

在一个.NET项目中，我有一些从本机DLL导入的函数。

目前要将本机DLL添加到项目中，它们被复制到C＃项目的根和他们的属性构建动作设置为复制到输出目录。

是否有更好的工作流捆绑本机DLL？

解决方案

如果您想单独执行部署，则将DLL作为资源嵌入到清单中。这是通常用于创建通用二进制文件的方法，可以从单个文件在X86或X64平台上运行。在这种情况下，您将64位版本嵌入到32位版本中，并在需要时在运行时解压缩。您可以看到使用 Sysinternals 二进制文件的操作。

在您的情况下，您将在受管理的可执行文件中嵌入本机二进制文件，然后在运行时将其作为IO流加载，或者将其从提取的路径中引用。在任何一种情况下，您都不用担心资源丢失，因为它是项目的一部分。

如果你决定去那条路线，那么如何它已经提供了几次。这是一个这样的问题：
将非托管dll嵌入到管理C＃dll

On a .NET project, I have a couple of functions imported from native DLLs.

Currently to add the native DLLs to the project, they are copied to the root of the C# project and their property Build action is set to Copy to output directory.

Is there a better workflow for bundling native DLLs?

解决方案

One option, which is particularly useful if you want single exe deployment, is to embed the DLL(s) into your manifest as Resources. This is a similar approach to what is often used to create "universal binaries" which can run on either X86 or X64 platforms from a single file. In that case you embed the 64-bit version inside the 32-bit version and extract it at runtime when needed. You can see that in action with the Sysinternals binaries.

In your case, you would embed a native binary within the managed executable, then either load it as an IO stream at runtime or extract it and reference it from the extracted path. In either case, you never have to worry about "losing" the resource because it's part of your project.

If you decide to go that route, the answer to how to do it has been provided several times over. Here's one such question: Embedding unmanaged dll into a managed C# dll

这篇关于如何将本地DLL与托管应用程序捆绑在一起？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！