Search The ForumSearch   RegisterRegister  LoginLogin

MailBee Objects
 AfterLogic Forum : MailBee Objects
Subject Topic: Backward compatibility Post ReplyPost New Topic
Author
Message << Prev Topic | Next Topic >>
Luca
Newbie
Newbie


Joined: 15 October 2006
Online Status: Offline
Posts: 17
Posted: 30 January 2013 at 5:51am | IP Logged Quote Luca
Hello, I have a question about backward compatibility of the latest releases with releases up to 5.8.

I have developed and am mantaining a software which uses 5.x. The same library was also used in a different application which unfotunately cannot be updated anymore, but is still installed on users' machines and is still being used by them.

I'd like to upgrade to the latest releases, and use those in my software, but I haven't done so yet because I am afraid of breaking compatibility for the older app, which uses SSL "the old way" and has hard-coded license keys.

What happens if I deploy a newer release of mailbee objects to those machines? I see that in 6.x, 7.x and 8.x you have changed both the license keys and the way the library deals with SSL, so I expect the new releases to have a different dll name (not mailbee.dll) and class IDs ... otherwise the old app would break (bad license keys, SSL object not supported anymore).

Am I correct here, or are the new versions using the same dll name and class IDs as the older, incompatible ones? And, if that is the case, what's the suggested practice for this scenario?
Back to Top View Luca's Profile Search for other posts by Luca
 
Igor
AfterLogic Support
AfterLogic Support


Joined: 24 June 2008
Location: United States
Online Status: Offline
Posts: 6038
Posted: 30 January 2013 at 6:03am | IP Logged Quote Igor
I believe both DLL name and Class ID should be the same between versions. You can download latest DLL build (32 bit / 64 bit) and check if it works for you.

Indeed, there were several SSL-related changes, but none of those should cause critical issues when updating 5.* > 8.* and keeping the same code. SSL object itself is still there, it's just instantiated automatically.

Anyway, the upgrade procedure is pretty much standard here: unregister current DLL, register new one, make sure new license key is supplied... and that should be it!

--
Regards,
Igor, AfterLogic Support
Back to Top View Igor's Profile Search for other posts by Igor
 
Luca
Newbie
Newbie


Joined: 15 October 2006
Online Status: Offline
Posts: 17
Posted: 30 January 2013 at 6:09am | IP Logged Quote Luca
Thank you for your prompt reply Igor; I will check the SSL thing.

Still, there's the problem of the license: the old application has "old" (5.x) licenses hard-coded (it sets .LicenseKey property by code), and as I said it cannot be updated.

If I install a newer (8.x) version of mailbee.dll on the PC, the old application would stop working, as its old licenses don't work anymore (they are not valid with 8.x). How should I address this?
Back to Top View Luca's Profile Search for other posts by Luca
 
Igor
AfterLogic Support
AfterLogic Support


Joined: 24 June 2008
Location: United States
Online Status: Offline
Posts: 6038
Posted: 30 January 2013 at 6:10am | IP Logged Quote Igor
Out of luck then, I'm afraid. Updating license key is a mandatory step.

--
Regards,
Igor, AfterLogic Support
Back to Top View Igor's Profile Search for other posts by Igor
 
Luca
Newbie
Newbie


Joined: 15 October 2006
Online Status: Offline
Posts: 17
Posted: 30 January 2013 at 6:20am | IP Logged Quote Luca
Ouch... That's very bad - the infamous dll hell strikes back :)

Basically, it means that, as a developer, you may never be sure you are not breaking other apps using mailbee (since you certainly can't force other developers to use the same version).

Or, even worse, you may never be sure that your app is broken by others.

I can stick to version 5.x, and am glad I did so, but if a newer version is installed by other software, my app gets broken.

I really believe that, as a component vendor, you should take this into consideration - your component is widely used, deployment can't be a matter of finger crossed ;)

Back to Top View Luca's Profile Search for other posts by Luca
 
Alex
AfterLogic Support
AfterLogic Support
Avatar

Joined: 19 November 2003
Online Status: Offline
Posts: 2206
Posted: 30 January 2013 at 6:25am | IP Logged Quote Alex
Yes, this is the natural problem of ActiveX/COM. .NET eliminates the issue. Different versions of .NET libs can freely co-exist with no concern.

Regards,
Alex
Back to Top View Alex's Profile Search for other posts by Alex
 
Luca
Newbie
Newbie


Joined: 15 October 2006
Online Status: Offline
Posts: 17
Posted: 30 January 2013 at 6:37am | IP Logged Quote Luca
I'm sorry I don't agree on this; if you release a COM version which is not backward compatible, the filename and class ID should be changed (as there is no point in keeping the same file name and class id anyway).

That's in fact what Microsoft did with many of their components, and what I see done from other component providers. In fact, I believe this is also a recommended practice on msdn: keep same class ids / filenames only if you keep backward compatibility. Makes lots of sense.

That's a pity because I really like Mailbee Objects component and it served me very good for years, but I realize I cannot rely on it anymore - either I break someone else's app, or mine gets broken.

Back to Top View Luca's Profile Search for other posts by Luca
 
Alex
AfterLogic Support
AfterLogic Support
Avatar

Joined: 19 November 2003
Online Status: Offline
Posts: 2206
Posted: 30 January 2013 at 6:50am | IP Logged Quote Alex
Well, there had been no change in ClassID. I just checked ClassIDs of the version back from 2004 and they are all the same.

Regards,
Alex
Back to Top View Alex's Profile Search for other posts by Alex
 
Luca
Newbie
Newbie


Joined: 15 October 2006
Online Status: Offline
Posts: 17
Posted: 30 January 2013 at 7:21am | IP Logged Quote Luca
That's in fact my point ... there should have been.

If you make a new release not backward compatible (for any reason), you should change both filename and class ID, so that both versions can be safely deployed side by side (think of mscomm32.ocx and mscomm232.ocx as an example).

(Obviously this applies to shared components only)

Since from Igor's reply I assume the only thing breaking backward compatibility is the licensing scheme, a possible mitigation strategy would be allowing to store a license key in the registry, and prioritizing it over the .LicenseKey property (if the component finds the proper registration there, it would ignore the value of .LicenseKey property).
Back to Top View Luca's Profile Search for other posts by Luca
 
Alex
AfterLogic Support
AfterLogic Support
Avatar

Joined: 19 November 2003
Online Status: Offline
Posts: 2206
Posted: 30 January 2013 at 8:09am | IP Logged Quote Alex
OK, I understood your point. Unfortunately, your approach would cause more disadvantages than advantages so that we cannot follow this route. It would cause the need for customers to modify their software each time a new version with new licensing is out (due to the change of the filename or registry paths).

Seems there is no ideal solution out there.

Regards,
Alex
Back to Top View Alex's Profile Search for other posts by Alex
 
Luca
Newbie
Newbie


Joined: 15 October 2006
Online Status: Offline
Posts: 17
Posted: 30 January 2013 at 10:42am | IP Logged Quote Luca
But Alex, this is exactly what is happening now - customers need to modify their software each time a new version with new licensing is out! In fact, we need to change the license in the application and recompile it. No big deal, but we cannot recompile other people's apps :)

Please take my criticism constructively - Mailbee Objects is the best component in its category (and I have quite a good knowledge of all of them), I just can't stand the idea of having to replace it with something inferior just because someone decided to break COM backward compatibility guidelines :) Any COM object should be replaceable with newer releases without recompiling the consumer; if it needs recompiling, filename and class ID must be changed in order to allow side-by-side deployment.

There is a way, actually, which was implemented by Microsoft precisely for cases like this (broken backwards compatibility): using Registration-Free COM Interop using an xml manifest; maybe you can provide a manifest file for the dll?

Or, is it possible to go through your custom programming offer - having a custom compilation (filename and class ID) of the latest dll?







Back to Top View Luca's Profile Search for other posts by Luca
 
Alex
AfterLogic Support
AfterLogic Support
Avatar

Joined: 19 November 2003
Online Status: Offline
Posts: 2206
Posted: 31 January 2013 at 2:55am | IP Logged Quote Alex
OK, I will explore the options of creating manifest when time permits, and let you know.

Regards,
Alex
Back to Top View Alex's Profile Search for other posts by Alex
 
Alex
AfterLogic Support
AfterLogic Support
Avatar

Joined: 19 November 2003
Online Status: Offline
Posts: 2206
Posted: 31 January 2013 at 7:04am | IP Logged Quote Alex
Did you try a tool like regsvr42? They claim to work directly on the compiled .dll and produce .manifest file automatically. The tool has some limitation but it may work in your case.

A number of other alternatives exist as well:
http://stackoverflow.com/questions/465882/generate-manifest-files-for-registration-free-com

Regards,
Alex
Back to Top View Alex's Profile Search for other posts by Alex
 

If you wish to post a reply to this topic you must first login
If you are not already registered you must first register

  Post ReplyPost New Topic
Printable version Printable version

Forum Jump

Powered by Web Wiz Forums version 7.9
Copyright ©2001-2004 Web Wiz Guide