COM Forward compatibility ?

Question

0.00/5 (No votes)

See more:

Hello, I have a question. I have a dll COM with version A and I have a new version of this dll (version B). Version B supports backward compatibility i.e: When I compile application with the version A of dll it works fine. When we launch it on machine that has version B installed.

I suppose my description is clear :(

Now what do I need if the inverse is true or not?
i.e : If I compile my application with the new version of dll(version B) and launch my application on machine which have the version A installed. Will this work or not?

Posted 17-Apr-13 5:51am

MrKBA

Updated 17-Apr-13 5:55am

Richard C Bishop

v2

Add a Solution

Comments

[no name] 17-Apr-13 12:12pm

"I suppose my description is clear", no it really is not clear at all.

"When we launch it on machine that has version B installed", is not a complete sentence.

"Will this work or not? ", that depends. You can only call functions in your COM object that is supported by the version installed on the target machine.

MrKBA 17-Apr-13 12:31pm

sorry for that
Normally the backward compatibility was planed to ensure that if one soft is compiled for an old version of the library, it can continue to work with the new higher version of the library without recompilation or special adaptation.(situation 1)

is the reverse also true?

means if the soft is compiled with the new higher version of dll it can continue to work with the old version of the library without recompilation or special adaptation.(situation 2)

My situation is the first one, So I ask if should I have also situation 2 works ?

[no name] 17-Apr-13 13:37pm

No. I think you misunderstand how COM works. You do not compile your code to include a specific version of a COM component. Your code would instantiate the COM component and use it. If the DLL does not support the functions you are calling then it's going to fail. You situation 2 is called "backwards compatibility". You cannot call functions in a DLL that your code does not know anything about.

MrKBA 17-Apr-13 12:27pm

sorry for that
Normally the backward compatibility was planed to ensure that if one soft is compiled for an old version of the library, it can continue to work with the new higher version of the library without recompilation or special adaptation.(situation 1)
is the reverse also true?
means if the soft is compiled with the new higher version of dll it can continue to work with the old version of the library without recompilation or special adaptation.(situation 2)
my situation is the first one, So I ask if should I have also situation 2 works ?

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CPallini · Accepted Answer · 2013-04-17T07:06:00

COM has strict rules: Interfaces must be immutable. You must never, ever change the interface in a new version of a COM DLL. You may add interfaces, however.
Now, supposing you have (strictly) followed the COM rules, the new DLL, supports the old interface and possibly new ones. IF object B relies on one of the new interfaces, then the corrensponding QueryInterface would fail when called on the old COM DLL.

Sergey Alexandrovich Kryukov · Accepted Answer · 2013-04-17T06:53:00

Solution 1

In general case, not. Actually, that's why, in addition to compatibility, COM components should support versioning.

Now, why? To understand it, you should consider layout of memory pointed by interface pointer and two side: a component and using code. Here is the illustration. From C++ perspective, consider it as pseudo-code:

C#

//Old component:
interface A {
   MethodOne();
}

//New component:
interface A {
   MethodOne();
   MethodTwo();
}

//Old using code:
A a = //...
a.MethodOne(); // valid for both new and old versions of A

//New using code:
A a = //...
a.MethodOne(); // valid for both new and old versions of A
// and, in general case:
a.MethodTwo(); // valid for new version of A, will try to call non-existent method of old version of A

Are you getting the idea?

—SA

Posted 17-Apr-13 6:53am

Sergey Alexandrovich Kryukov

Updated 22-Apr-13 5:14am

v2

Comments

MrKBA 18-Apr-13 5:04am

So conclusion, it is impossible to ensure this ?
And caller should have at least the new version of COM to works ?

Sergey Alexandrovich Kryukov 18-Apr-13 10:16am

Impossible to ensure without additional functionality like version information.

The simple approach: you can have some interface with some version and version comparison. And this interface should be only one, never changed.

If the using code of newer version uses older or the same version of interface, it's fine.
Otherwise, the using code throws exception and says something like "you are using obsolete version of the application; please upgrade..." and provide the access to upgraded version, download or something like that.

How to compare and modify versions during development? Introduce some policy. When you support versions, you can consider, for example, that too or one most significant numbers of the version mean incompatibility (say, ignore release/build components of the versions in comparison). It means that only implementation detail is changed. (Or support separate versioning for interfaces and implementations and compare separately. This can be over-complicated. It depends on your development branches.)

Never delete members of any exposed interfaces in the evolution. If you really need to phase out some of them, develop some deprecation mechanism, so the deprecated members are always available, but using them provides some warning.

Are you getting the idea?

—SA

MrKBA 22-Apr-13 4:51am

yes.thank you

Sergey Alexandrovich Kryukov 22-Apr-13 11:13am

You are welcome.
Good luck, call again.
—SA