静态和动态链接使用不同版本的Visual Studio生成的DLL

静态和动态链接使用不同版本的Visual Studio生成的DLL

问题描述:

这是我正在寻求反馈的情况:

here's the situation I'm looking for feedback on:

  1. 在工作中,我的职责之一是维护几个旧版应用程序,我们将其中一个称为"LegacyApp".它始终使用VS 6.0进行编译. (而且最近没有多动.)
  2. 它使用API​​提供对某些专用硬件的访问.此API由我公司的另一个小组生产.我们将这个API称为"ControllerAPI".它始终使用VS 6.0进行编译.
  3. LegacyApp的开发人员还围绕ControllerAPI编写了包装DLL,LegacyApp将使用该DLL.我们将其称为"WrapperAPI".我有责任维持这一点.它始终使用VS 6.0进行编译.
  4. WrapperAPI与ControllerAPI静态链接.
  5. LegacyApp针对WrapperAPI动态着墨.
  6. 在下一个版本中,构成ControllerAPI的小组已经开始使用VS 2008而不是VS 6.0进行编译,直到现在为止.

所以,这是我的问题:

  1. 由于WrapperAPI与ControllerAPI静态链接,因此我需要在VS 2008中编译WrapperApi吗?那是对的吗? (我已经这样做了,在这种情况下是一个简单的步骤.)
  2. 由于LegacyApp与WrapperAPI动态链接,我可以继续在VS 6.0中编译LegacyApp吗?如果是这样,我在WrapperAPI编译中是否需要做任何事情以确保仍然如此.还是我需要在VS 2008中编译旧版应用程序,而我目前不希望这样做.

因此,我的问题归结为彼此运行已使用不同版本的Visual Studio编译的Apps和Dll,以及是否以静态或动态方式链接各个层是否有所不同.

So, my question boils down to running Apps and Dlls with each other that have been compiled with different versions of Visual Studio, and whether or not it makes a difference if the various layers are linked statically or dynamically.

感谢您的反馈意见

如果从ControllerAPI和WrapperAPI导出的函数的签名未更改,则您的绑定应该是精细的,静态的或动态的.

If the signatures of the functions exported from ControllerAPI and WrapperAPI have not changed, your bindings should be fine, static or dynamic.

但是,如果函数使用的类型和对象(输入,输出,返回参数)依赖于外部库;那么您可能会遇到问题.

However, if the types and objects used by the functions (input, output, return parameters) are dependent on an external library; then you may have issues.

例如,假设如果ControllerAPI用一个版本的C运行时分配内存,而WrapperAPI希望能够自己释放它,那么在这种情况下,它们都需要针对同一版本的C运行时进行链接.如果您在VS2008中重新创建了该项目,而不是导入和升级该项目,则您的默认编译目标和导入的库可能已更改.在使用MFC,ATL等已知类型创建的库中也可以观察到类似的问题.

For example, say if ControllerAPI allocates memory with one version of the C runtime, and WrapperAPI expects to be able to free it on it's own- then in this case they both need to be linked against the same version of the C runtime. If you recreated the project in VS2008 instead of importing and upgrading it- then your default compile targets and imported libraries may have changed. Similar issues can be observed in libraries created with types known to MFC, ATL, etc.

不幸的是,您将需要手动检查这些情况,但是如果您可以检查以下项目,则可以.我还应注意,还将在任意两个给定的Visual Studio版本之间,甚至在针对不同编译目标或平台SDK版本的任何两个版本之间,对这些内容进行检查.

Unfortunately, you will need to check over these scenarios by hand, but if you can check off the following items, you should be fine. I should also note that these things would also be checked between any two given versions of Visual Studio and even any two builds against different compile targets or versions of the Platform SDK.

  1. 在任何情况下,两个DLL都不需知道另一个DLL链接的引用(内存/句柄/资源分配).但是,如果WrapperAPI负责处理ControllerAPI中的项目并进行适当处理(例如,ControllerAPI分配一些东西,WrapperAPI使用它,然后将其交回ControllerAPI进行释放/销毁),这是可以的.
  2. 两个DLL使用的结构中没有内存对齐差异.
  3. 已定义的参数类型未更改.当心一个版本声明一个32位类型的变量的情况,但是在VS2008中重新编译时,在某些编译目标(LONG)下可能是64位.
  4. 对于导出/导入的DLL函数以及任何函数参数类型,调用约定(cdecl/pascal/etc.)均未更改.