-
Notifications
You must be signed in to change notification settings - Fork 155
Updating Indy
When installing the IDE, the Indy library is pre-installed automatically. However, it usually won't be the absolute latest version, as this repository is constantly being updated. To upgrade to the latest code, you first need to uninstall the default version of Indy.
Note: Please read the Important Notes section before continuing!
In Indy's repository, the \Lib source folder contains command-line Clean_<version>.cmd scripts for removing the default Indy installation from the IDE. Simply execute the appropriate script for your IDE version (with elevated privileges, of course), and the pre-installed binaries will be deleted automatically.
Note: Currently, cleanup scripts are provided for only XE3 and later. Scripts for older versions may come at a later time.
To fully uninstall the default Indy library manually, you will need to know a little about your IDE and where files are located.
The file locations will vary a little depending on the version of the IDE you're using. For example, Delphi 7 and earlier were published before Embarcadero acquired the CodeGear division of Borland, so the default installation path was under C:\Program Files (x86)\Borland; the early XE versions were in C:\Program Files (x86)\Embarcadero\RAD Studio; The current path is C:\Program Files (x86)\Embarcadero\Studio. To verify the installation path, start the IDE, select the Tools > Options (or Environment Options for old versions) from the menu, and look at the list of Environment Variables and find one of the following variable names:
-
BDS- for recent versions of Delphi, C++Builder, and RAD Studio -
DELPHIfor Delphi -
BCB- for C++Builder
The value of this variable will be the installation path.
To start the uninstall process, first remove Indy's packages from the IDE. This won't delete any files, but simply unregister them from the IDE. Select Component > Install Packages from the menu and locate the Indy packages -- there should be at least two of them:
- Indy 10 Core Design Time
- Indy 10 Protocols Design Time
There might be a third one as well:
- IP Abstraction Indy Implementation Design Time
(notice the filename for each is a .BPL in a \bin subfolder of the installation path)
Select each one and click the Remove button.
The default installed Indy files that come with the IDE are mixed in with other library files, so you might want to make a backup of your installation first. Depending on your version of the IDE and whether it supports multiple platforms, there may be several folders under the installation path with files that need to be removed (which will require Administrator rights in modern versions of Windows). The following is a list of the files under the installation path you need to look for and remove (paths may vary depending on IDE version).
For older IDEs, be sure to also check the OS system folders for any Indy binaries!
WARNING: Be careful when using wildcards and deleting files; remove ONLY files related to Indy -- double-check the ones that start with Id* to make sure they are not part of a different library. For example, DO NOT delete idoc.dcu and idispids.dcu! This is where a backup can really come in handy.
In $(BDS)\bin:
Indy*.bplIndy*.jdbgdclIndy*.bpldclIndy*.jdbg
In $(BDS)\lib\win32\debug:
Id*.dcuId*.objIndy*.bpiIndy*.dcpIndy*.dcuIndy*.libIndy*.resFmx.Id*.dcuFmx.Id*.objVcl.Id*.dcuVcl.Id*.obj
$(BDS)\lib\win32\release:
Id*.dcuId*.objId*.resIndy*.bpiIndy*.dcpIndy*.dcuIndy*.libIndy*.objIndy*.resFmx.Id*.dcuFmx.Id*.objVcl.Id*.dcuVcl.Id*.obj
In $(BDS)\bin64:
Indy*.bplIndy*.jdbg
In $(BDS)\lib\win64\debug:
Id*.dcuId*.oIndy*.bpiIndy*.dcpIndy*.dcuIndy*.resFmx.Id*.dcuFmx.Id*.oVcl.Id*.dcuVcl.Id*.o
In $(BDS)\lib\win64\release:
Id*.dcuId*.oId*.resIndy*.aIndy*.bpiIndy*.dcpIndy*.dcuIndy*.oIndy*.resFmx.Id*.dcuFmx.Id*.oVcl.Id*.dcuVcl.Id*.o
In $(BDS)\lib\win64x\debug:
Id*.dcuIndy*.dcpIndy*.dcuIndy*.lib
In $(BDS)\lib\win64x\release:
Id*.dcuIndy*.dcpIndy*.dcuIndy*.lib
In $(BDS)\binlinxu64:
bplIndy*.so
In $(BDS)\lib\linux64\debug:
Id*.dcuId*.oFmx.Id*.dcuFmx.Id*.o
In $(BDS)\lib\linux64\release:
Id*.dcuId*.oIndy*.dcpIndy*.oFmx.Id*.dcuFmx.Id*.o
In $(BDS)\binosx64:
bplIndy*.dylib
In $(BDS)\lib\osx64\debug:
Id*.dcuId*.oIndy*.dcpIndy*.dcu*Indy*.oFmx.Id*.dcuFmx.Id*.o
In ($BDS)\lib\osx64\release:
Id*.dcuId*.oIndy*.bpiIndy*.dcpIndy*.dcuIndy*.oFmx.Id*.dcuFmx.Id*.o
In $(BDS)\lib\osxarm64\debug:
Id*.dcuId*.oIndy*.dcpIndy*.dcuIndy*.oFmx.Id*.dcuFmx.Id*.o
In $(BDS)\lib\osxarm64\release:
Id*.dcuId*.oIndy*.bpiIndy*.dcpIndy*.dcuIndy*.oFmx.Id*.dcuFmx.Id*.o
In $(BDS)\lib\iosDevice64\debug:
Id*.dcuId*.oIndy*.dcpIndy*.dcuIndy*.oFmx.Id*.dcuFmx.Id*.o
In $(BDS)\lib\iosDevice64\release:
Id*.dcuId*.oIndy*.dcpIndy*.dcuIndy*.oFmx.Id*.dcuFmx.Id*.o
In $(BDS)\lib\iossimarm64\release:
Id*.dcuId*.oIndy*.dcpIndy*.dcuIndy*.oFmx.Id*.dcuFmx.Id*.o
In $(BDS)\lib\iossimarm64\debug:
Id*.dcuId*.oIndy*.dcpIndy*.dcuIndy*.oFmx.Id*.dcuFmx.Id*.o
In $(BDS)\lib\android\debug:
Id*.dcuId*.oIndy*.dcpIndy*.dcuIndy*.oFmx.Id*.dcuFmx.Id*.o
In $(BDS)\lib\android\release:
Id*.dcuId*.oIndy*.dcpIndy*.dcuIndy*.oFmx.Id*.dcuFmx.Id*.o
In $(BDS)\lib\android64\debug:
Id*.dcuId*.oIndy*.dcpIndy*.dcuIndy*.oFmx.Id*.dcuFmx.Id*.o
In $(BDS)\lib\android64\release:
Id*.dcuId*.oIndy*.dcpIndy*.dcuIndy*.oFmx.Id*.dcuFmx.Id*.o
With either automated or manual uninstall, you may notice that the Indy source code that comes with the IDE is still there; you can rename it, remove it, or just leave it there -- it won't cause any problems. However, you should make sure those source folders are removed from the IDE's Search path -- you don't want to inadvertently pull up the wrong version of the Indy source once you have a newer version installed elsewhere.
With the default Indy library files safely removed from the IDE, get the latest code from GitHub. The easiest way is to git clone the library to a new folder; that way you can easily keep the library updated later as bug fixes and enhancements are made.
NOTE FOR DELPHI/C++BUILDER 5 USERS ONLY: DO NOT use the code in the master branch. There are some nasty bugs in the Delphi 5 compiler (ie, stack corruption, IDE crashes) which require some ugly workarounds in Indy, which are not included in the master branch to keep its code clean. Use the code in the Delphi5-workaround branch instead. The bugs were fixed in Delphi/C++Builder 6. If the Delphi5-workaround branch hasn't been updated from the latest master branch for awhile, please contact the Indy team, or submit a Pull Request.
For Delphi/C++Builder/RADStudio IDEs, the packages and project groups are named after the Compiler Package Version. For example, RAD Studio 10.2 Tokyo's Package Version is 250, so you would load the Indy250.groupproj project group; for XE, you'd load Indy150.groupproj.
Note: this naming convention will be changed in the future to drop the version numbers from the package names!
Note: the SuperCore package is very outdated and not currently usable. Don't even try to compile or install it, it will not work.
Note: there was no Delphi/C++Builder v13, so do not use the Indy...130 packages. For D/CB/RAD 2009, use the Indy...120 packages. For D/CB/RAD 2010, use the Indy...140 packages.
Select the project group in Indy's \Lib folder corresponding to your version of Delphi. You can then build and install the packages using the IDE's Project Manager.
Note: project groups are missing for some IDE versions. If they are missing for your version, simply compile and install the individual packages instead. See the "Build the Projects" section further below. Feel free to submit any missing project group files.
For RAD Studio, if the C++ personality is installed, be sure that "Generate All C++ Files" is enabled in the options of each Indy project. This is needed to produce .lib and .hpp files for using Indy in C++ projects. Also, make sure that BCB is defined in either the IDE's Environment Options, or as a Conditional Define in each Indy package. This is needed to enable workarounds in Indy's source to deal with various C++ compiler issues.
Indy does not include .BPK project files for C++Builder. In Indy's \Lib folder are command-line .bat scripts with the names Fullc_<version>.bat for compiling Indy's .DPK files using C++Builder's command-line Delphi compiler (dcc32.exe) or MSBuild toolchain (msbuild.exe), depending on your IDE version. Choose the script corresponding to your version of C++Builder and run it, and then you can register the resulting .BPL files in the IDE.
NOTE: It is recommended to read the comments in the batch file before you begin.
Lazarus 1.8 and later has a built-in Online Package Manager. Indy has been included in the OPM, and thus can be installed into Lazarus with a single click, instead of having to manually download, compile, and install Indy yourself.
However, if you need to, the instructions for compiling Indy for FreePascal are available at https://wiki.freepascal.org/Indy_with_Lazarus.
If you're ready to proceed, look at the projects in the project group you loaded. You'll notice five projects:
-
IndySystem- runtime library inLib\System -
IndyCore- runtime library inLib\Core -
IndyProtocols- runtime library inLib\Protocols -
dclIndyCore- design-time library inLib\Core -
dclIndyProtocols- design-time library inLib\Protocols
Compile the projects in the order listed.
If you encounter the following linker error:
RLINK32: Error opening File <packagename>.drf
Try this workaround:
- Delete all
.DCPand.BPLfiles for the package - Open the package file in the IDE, go into its Project Options, and make sure it's set for "Explicit Rebuild"
- Rebuild the package.
- Repeat these steps for each dependent package.
The current Indy 10 package projects are set for Windows compilations. The IndySystem and IndyProtocols packages do have a few platform-specific units in them, which are conditionally compiled via IFDEF statements in the .DPK files. This is fine for command-line compilations, but the IDE usually doesn't handle IFDEFs in .DPK files very well, and this can also cause an associated .DPROJ file to become out of sync with its .DPK file. So this may lead to issues if you want to compile Indy via the IDE for non-Windows platforms (in versions that support this). You might need to edit the IndySystem project to remove the IFDEFs and replace the IdStackWindows, IdWinsock2, and IdWship6 units with the IdStackVCLPosix and IdVCLPosixSupplemental units instead, and then edit the IndyProtocols project to remove the IFDEFs and the IdAuthenticationSSPI and IdSSPI units. Perhaps in a future release, we will try to automate/cleanup this better.
In your Indy directory, you should now see some compiled .DCU files. Open the IDE and select Tools > Options (or Environment options for old versions) from the menu and add the three Indy folders to your Library path:
Lib\CoreLib\SystemLib\Protocols
Now install the two design-time packages, dclIndyCore and dclIndyProtocols, into the IDE.
You should get a message listing all the components that have been registered and added to IDE.
Congratulations! You've got the latest Indy libraries!
Here are some important notes to be aware of when updating a shipped version of Indy in various Borland/Embarcadero IDEs.
Embarcadero's DataSnap framework is compiled against the Indy 10 packages that ship with the IDE. Installing a new version of Indy will render DataSnap unusable, as it will not be able to load the Indy packages anymore, and DataSnap cannot be recompiled by end users. If you need to use DataSnap, then you will need to maintain the original Indy 10 packages for use in DataSnap projects. You can use a separate installation of Indy 10 for non-DataSnap projects. This was addressed by Embarcadero in D/CB/RAD XE2 so Indy 10 upgrades and DataSnap can co-exist.
Up to, and including, Update 3, an erroneous dependency on Indy has been identified in Embarcadero's dclnet160.bpl package. Installing a new version of Indy will cause this package to fail to load correctly in the IDE, preventing all contained components (such as THTTPRIO, TXMLDocument, TWeb*Dispatcher, T*Producer, TTcp*, TUdp*), as well as Wizards and Property Editors for them, from appearing at design-time. The run-time components can still be instantiated dynamically in your run-time code, though! Embarcadero is aware of the problem, and has already fixed the problem for XE3. Removing the dependency causes an interface change in dclnet.dcp, and Embarcadero does not normally release interface changes in product Updates, however the change is internal to Embarcadero's code only and should not effect end users, so Embarcadero may have included the fix in an XE2 Update.
The DCLIPINDYIMPL160.BPL package has a link to Indy's IdHeaderCoderUTF unit, which does not exist in Indy anymore and was replaced with the IdHeaderCoderIndy unit. Installing a newer version of Indy will cause a linker error in this package. According to Embarcadero, this package is the only design-time package that should require rebuilding after upgrading Indy with any kind of interface changes or unit list changes. The source for this package is provided in XE2, users can find it under $(BDS)\source\indy\implementation.
Update: interface changes have been made to Indy since XE2's release, so Embarcadero's IndyPeerImpl.pas unit in this version will no longer compile as-is. Have a look at this discussion for some of the issues you may run into and how to work around them: http://www.codenewsfast.com/cnf/thread/0/permalink.thr-ng1921q9564, in particular this reply: http://www.codenewsfast.com/cnf/article/1430996872/permalink.art-ng1921q9582.
Embarcadero changed the signature of the TIdUDPServer.OnUDPRead event in the bundled copy of Indy 10. This was done in an attempt to address a slew of related Quality Central bug reports (#88816, #89298, #89662, #92067, #93672, #94969, #97943, #99863, #103088, #104825), to allow the Delphi compiler to generate RTTI that allows the IDE to produce an event handler that is compatible with both Delphi and C++Builder without errors, and without requiring additional RTL/compiler changes (which are actually needed to solve the root cause of the original errors). Specifically, the AData parameter of the OnUDPRead event was changed from a Dynamic Array to an Open Array. Consequently, the parameter signature is now different, which means that pre-existing user code that uses the OnUDPRead event in earlier D/CB/RAD versions will no longer work correctly without being updated accordingly. This change was NOT approved by the Indy development team, and Embarcadero did NOT apply their change to other areas of Indy that are affected by the same issue, such as the TIdTelnet.OnDataAvailable and IdIPMCastClient.OnIPMCastRead events. To maintain a single codebase, these changes have been merged into subsequent releases of Indy 10.
Update: this was corrected in XE4, allowing the AData parameter to be changed back into a dynamic array.
Embarcadero's Metropolis UI LiveTile framework is compiled against the Indy 10 packages that ship with the IDE. Installing a new version of Indy will render LiveTiles unusable, as it will not be able to load the Indy packages anymore, and LiveTiles cannot be recompiled by end users. If you need to use LiveTiles then you will need to maintain the original Indy 10 packages for use in LiveTile projects. You can use a separate installation of Indy 10 for non-LiveTile projects. This has not been addressed by Embarcadero yet so Indy 10 upgrades and LiveTiles can co-exist.
There have been some reports that when compiling Indy for XE3, the compiler may complain about missing .OTARES files. This is caused by a {$R *.otares} statement in the .DPK files. The files that are checked in to Indy's repo do not contain this statement, but apparently the compiler may decide to insert it on its own. If this happens, just remove the statement and recompile again. Indy does not use .OTARES files. They are generated by the IDE when it encounters unknown resources while upgrading a project from an older IDE version.
Embarcadero's LivePreview and EMSEdge frameworks are compiled against the Indy 10 packages that ship with the IDE. Installing a new version of Indy will render LivePreview/EMSEdge unusable, as they will not be able to load the Indy packages anymore, and they cannot be recompiled by end users. If you need to use LivePreview/EMSEdge, then you will need to maintain the original Indy 10 packages for use in LivePreview/EMSEdge projects. You can use a separate installation of Indy 10 for non-LivePreview/EMSEdge projects. This has not been addressed by Embarcadero yet so Indy 10 upgrades and LivePreview/EMSEdge can co-exist.