我们有一个（非常大的）现有的ActiveX控件的代码库，为了与KML映射数据交互，我想集成libkml ，而不是重新发明轮子。 问题是，我是一个相对较新的Windows开发人员，来自Linux世界，我真的不确定集成第三方库的正确方法是什么。 谢天谢地， libkml提供MSVCC编译项目，所以移植不成问题。 我想我有一些我可以想到的select：
直接build立和链接库 。 我们已经有了一个解决项目文件的“主”项目; 我可以将libkml项目添加到该解决scheme，但我宁愿不。 libkml代码不太可能会根据我们应用程序的代码而改变。
静态链接到由libkml生成的.lib文件 。 这是没有吸引力的，因为libkml解决scheme中有六个.lib文件，并且在链接器选项中手动指定它们似乎是libkml 。
将代码按原样包装在一个DLL中 。 也许与COM？ 看来如果我这样做没有任何翻译，我最终会有很多开销，因为我对COM很不熟悉，所以我不知道在展示所有的function时会涉及多less工作，喜欢通过COM使用。 图书馆是相当大的，有很多类使用，如果我不得不手动编写代码来暴露这一切，我会犹豫要走这条路线。
编写包装代码来抽象我需要的function，将其打包到一个COM DLL中，并与之交互 。 我想这似乎是合理的，但是我很难确定需要多less抽象，因为我还没有编写使用libkml的代码。
让我重申：我还没有编写与libkml交互的代码，所以这主要是实验性的。 选项1和2也是复杂的事实， libkml额外依赖于另外三个外部库也在.lib文件（我不得不重新编译以获得代码生成标志排列）。 目标显然是让代码工作，但可维护性和源树组织也是目标，所以我倾向于选项3和4，但我不知道在Windows上接近这些选项的最佳方法。
键入六个文件名，或者使用#pragma comment（lib，“foo.lib”）的声明式样式，与将其转换成DLL或COM服务器所需的工作相比，是小土豆。
这个分布严重偏向于将其用作静态链接库。 只有不明确的声明可以用__declspec（dllexport）把它变成一个DLL。 它们只存在于第三方依赖关系中。 当然，所有使用不同的#define，您将通过在项目的预处理器定义中键入一堆名称。
而且，由于您正在COM服务器中使用它，实际上在运行时会加载该DLL，所以很难实现。 当COM创建你的控件实例时，DLL的搜索路径将是客户端应用程序，不可能靠近你部署DLL的地方。
使它成为一个COM服务器是很多工作，你将不得不自己写所有的接口粘合剂。 同样，源代码中没有任何东西可以帮助完成这个任务。
您也可以将所需的所有功能包装在非COM-dll中。 Visual Studio支持创建一个静态的包装库，当链接时，将使您的程序使用DLL。 这样你只有一个依赖项来指定而不是六个。
除此之外，指定六个依赖关系有什么问题。 我认为有一个很好的理由，那就是六个独立的库，而不是一个，所以谨慎地指定你实际使用的是哪个部分。
也许我在这里错过了一些东西，但是我真的没有看到（1）有什么问题。 我认为，即使您有多个使用libkml的项目，只需将libkml的项目文件插入到您的解决方案文件中，指定依赖关系，即可完成。 这很简单 即使解决方案（2）也很简单。 如果图书馆改变了，你重建 – 无论如何你都需要这样做。
我没有看到（3）或（4）是必要的甚至是需要的。 对我来说，这听起来像是很多目标（源代码树组织和可维护性）的工作，我甚至不确定这些选项是否真的符合。 事实上，你自己说过：“libkml代码与我们应用程序的代码相关的可能性不大。”
我多年来发现的就是保持简单。 如果重建KML可能会耗费时间，请抓取库并静态链接到库。 是的，还有其他的依赖关系，但是你会设置一次并完成，希望不要再担心它。 否则，坚持在项目中继续前进。 我认为有必要问一下在这个问题上花费很多时间是否值得遇到麻烦。