有没有人知道部署本机(没有COM,没有.NET)ANSI C Windows共享库的最佳实践指南？
我们的产品使用zlib,我们在下载页面上分发预先构建的二进制文件,这些文件与官方zlib页面上的不同.我猜这是因为避免混合C运行时.官方版本是使用VC++ 6.0针对msvcrt构建的,而VS.NET/2005/2008将使用msvcrt71/80/90.
我想要做的是创建VS2005/8解决方案和项目,这些解决方案和项目将为我们正确构建zlib并将它们分配到我们现在所拥有的位置.我想仔细地做这件事,并分发一个适当的有用的包,然后我也可以发送给zlib的策展人,以包含在他们的源代码发行版中.但是,找到可靠的信息已被证明是麻烦的.我有很多关于Win32编程的书籍,我在网上发现了很多文章,但这些文章似乎没有完全描述你真正需要分发的内容.
例如,zlib分发.exp,.lib存根和.def文件,其中fftw分发.def文件,但不分发.lib存根和.exp文件.我想我可以直接转储那些看起来很有用的东西(或者只是反映官方zlib目前的内容),但我想知道为什么它必须存在于它所属的目录中.
是否有很好的例子来源于unix世界的维护良好的Windows发行版？
澄清:
我们分发一个库并向(大多数)Windows用户提供zlib,因为他们通常没有它.我希望我们的zlib构建作为一般组件非常有用,而不仅仅是我们的产品消耗的.dll.我们是开源的并且被广泛使用,因此我们希望使我们的整个构建环境可用并且易于适应您想要使用的任何编译器.
如您所知，混合 C 运行时是一个真正的问题。因此，DLL 发行版的一个维度始终是运行时的选择。有时这不是一个自由的选择。将在运行时由现有应用程序（例如插件）加载的 DLL 必须（通常）与托管应用程序使用的 CRT 选择相匹配。
您可能会想到可以将 CRT 静态链接到 DLL 中并避免出现这种问题。然后出现的问题是，当您必须在 DLL 及其托管应用程序之间传递分配的指针时，因为混合运行时的大部分问题都来自于进程中存在多个malloc()和的实现。free()然而，通过为 DLL 精心设计和实现 API，这可以成为解决方案。
像Mark Rushakoff 的答案中描述的Lua Binaries这样的发行版使用大量的构建自动化来安排使平台和编译器的多种组合可用。维护构建过程对于其团队来说是一项相当大的工作。当一个单独的小组决定为 Lua创建一个Windows 安装程序以便为 Windows 用户提供简单的首次使用体验时，他们决定（我相信这是明智的）为其产品选择一个单一的 CRT 版本，并要求他们提供的所有扩展 DLL与它是针对该单一版本编译的。
作为发布打包的一部分，您应该遵循的一种做法是使用Dependency Walker来验证是否使用了预期的 CRT，并且所有其他依赖项要么是来自托管应用程序安装的系统 DLL，要么也包含在您的包中。Dependency Walker 可以从批处理文件运行，因此可以用作回归测试套件的一部分来自动执行此验证。例如，当发布基于 Lua 的项目时，我从 Makefile 中的 Dependency Walker 下运行最终构建，作为构建安装包的目标的一部分，并使用 perl 脚本检查日志以验证唯一使用的 DLL 是否是这一部分我的安装或来自系统。
正如其他人所说，如果您的 DLL 被不希望使用它进行开发的最终用户使用（例如独立分发的较大应用程序的插件），那么您需要打包的只是 DLL 本身（以及它的任何依赖项）。有最终用户文档等）。在这种情况下，您只需确保 DLL 使用与应用程序相同的运行时即可。
如果 DLL 用于开发人员社区，那么您可能会遇到 Lua 二进制文件的多构建情况。每个分发包都将包含正确构建的 DLL，以及导入库 (.LIB) 和所有文档。对于由 VS 构建的 DLL，预计将与其他编译器的代码进行链接，包含记录实际导出名称的 .DEF 文件可能会很友好。现代 MinGW 实际上并不需要它，但是 Borland C 或可能是 C 以外的语言的用户可以使用他们可以获得的所有帮助。
鉴于最近 Lua、Perl、TCL 和 Python 等动态语言的流行，这些语言通常可以轻松绑定到用 C 实现的库，如果您可以提供对这些语言的绑定，这些用户社区也会非常感激，以及针对选择 CRT 的“本地习惯”编译的二进制文件。