Gerrit-Jan Linker
|
The drawback I have found when using the described technique is that with late binding no named enums can be used. Suppose I have defined an enum in my dll project as: Public Enum MyEnum One = 1 Two = 2 End Enum In my executable program, having a statically linked ActiveX dll linked, I can use this enum in code like this: Dim lngChoice as Long lngChoice = MyDLLProject.MyEnum.One When using late binding this cannot be used anymore. We will be forced to use: Dim lngChoice as Long lngChoice = 1 Of course this can also be fixed using conditional compilation. It discourages me however from using enums however. Conclusion: My conclusion is that with the technique described above classic Visual Basic - VB5 and VB6 - can be used to write libraries of dlls with reusable code without having to worry about the versioning problems. One thing that you should have to do yourself is ensuring your code is backwards compatible. You must ensure that the new dll being called by the old executables still exhibits itself in the same way as before. If you change the behavior of the dll the executable programs will obviously fail. This is the origin of the reason why VB creates a new GUID. Every time the signature (public methods an properties) of a class changes the GUID will be changed to a new one. It does not make sense however when you just add new code to the project. Care should be taken when changing the existing code of classes.
|