Indy10 SSL Failure First Time Connecting

Question

I'm having a very similar problem to the one posed in this problem (having to connect twice on first load because of a "problem" loading the SSL dlls), except I'm pretty sure I'm using the latest version of Indy so the solutions proposed there do not solve my problem.

I am using Delphi7, and I selected not to install Indy from the Delphi7 installer since that version is incredibly obsolute. I did install Indy9 from latest SVN source before downloading and installing Indy10 (from SVN source), but I reconfigured the IDE and project settings to use the new Indy10 components/paths instead of Indy9. Clearly the project is using Indy10 to build as there are quite a number of methods I had to change to match all the Indy10 signatures to even compile.

My SVN repository for Indy10 is checked out from: https://svn.atozed.com:444/svn/Indy10/trunk/Lib and shows last commit revision of 4972, about 2 weeks ago--this does not look like "some really old version of Indy10".

I have downloaded OpenSSL 1.0.1e for Win32 from the binary build at http://opendec.wordpress.com/ (the location recommended from that other stackoverflow question I mentioned earlier) and put it in the same folder as my built .exe

Here's the code I'm using right now to open an SSL connection:

  try
    POP.Connect(Server,Port,Protocol,UserName,Password,TimeOut);
  Except
    on e : EIdOSSLCouldNotLoadSSLLibrary do
    begin
      ShowMessage('Failed to load: ' + WhichFailedToLoad());
      POP.Connect(Server,Port,Protocol,UserName,Password,TimeOut);
    end;
  end;

BUT... this is causing an EIdOSSLCouldNotLoadSSLLibrary exception, and adding WhichFailedToLoad shows the exact same list of components, that would suggest it's expecting the "indy specific" version of OpenSSL:

But Wait a minute... Remy answered in the linked question that "Indy 10 was updated to no longer require the custom-built DLLs anymore. It now uses the standardized OpenSSL DLLs as-is." So why would it be complaining that it needs Indy specific functions?

How could I troubleshoot why it's failing to connect the first time/saying it needs functions I understand not to be needed anymore? Is my expectation that it should not be looking for indy specific functions incorrect?

Answer 1

My guess, confirmed in the comments to the question, is that your compiler is finding Indy 9 and not Indy 10 to build your project.

The things can go ever worst, because your IDE may be using one version in design time and the compiler may be using a different version. In fact the IDE and the compiler are different parts of the chain and you can broke the original synchronization between both. Because that, I'll explain both cases and, as I explain later, you have to change both.

The IDE and design time

Design time packages are loaded by the IDE to create objects while you're working, show you the properties of that objects in the object inspector, create the form DFM files and get the method firm to be used when you resort to the IDE to generate pascal code to respond to events.

For the IDE you can check what version you're using in design time by right clicking on any Indy component, as shown in the image.

To change the version you're using in design time, go to Component\Install packages and check the correct version in the list. You cannot load Indy 9 and Indy 10 at the same time.

The compiler and run time

The compiler uses the Library path to look for the units you use in your project that are not part of the project itself, and compile that code along with yours to produce the executable.

To check what Indy version was linked into your executable, you can resort to the Version property present on all INdy components, for example:

ShowMessage('Indy version: ' + MyIndyComponent.Version);

To change what the compiler finds first, you have to change the paths. You can do it from inside the IDE. In modern Delphi you could check in Tools\Options\Delphi options\Library\Library path\ and Project\Options\Delphi compiler\Search path\ (I just don't remember where the options were in D7).

The Indy 9/10 case

Indy introduced interface breaking changes that makes impossible to compile a project written for Indy 9 using Indy 10. In fact, the administrators of the project doesn't wait for a major release to break the code compatibility and you expect to be forced to adjust your code when you upgrade to any minor version if it happens to have a different interface.

Because of that, you're definitely using Indy 9 in both, at compile/run time and IDE/design time, so you have to adjust both in your environment. After that, be prepared to re-write part of your code to adjust. Once you understand what changed and learn how to adapt, the change is fairly simple. The details are out of the scope of this answer, but there's enough information in the Internet for you to figure out how to do it.