Question

There’s a class which is compiled into a dll

//HeaderFile.h  //version 1.0 class __declspec(dllexport) A {     int variable; //member functions omitted for clarity };  //implementation file omitted for clarity 

You build an exe which uses above class from the dll it was compiled into

#include 'HeaderFile.h' int main() {     A *obj = new A();     obj->CallSomeFuncOnObj();      //     //whatever     // } 

Up til now your program is working fine. But now you recompile your dll with the following code

//HeaderFile.h //version 2.0 class __declspec(dllexport) A {     int variable;     int anotherVariable; //member functions omitted for clarity };  //implementation file omitted for clarity 

and you do not recompile your exe but start using the recompiled dll from the old exe. What will happen now is that your exe has the code that will allocate memory = sizeof(class A version 1.0) but the constructor in your new dll has code that assumes it is being passed a memory block = sizeof(class A version 2.0). There’s an integer’s worth size difference between the two – a recipe for unpredictability.

A similar example is shown in the first chapter of an excellent book – Essential COM by Don Box. Now for the question. In a similar situation in c#(or any other .Net languare) what would happen?

Answer 1

In COM, your DLL implements an object factory: The DLL creates the object itself in order to avoid such ‘syncho’ problems. In .NET, the CLR instantiates the object based on type knowledge pulled from the DLL where the type is implemented. In both cases, the problem you mention is avoided.