Author |
|
Luca Newbie
Joined: 15 October 2006
Online Status: Offline Posts: 17
|
Posted: 30 January 2013 at 5:51am | IP Logged
|
|
|
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 |
|
|
Igor AfterLogic Support
Joined: 24 June 2008 Location: United States
Online Status: Offline Posts: 6092
|
Posted: 30 January 2013 at 6:03am | IP Logged
|
|
|
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 |
|
|
Luca Newbie
Joined: 15 October 2006
Online Status: Offline Posts: 17
|
Posted: 30 January 2013 at 6:09am | IP Logged
|
|
|
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 |
|
|
Igor AfterLogic Support
Joined: 24 June 2008 Location: United States
Online Status: Offline Posts: 6092
|
Posted: 30 January 2013 at 6:10am | IP Logged
|
|
|
Out of luck then, I'm afraid. Updating license key is a mandatory step.
--
Regards,
Igor, AfterLogic Support
|
Back to Top |
|
|
Luca Newbie
Joined: 15 October 2006
Online Status: Offline Posts: 17
|
Posted: 30 January 2013 at 6:20am | IP Logged
|
|
|
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 |
|
|
Alex AfterLogic Support
Joined: 19 November 2003
Online Status: Offline Posts: 2206
|
Posted: 30 January 2013 at 6:25am | IP Logged
|
|
|
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 |
|
|
Luca Newbie
Joined: 15 October 2006
Online Status: Offline Posts: 17
|
Posted: 30 January 2013 at 6:37am | IP Logged
|
|
|
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 |
|
|
Alex AfterLogic Support
Joined: 19 November 2003
Online Status: Offline Posts: 2206
|
Posted: 30 January 2013 at 6:50am | IP Logged
|
|
|
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 |
|
|
Luca Newbie
Joined: 15 October 2006
Online Status: Offline Posts: 17
|
Posted: 30 January 2013 at 7:21am | IP Logged
|
|
|
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 |
|
|
Alex AfterLogic Support
Joined: 19 November 2003
Online Status: Offline Posts: 2206
|
Posted: 30 January 2013 at 8:09am | IP Logged
|
|
|
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 |
|
|
Luca Newbie
Joined: 15 October 2006
Online Status: Offline Posts: 17
|
Posted: 30 January 2013 at 10:42am | IP Logged
|
|
|
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 |
|
|
Alex AfterLogic Support
Joined: 19 November 2003
Online Status: Offline Posts: 2206
|
Posted: 31 January 2013 at 2:55am | IP Logged
|
|
|
OK, I will explore the options of creating manifest when time permits, and let you know.
Regards,
Alex
|
Back to Top |
|
|
Alex AfterLogic Support
Joined: 19 November 2003
Online Status: Offline Posts: 2206
|
Posted: 31 January 2013 at 7:04am | IP Logged
|
|
|
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 |
|
|