Updating DLL Breaks references in word 1

[markphsd]

I use a dll with word and Access, when I make any changes to the dll, i have to re-reference it in the WORD And access file. Is there any way to get around re-referencing?

Mark P.

http://www.cafecartel.com

Providing Low Cost Powerful Point of Sale Solutions.

 

[BobRodes]

Yes there is. Go into the properties for the project, and on the compile tab, select binary compatibility. What you're finding is that every time you recompile the project, you're assigning a new GUID to the class, with the result that you are breaking the reference to the class in any clients thereof.

Understand that when you select binary compatibility you must conform to COM interface rules. Those rules are:

1. Thou shalt not alter the names of any methods or properties.
2. Thou shalt not add, remove, alter the name of, or alter the type of any arguments to methods, nor shalt thou alter the type of any properties.
3. Thou shalt not alter the type of the return value of any method. (That is, you can't change a sub to a function, or alter the type of the return value of a function.)
4. Thou shalt not attempt to reorder the sequence of methods or properties in the interface.
5. Thou shalt not append methods to the interface. (While VB allows you to do this, I don't recommend it.)

There are other rules, such as supporting the iUnknown interface, but VB won't let you break them. The idea is to make sure that any code interface will retain backward compatibility with existing clients. Of course, you can reimplement a method to completely mess up the existing client, but at least the client will be able to call the messed up code properly.

HTH

Bob

 

[markphsd]

thanks bob, i'm down with that.

Does VB alert me if i do change one of those items in the com interface rules? or will it just break something in the application using the dll?

So when considering that it's about backwards compatability, it's okay to add properties and methods and functions and classes?

Mark P.

http://www.cafecartel.com

Providing Low Cost Powerful Point of Sale Solutions.

 

[JoeAtWork]

You are probably breaking compatibility every time you compile the DLL.

Go into the project properties, click the Component tab, in the Version Compatibility section, choose "Binary Compatibility" and point to the previous compiled DLL.

Once you are committed to maintaining backwards compatibility, do not change the parameters of any of your public object methods, their return values, and don't delete them. Same with properties. If you need to change them, create a new method or property. Otherwise, you will be contributing to "DLL Hell" and all other programmers will condemn you to virtual purgatory.

Also, make sure you increase the version number every time you compile (on the Make tab of the Project Properties dialog, checkmark the Auto Increment check box in the Version Number section).

 

[JoeAtWork]

Bob came down from the mountain with the sacred tablets quicker than I did.

 

[BobRodes]

Question 1: Yes, VB alerts you and gives you ominous warnings about how bad it is.

Question 2: see rules 4 and 5. COM rules forbid it, but... Also, functions ARE methods, classes are irrelevant to this discussion.

Sacred tablets....yer killin me Joe.

 

[markphsd]

Okay,

I changed to Binary, now when trying to make the dll it tells me I'm breaking compatability.

For example, it sayes I changed a DateOfBirth field from date to variant (Not after I changed to binary compatability, in fact this must have been changed a month ago.)

I first made the dll, then went to properties, checked binary compatability. The path to the dll is the sames as the one i just compiled. Then I went back to Make DLL and.... it won't compile.

Mark P.

http://www.cafecartel.com

Providing Low Cost Powerful Point of Sale Solutions.

 

[BobRodes]

Try unregistering the component, recompiling it, and then selecting binary compatibility.

 

[strongm]

>Thou shalt not append methods to the interface

Not sure I agree with this one ...

 

[markphsd]

BobRodes,

I ended up having to delete the old dll and recompile, thanks!

Mark P.

http://www.cafecartel.com

Providing Low Cost Powerful Point of Sale Solutions.

 

[BobRodes]

Yeah, strongm, I'd say it's a bit of a grey area. I don't like doing it personally, because if you have clients that implement an interface, and then you add methods to the interface, and then attempt to recompile classes that implement the interface, you'll get a compile error because you didn't fully implement the interface as it now stands. That's breaking backward compatibility in my book, and I think it's preferable to create a second interface with the new functionality, and then retrofit clients proactively as needed to implement the new interface.

However, in a situation with a good deal of control over the clients in a small shop it might be ok to do as a matter of policy. I still don't like it though.

Bob

 

[BobRodes]

By the way, Joe's suggestion to autoincrement the version number is an important one. I'd make sure you do that.

Bob

 

[markphsd]

Yes, it auto incrememnts thanks again, i thought that would be a good idea anyways, so i did it.

Mark P.

http://www.cafecartel.com

Providing Low Cost Powerful Point of Sale Solutions.

 

[BobRodes]

strongm, please elaborate on your point of view if you should desire to do so. I'm interested to hear what you may have to say.

Bob

 

[strongm]

Clearly adding interfaces, as you describe, is probably the most robust approach. However, certain environments can only work with the default interface (mainly scripting languages such as JScript and VBScript¹, for example). For them, extending the default interface is about your only option.

Secondly (and less importantly) I suspect many VB programmers are not really aware or care about interfaces (default, secondary or otherwise), mainly thanks to the fact that VB blurs the distinction between a class and an interface (and doesn't require the programmer to actually create an interface at all, doing it all behind the scenes for them)


¹Yes, yes, there are techniques for getting Vbscript to recognize a secondary interface, but you have to have planned ahead ...

 

[BobRodes]

Ok, I see what you're getting at now, and you do have a point. As for the second point, well yes, very true in my experience. And, VB's handling of user-defined interfaces is a bit less than ideal as well.

Perhaps I should amend what I said before to "I don't recommend it unless your environment leaves you no choice.

 

[strongm]

Yep, I'd be happier with that ;-)

 

[markphsd]

Okay,

Update,

I am now getting compatability breaking messages for what methods and properties i didn't change, they all have a form as a property and or parameter. The form parameter and property are shown as an object in the original dll, but not in the one i'm compiling.

So I:
Set the project back to no compatability.
Unregistered the orginall dll, then deleted it.
Compiled the project back to a Safe Reference Location.
Closed and opened vb.
Set the Project Compatability to Binary.
Compiled to my normal runtime location.
Got those messages again.

Any ideas? Should i not be using a public form property?

Mark P.

http://www.cafecartel.com

Providing Low Cost Powerful Point of Sale Solutions.