-
Oct 13th, 2005, 07:50 AM
#1
Thread Starter
Hyperactive Member
Change reference to new dll
I'm using VB6. I have a whole bunch of programs referencing a dll. Now the dll has changed (the name is same though). So do I have to open each project and change reference to point to new one OR is there some other easier way or some script which could make life easier.
-
Oct 13th, 2005, 08:42 AM
#2
Re: Change reference to new dll
Watch very carefully and this will be the last time you have to do it.
1) Open the dll project.
2) Open the properties dialog for the project.
3) Select the Component tab (if there's a set of options regarding the Compatibility at the bottom, you have the right one)
4) Make sure that "No Compatibility" is selected. Click OK
5) From the File Menu, select MAke xyzMyDll.Dll
6) In the Save As File dialoge, make a new directory (I'm assuming that this is going into the same folder where the project is.) Doesn't matter what you call it. We call our "Release" but you cna give it any name you want.
7) Compile the DLL into that new directory.
8) When done, open the Project properties form again and back to the Component tab.
9) This time select "Binary Compatibility" There should be a button right there that will allow you to select the file to be compatible with. Click it.
10) Select the DLL you JUST created.
11) Close all screens and compile the DLL again. THIS TIME compile it back to the PROJECT folder.
12) Save the project file.
From now on, when ever you make a change, you can simply replace the DLL w/o needing to reset the reference every time.
At this point, you will need to reset the reference in the other projects one last time (because we compiled it once at the begining with no compatibility) but after that, it will stick.
-- NOTE This will work as long as the interface (public subs, functions, object, etc) don't change (doesn't include the code inthose elements, but their external physical signature.) If the interface does change, then repeat steps 5 -12, but using a new folder (in our case we end up with Release, Release 2, Release 3, etc).
What this does: By setting the compatibility, the same classID will be generated for the DLL each time. When you set "No Compatibility" a new ClassID is created everytime. This is why you have to reset the reference after compiling. Since it will always have the same classId now, projects will be able to maintain the reference correctly.
-tg
-
Oct 9th, 2007, 03:03 AM
#3
New Member
Re: Change reference to new dll
It is very Informative.
I just followed what you had said, and everything were successfully done.
I created a batch file to compile all the DLLs and Projects.
Problem:
1) I need to add Public variables to my DLLs. Adding Public variables are still needed to set the reference again of the project?
2) Is there any batch file/automatic referencing the newly created ClassID to the Project?
-
Oct 9th, 2007, 03:11 AM
#4
Re: Change reference to new dll
NO.... there's no need to rest the reference... See my note in the above posting... you are adding to the interface, not removing or changing an existing sub signature.
-tg
-
Oct 9th, 2007, 08:55 PM
#5
New Member
Re: Change reference to new dll
How about my favor on number 2? is there other way to automatically link the newly created ClassID via batch file?
-
Oct 9th, 2007, 09:21 PM
#6
Re: Change reference to new dll
Once you set the reference, that's it.... you don't need to change the ClassID.... that's the whole point of setting the binary compatibility... the classID doesn't change.
-tg
-
Oct 16th, 2007, 08:44 PM
#7
New Member
Re: Change reference to new dll
Originally Posted by techgnome
Once you set the reference, that's it.... you don't need to change the ClassID.... that's the whole point of setting the binary compatibility... the classID doesn't change.
-tg
Maybe I misinterpreted regarding changing the interface..
When the interface of a DLL had changed, It causes to create a new ClassID?
If yes, do we need to set the project reference again?
-
Oct 16th, 2007, 09:19 PM
#8
Re: Change reference to new dll
Originally Posted by erosszz
Maybe I misinterpreted regarding changing the interface..
When the interface of a DLL had changed, It causes to create a new ClassID?
No, because you have binary compatibility set...
If yes, do we need to set the project reference again?
No, because you have binary compatibility set.
Now, the following cases will cause compatibility to be broken, in which case, yes, it would need to be reset (but there are ways around that):
* You remove a parameter from a sub/function.
* You change a public enum value
* You completely remove a sub, function or property.
If you make changes and try to compile it, if you get a message about breaking compatibility, then that's when you've got a problem....
-tg
-
Dec 14th, 2007, 03:50 AM
#9
New Member
Re: Change reference to new dll
Originally Posted by techgnome
.
Now, the following cases will cause compatibility to be broken, in which case, yes, it would need to be reset (but there are ways around that):
* You remove a parameter from a sub/function.
* You change a public enum value
* You completely remove a sub, function or property.
-tg
Could you elaborate please on what ways there are around this, I know I need to be careful as I would need to ensure that no DLLs call these changed functions until all is recompiled, however in a project with a large number of DLLs it will make life easier - any links or info on what one can do?
VMT
-
Dec 14th, 2007, 06:41 AM
#10
Re: Change reference to new dll
If you follow techgnome's steps in Post #2 you shouldn't have any problems.
-
Dec 14th, 2007, 08:17 AM
#11
New Member
Re: Change reference to new dll
Thanks, but your reply wasn't to the question that I asked! If you read his post which I quoted, he states that there are ways around a recompile if you - change parameters
- change public enums
- remove functions
The only ways I know of are late binding (generally no!)
automated builds (doesn't solve the need for a recompile but eases it with a large project).
Is there any other way...
His answer in 2 is for maintaining compatibility if you don't change one of these 3 listed...
-
Dec 14th, 2007, 09:40 AM
#12
Re: Change reference to new dll
There are ways around it and there isn't.... If you've changed any one of those three items... you've got a problem. You broke compatibility on them. Then next compile will tell you, hey this is no longer comaptible, what would you like to do? And it will offer you two choices: Break compatibility, or disable the new functions, preserving compatibility (but denying access to anything you changed). There's no work around for that directly. Essentially, you broke the contract with COM and it's crying foul.
So the answer is: don't do that.
The longer answer is, if you need to change a parameter, leave the original, strip the code out, and have it raise an error. Then create a NEW function that has the new signature with the new parameters. But that means that everywhere the old function was called, it will now throw an error (so now you can find it), and it will need to be replaced with the new function call (which you would have to change anyways since the parameters were changing.)
For changing enums.... simply don't. Just add to the list.
Removing functions - again, don't. Just strip the code from the function and raise an error stating that the function is no longer in use. Any one who tries to use it will get a RunTimeError (unless they've use On Error Resume Next --- mental note - add that to the arguments against OERN).
Does that help?
-tg
-
Jun 3rd, 2010, 11:57 AM
#13
Re: Change reference to new dll
Old post I know and a worthy read. I'd like to add something else regarding upgrading due to new functions.
1. One option of course is to create it as a new dll/ocx with a new filename, following steps in post #2 above.
MS does this from time to time: msado21, msado22, mado25, etc.
2. If you don't want to break compatibility, but want to add/change functions while maintaining backward compatibility to previous version of dll/ocx... Add those new functions. For those functions that you want to change/modify/upgrade, do not change them. Leave them alone. Instead, create a new function with a similar name.
The inet control does similar stuff: WebBrowser1.Navigate & WebBrowser1.Navigate2 for example.
I think the comments I made are valid. If something is not worded correctly or misleading, I apologize & definitely mention it.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|