Printable View
If you make an activeX dll and set its compatibility to "No Compatibility" what effect does that have on the DLL?
in the help it says
No Compatibility — Compatibility not enforced.
i have this DLL that was set to binary compatibility and all was well with it.. but now all of a sudden when i make changes to it.. i need to recompile all the exes that use it in order for them to work properly.. i thought binary compatibility allowed you to just change the dll??
i dont know what effect that has on the dll, but i do know that having to recompile the exe's is cause the DLL version has changed, and theres something on how to avoid that on www.directx4vb.com i think its in the 'other tutorials' section under something about dll's, go read it
nm, i just edited the post and got the link anyway:
http://www.exhedra.com/DirectX4VB/Tu...B/GM_VBDLL.asp
Each time it compiles, the ProgID GUID changes. Which means any app that had a reference to it is no longer any good. The bet thing to do is to start creating compatability releases.
Here's how we do it:
When a DLL is created, the Compatability is set to None. The DLL is then compiled into a folder called "Release" under the project's folder. Then the compatibility is set to Binary, with the reference pointing to the DLL in the Release folder. Then we re-compile the DLL into the project's main folder. Then the whole thing is checked into source safe. A few things to note, do NOT check in the .EXP or LIB files created. Also do NOT check in the DLL that's in the project's main folder.
Now, when ever you make changes, as long as the interface isn't being changed, the compatibility will remain in tact and you won't have to reset the reference in your app every friggin time.
If you need more info on this PM me. -- This is something we use as the foundation of our development here, so I have a pretty good handle on it.
ah what the heck, i'll just paste it here anyway, lol
Quote:
To allow you to update it without confusing vb (it expects a certain version of the DLL - which changes each time it's compiled), you need to set an option for the DLL so that it is Binary Compatable. You can find it under the component tab in the project properties window. But before you do that, compile the DLL without this option - you dont need any code in it yet. You now have a useless DLL (wow!) - then go back into the properties and set it to be binary compatable, and in the little text-box point it to the precompiled DLL. You can now add as much code as you like and VB will never no the difference.
it was my understanding that I could make a DLL and compile it.. lets say to system32 (thats where the DLL sits normally) then i can go into the properties of my dll project and set it to binary compatibility and compile it again there on out with any changes and the exes that reference it won't need a recompile (unless you get that screen that says you will break compatibility??)
if you read what i posted above you'll see what to do, just turn off binary compatibility, compile your dll, then compile your programs, then turn binary back on and go from there
Yes, technically that would work.... the reason we did it the way we did, was so that when the class interface changes (usually extended, we try to avoid full changes that break comaptability) we create a Release 2, (or a Release 3, whatever the next release is) to preserve backwards compatability (which is very importaint to our product). This allows our screens which use these DLLS to work with either the original, or the Release 2 or whaterver the current version is.Quote:
Originally posted by kleinma
it was my understanding that I could make a DLL and compile it.. lets say to system32 (thats where the DLL sits normally) then i can go into the properties of my dll project and set it to binary compatibility and compile it again there on out with any changes and the exes that reference it won't need a recompile (unless you get that screen that says you will break compatibility??)
We may have one client that's on the original spec, while at the same time, we may have another that's on a different version. While still yet another version maybe in development. This allows us to be able to move forward/back through the version to properly support the clients.
Binary comp. is good as long as you do not change the Signature of the DLL. It means as long as you do not touch/change the Return Type and Paramters of a function in the dll, you can just recompile the dll, once you touch the signatures you just broke binary compatibility and it won't work anymore. These are the base principals of Active X developement.Quote:
Originally posted by kleinma
If you make an activeX dll and set its compatibility to "No Compatibility" what effect does that have on the DLL?
in the help it says
No Compatibility — Compatibility not enforced.
i have this DLL that was set to binary compatibility and all was well with it.. but now all of a sudden when i make changes to it.. i need to recompile all the exes that use it in order for them to work properly.. i thought binary compatibility allowed you to just change the dll??