如何跨越VS版本做出一致的dll的可执行文件？ [英] How to make consistent dll binaries across VS versions?

问题描述

例如，winsock的库的伟大工程，在所有版本的Visual Studio。但我有真正的麻烦在所有的版本中提供了一个一致的二进制文件。在VS 2005编译将无法工作的DLL时挂写在2008年的应用程序，我升级既2K5和2K8到SP1，但结果并没有太大的改变。它的工作原理有些什么好的。但是，当他们有这与C＃应用程序，在C＃应用程序获得访问冲突的错误，但与经典的C ++应用程序，它工作正常。

For instance, winsock libs works great across all versions of the visual studio. But I am having real trouble to provide a consistent binary across all the versions. The dll compiled with VS 2005 won't work when linked to an application written in 2008. I upgraded both 2k5 and 2k8 to SP1, but the results haven't changed much. It works some what ok. But when they include this with a C# app, the C# app gets access violation errors, but with classic C++ application it works fine.

有一个战略，我应该知道什么时候我提供的dll？

Is there a strategy that I should know when I provide dlls ?

推荐答案

首先，不要通过任何比普通的旧数据翻过DLL边界值等。即结构的罚款。类不是。 其次，要确保所有权不转移 - 即通过防空火炮的DLL边界的任何结构的DLL以外永远不会释放。所以，如果你的DLL导出一个X *的getX（）函数，有相应的FreeX（X *）类型功能确保了分配相同的运行负责取消分配。

First, dont pass anything other than plain old data accross DLL boundries. i.e. structs are fine. classes are not. Second, make sure that ownership is not transferred - i.e. any structs passed accross the dll boundry are never deallocated outside the dll. So, if you dll exports a X* GetX() function, there is a corresponding FreeX(X*) type function ensuring that the same runtime that allocated is responsible for de-allocation.

下一页：让您的DLL链接到静态运行时。组建了一个项目从几个第三方comprimising DLS，每个链接并期待不同的运行时，可能不同于预期的应用程序运行时，是一种痛苦，这可能迫使安装程序安装软件的运行时间为7.0，7.1，8.0和9.0 - 其中几种存在于不同的服务包可能会或可能不会引起问题。善待 - 静态链接您的DLL项目

Next: Get your DLLs to link to the static runtime. Putting together a project comprimising dls from several 3rd parties, each linked to and expecting different runtimes, potentially different to the runtime expected by the app, is a pain, potentially forcing the installer software to install runtimes for 7.0, 7.1, 8.0 and 9.0 - several of which exist in different service packs which may or may not cause issues. Be kind - statically link your dll projects.

- 编辑： 你不能直接使用这种方法导出一个C ++类。共享模块之间的类定义意味着你必须有一个均匀的运行时环境，不同的编译器或编译器会产生不同的名字装饰版本。

-- You cannot export a c++ class directly with this approach. Sharing class definitions between modules means you MUST have a homogeneous runtime environment as different compilers or versions of compilers will generate decorated names differently.

您的可以的绕过这个限制，通过导出你的类，而不是作为一个COM界面风格......这是说，当你不能在运行时独立的方式导出类，可以导出接口，它可以easilly声明一个类仅包含纯虚函数使...

You can bypass this restriction by exporting your class instead as a COM style interface... which is to say, while you cannot export a class in a runtime independent way, you CAN export an "interface", which you can easilly make by declaring a class containing only pure virtual functions...

  struct IExportedMethods {
    virtual long __stdcall AMethod(void)=0;
  };
  // with the win32 macros:
  interface IExportedMethods {
    STDMETHOD_(long,AMethod)(THIS)PURE;
  };

在你的类定义，你从这个接口继承：

In your class definition, you inherit from this interface:

  class CMyObject: public IExportedMethods { ...

您可以通过C厂的方法导出这样的接口：

You can export interfaces like this by making C factory methods:

  extern "C" __declspec(dllexport) IExportedClass* WINAPI CreateMyExportedObject(){
    return new CMyObject; 
  }

这是出口的编译器的版本和运行独立的阶级版本的非常轻量级的方式。请注意，您仍然无法删除其中之一。您必须包括释放功能的DLL或接口的成员。由于接口的成员也可能是这样的：

This is a very lightweight way of exporting compiler version and runtime independent class versions. Note that you still cannot delete one of these. You Must include a release function as a member of the dll or the interface. As a member of the interface it could look like this:

  interface IExportedMethods {
    STDMETHOD_(void) Release(THIS) PURE; };
  class CMyObject : public IExportedMethods {
    STDMETHODIMP_(void) Release(){
      delete this;
    }
  };

您可以把这个想法，并进一步运行它 - 自IUnknown继承你的接口，实现裁判计数AddRef和Release方法，以及以对的QueryInterface V2接口或其他功能的能力。最后，使用DllCreateClassObject作为创建对象并获取必要的COM注册要去的手段。这一切都是可选但是，您可以easilly逃脱通过一个C函数访问一个简单的接口定义。

You can take this idea and run further with it - inherit your interface from IUnknown, implement ref counted AddRef and Release methods as well as the ability to QueryInterface for v2 interfaces or other features. And finally, use DllCreateClassObject as the means to create your object and get the necessary COM registration going. All this is optional however, you can easilly get away with a simple interface definition accessed through a C function.

这篇关于如何跨越VS版本做出一致的dll的可执行文件？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！