Is it possible to use Indy 10.5.8.0 in Delphi XE and DataSnap?
Asked Answered
J

4

8

The case

I'm trying to update the INDY to the latest version for my Delphi XE (Update 1), so I downloaded the latest INDY10 file (Indy_4545.zip) from indy.fulgan.com/ZIP.

The packages compiles successfully and I can now even see the new version 10.5.8.0 on the about box dialog, but after a IDE restart I got a message saying:

No se encuentra el punto de entrada del procedimiento @Idhttp@TIdCustomHTTP@GetRequestHeaders$qqrv en la biblioteca de vínculos dinámicos IndyProtocols150.bpl.

My free translation to English:

Entry point not found for procedure @Idhttp@TIdCustomHTTP@GetRequestHeaders$qqrv not found on the dynamic link library IndyProtocols150.bpl.

After a quick comparision of old and new IdHTTP.pas I found a lot of changes on the TIdCustomHttp class, including the rename of some methods

  • GetResponseHeaders to GetResponse
  • GetRequestHeaders to GetRequest
  • SetRequestHeaders to SetRequest

Along with changed public/published method firms in this and other and classes interfaces.

After the update, I got a lot of packages failing to load, including dclcxPivotGridOLAPD15.bpl, which in turns depends on dclDataSnapServer150.bpl which encounters the missing method on the bpl.

AFAIK I can't recompile the dclDataSnapServer150.bpl (and maybe other failing packages, I just stopped here).

DataSnap and DevExpress support on the IDE is a must for my day to day so

The questions

  1. Is there a safe pre-established path to update to the newest INDY for Delphi XE?
  2. If not, am I on the safe side by just parching the source code by creating the old public methods and call the new ones on the implementation part?
  3. am I missing something else or am I really stuck with INDY 10.5.7 until the next Delphi minor/major release?
Jude answered 30/12, 2010 at 23:40 Comment(0)
J
4

From other's answers and mainly Remy's comments:

It is not possible to install Indy 10.5.8.0 without breaking DataSnap in Delphi XE Update 1.

Jude answered 31/1, 2011 at 15:20 Comment(5)
It is possible, just keep a copy of the original packages that shipped with the IDE, or install a separate copy of the updated Indy. Then tweak your project settings to use the original packages in DataSnap projects, and to use the updated packages in other projects.Meissner
@Remy: What you said is accurate, it happens to me that 99% of my relevant projects are using DataSnap, so it is nice to have an updated INDY for the toys, but it would be nicer to have it for what matters.Jude
I have been informed by Embarcadero that they will be looking into the possibility in the future of making DataSnap allow Indy upgrades without breaking anymore.Meissner
@Remy: Nice to know! I'll be tuned and waiting that moment. I have to say I like the fact INDY is actively developed, I just hope that evolution is isolated and/or made with direct Delphi dependencies into account, at least carrying needed breaking changes until the next library major release. Anyway, I have no other means but to be grateful to the work done by the INDY team.Jude
Remy ; maybe a nice JVCL-style installer for the indy project that can backup the original INDY, and maybe a swap tool that can register/unregister everything cleanly, would be a good idea.Kamal
M
12

[Installing Indy for Delphi XE]

Yes, the install process is tedious, but it's worth it to get it done right.

This is for all Indy components except SSL. (I haven't tried any of the SSL stuff yet.)

A.) Seek and destroy all Indy files that come with Delphi. These are no good as the Indy project is updated every single day with new bug fixes. If Delphi picks up any of the old files instead of your new fresh Indy library, you will get crazy errors from the IDE at all different times that are very hard to trace.

i. Go to Component-->Install Packages, then completely remove all packages that start with "Indy".

ii. Close Delphi.

iii. Erase all files that match "dclIndy*.bpl" and "Indy*.bpl" from Delphi's Bin folder.
(C:\Program Files\Embarcadero\RAD Studio\8.0\bin)

iv. Erase all files that match "Indy*.dcu" and "Id*.dcu"^^^ in Delphi's Lib sub folders.
(C:\Program Files\Embarcadero\RAD Studio\8.0\lib\win32\debug)
(C:\Program Files\Embarcadero\RAD Studio\8.0\lib\win32\release)
^^^ Warning: watch out for non-Indy DCUs that happen to begin with the letters "id" like "idispids.dcu" and "idoc.dcu"

v. Delete the entire Indy10 source folder:
(C:\Program Files\Embarcadero\RAD Studio\8.0\source\Indy10)

B.) Download the latest Indy10_XXXX.zip from http://indy.fulgan.com/ZIP/ (If you get a compile error or runtime error using this zip file for any of the steps below -- don't be discouraged! Re-download the zip file on the following day and try again. This zip file gets updated every day and there is a chance that there may be some bugs/errors on any given day.)

C.) Extract only the System, Core, and Protocols folders into your own Indy library folder. ex.
(c:\MyDelphiComponents\Indy\Core)
(c:\MyDelphiComponents\Indy\System)
(c:\MyDelphiComponents\Indy\Protocols)

D.) Launch Delphi. Ignore all failed package dialogs: These are the Embarcadero packages that rely on Indy! (Just click Ok on all errors, and indicate that any failed packages should not be loaded again.)

E.) Go to Options-->Environment Options-->Delphi Options-->Browsing Path - Remove paths that start with $(BDS)\Lib\Indy10

F.) Go to Options-->Environment Options-->Delphi Options-->Library Path - Add your new System, Core, and Protocols folders from step C to Delphi's library path.

G.) Perform the following 5 actions in order: (Just say OK to any dialogs about upgrading the project.)


Important:

After loading each dpk and before each build, go to:

Project-->Options-->Description-->Build Control

Set radio button to "Explicit Rebuild".

(Actually, this is optional, but I always make packages Explicit Rebuild because they seem easier to handle that way, but I'd like to hear what other people think about this...)


  1. Build - System\IndySystem150.dpk
  2. Build - Core\IndyCore150.dpk
  3. Build first, then Install - Core\dclIndyCore150.dpk
  4. Build - Protocols\IndyProtocols150.dpk
  5. Build first, then Install - Protocols\dclIndyProtocols150.dpk

** Double check that you've set "Explicit Rebuild" on all packages! **

H.) Finally, go to Component-->Install Packages and find all of the packages that rely on Indy that were turned off during step D. Reactivate them, and restart Delphi. (If your new Indy hasn't changed too much from the one released with Delphi, those packages will use the new Indy!)

++ Note, you may not receive any errors right away when reactivating those Embarcadero packages, but they may pop up at random times later. For example, I just installed Indy10_4548.zip and all the reactivated packages seemed fine. Then a day later out of the blue, the IDE threw me a message that said it couldn't find GetRequestHeaders in TIdCustomHTTP and that the dclWindowsAzureManagement150.bpl was having trouble as a result. So I had to go back and disable that Windows Azure package in the IDE.

Morbilli answered 14/1, 2011 at 18:41 Comment(2)
Thanks for your answer.. my question is just about your last part and not the process to install new indy itself, but as I said in my question, it is mandatory to have dclDataSnapServer150 because my projects rely on DataSnap, so what you wrote is, at the end, the same question and not an answer to mine.Jude
DataSnap uses Indy, but since DataSnap cannot be recompiled, it can only use the version of Indy that shipped with the IDE. For any project that uses DataSnap, you will have to maintain the original Indy packages. Since the IDE allows you to enable/disable packages on a per-project basis, you can use the original Indy packages for your DataSnap projects, and the newer Indy packages for other projects. Just install the packages into different folders.Meissner
P
7

AFAIK you're going to lose some packages that depends strongly on the Indy version deployed with Delphi, most notably the new Datasnap.

You may try to build your onwn packages to be used instead of standard ones that can't be recompiled, as long as all the needed units are available.

IMHO Embarcadero should find a solution about its own code depending on an "unstable" library like Indy. That's not acceptable in a professional environment, especially since they are unable to release official updates including the bug fixes from Indy beyond a few months from release. For example I found lately that Indy 10.5.5 mail message parsing truncates mail addresses, that not happens in 10.5.8. Of course the 10.5.5 behavior is not acceptable, I am forced to upgrade...

Pannonia answered 31/12, 2010 at 13:4 Comment(5)
The error you saw is because other packages (like Datasnap) depend on the indy package that came with the product. If you want to change the version of Indy, then you have to uninstall some of the other packages that depend on them. Delete the old IndyProtocols150.bpl from your BPL folder and see what else fails to load, and uninstall all affected packages before you try again.Kamal
Uninstall dependent packages like dclDataSnapServer looks bad to me, mostly because I do use DataSnap on my current projects. A better solution would be to have a new compatible version for each Indy breaking release, or to have Indy backward compatible minor releases. Of curse none of these are on our hands... Maybe I shall go trough Embarcadero support for this.Jude
The real issue is Indy should not make breaking changes within a given release. IMHO Indy really lacks proper release management and Embarcadero should take control of it, because of dependencies in its own code. Breaking changes could be made in major releases, but minor should only add fix or features which do not require changes to actual interfaces. Otherwise they drive mad any developer trying to build libraries using Indy (i.e. EldoS SecureBlackBox has the same issue with Indy). Probably Embarcadero should fork Indy and do something about it.Pannonia
The Indy team is well aware of its limitations and inadequacies regarding Indy's current practices. We're hoping to revamp a lot of things, both coding- and management-wise, when we start working on Indy 11. Simplifying installation and upgrade issues are high on the todo list.Meissner
I wish that it was easy to swap out the factory Indy packages, and replace them with some other. Maybe what is needed is a nice Indy installer, that can swap indy out and replace it with a local build, and then swap it back out. I agree with ldsandon. I think that the dependency of DataSnap on Indy creates a bad problem that the Indy project team can't really cleanly solve within the IDE's current limitations. Their APIs must be frozen, and they must maintain ABI compliance totally, or else the DataSnap packages break. Ouch.Kamal
J
4

From other's answers and mainly Remy's comments:

It is not possible to install Indy 10.5.8.0 without breaking DataSnap in Delphi XE Update 1.

Jude answered 31/1, 2011 at 15:20 Comment(5)
It is possible, just keep a copy of the original packages that shipped with the IDE, or install a separate copy of the updated Indy. Then tweak your project settings to use the original packages in DataSnap projects, and to use the updated packages in other projects.Meissner
@Remy: What you said is accurate, it happens to me that 99% of my relevant projects are using DataSnap, so it is nice to have an updated INDY for the toys, but it would be nicer to have it for what matters.Jude
I have been informed by Embarcadero that they will be looking into the possibility in the future of making DataSnap allow Indy upgrades without breaking anymore.Meissner
@Remy: Nice to know! I'll be tuned and waiting that moment. I have to say I like the fact INDY is actively developed, I just hope that evolution is isolated and/or made with direct Delphi dependencies into account, at least carrying needed breaking changes until the next library major release. Anyway, I have no other means but to be grateful to the work done by the INDY team.Jude
Remy ; maybe a nice JVCL-style installer for the indy project that can backup the original INDY, and maybe a swap tool that can register/unregister everything cleanly, would be a good idea.Kamal
B
2

Although I don't use Delphi XE my self, but the 2010 version. I was able to upgrade Indy components to the most current version, with the help of this Stack Overflow post: Step by step upgrade of Indy 10 in Delphi 2009

I know the question is for 2009 (but the answer covers 2010 as well), but it worked for me in version 2010, so my guess is that it will help you as well. I'd recommend you'd read the comments, since there are some good hints there as well. Hope this helps.

Brunel answered 30/12, 2010 at 23:46 Comment(2)
Thanks, I didn't know that question, but following my own procedure (and trying to write an article for my blog about the upgrade). As said, the problem is not with the compilation/installation but because the interfaces changed and other packages have dependencies to the old ones. Thanks for your answer, tough.Jude
When I upgraded Indy I had to manually edit the project files to make use of the new version Indy. This can be a bit of hassle, and result in errors if forgotten.Brunel

© 2022 - 2024 — McMap. All rights reserved.