why does modifying a dll requires to rebuild the client application

why does modifying a dll requires to rebuild the client application

• k000der

  This is not accurate at all!

  This only occurs if you are exporting virtual or pure classes from within a DLL and you change the signature of those classes (the vtbl layout), if you are just exporting functions, you can change the body of those exported functions freely and have no problems making calls because the ordinal values for those don't change.

  The problem you expose is solved if you understand one of the most important COM's (Component Object Model) philosophy principles.

  "Once you have deployed your library, you can not change the interfaces your classes implement!"

  If you need additional functionality, create another interface with the new signature (methods) and implement it. Notify your users about the new functionality available through the new interface.

  With interfaces you can obtain far more advanced behaviors (polymorphic behaviors) from your objects so they can behave in different manners when needed.

  Use Class Factories for those objects available in your library so this is the only way to use them and guarantees consistency in the behavior you created.

  There are also some aspects you have to take into account (Reference Counting, Thread Safety etc) if you are going to provide advanced functionality.

  If you meet the above mentioned philosophy, you won't have any problems in the future once your library has been deployed and plugged into foreign applications.

  There are many books that dig deeply into such aspects of COM so you can refer to them for more information (just enter this in google search "COM books").

  :)

   

  
  
  

• jcorra

  Vishal Srivastav,

  This is an excellent question. In fact, it's such a great question, that many programmers before you (and me too) have asked this question. From what I have read, this situation is one of the prime motivators behind the strict versioning policy that the .NET Framework requires of its Common Language Runtime and the assemblies produced by all .NET compilers. This kind of thing was a HUGE problem for pre-.NET and COM development.

  The most obvious reason this linkage fails is that if the compiler allowed it without checking, then many executables can be built against the original DLL. In fact, entire libraries can be built against it, that will have client applications themselves using a virtual function table as a data structure representing actual objects that rely on function pointers to the original code. If the DLL is updated, usually the function signatures will be changed in the process, and so certain source elements, when executed, will cause the resultant linked applications to fail catastophically. There will be incorrect memory allocations, buffer overruns and access violations. In a simple program, this may very well not have any deleterious consequences at all, but, in a more complex scenario it could be a really serious security hazard.

  My explanation is overly simplistic. If you really are interested in a thorough explanation, Google the phrase "DLL Hell", of get a copy of Don Box's book, "Essential COM".

  This article clearly explains the issues: http://www.codeproject.com/dll/The_DLL_Hell.asp

  
  
• why does modifying a dll requires to rebuild the client application