bds2006 update indy10 requires system.windows.forms.dcp

[cramer]

Hallo,

ich bekomme beim Verbindungsaufbau zu einer https Seite mit Indy 10.1.5 immer den Fehler "Could not load SSL library."
Die dlls liegen aber auffindbar im Ordner der EXE Datei.
Ursache ist da wohl die originale header Datei.

Ich wollte dann die Header Datei und dlls mal aktualisieren gem. diesem Beitrag:
http://www.delphipraxis.net/93395-in...-0-9-8e-2.html

Code:

Indy OpenSSL 0.9.8h Patch
03. Juni 2008
Copyright (c) 2008 digivendo GmbH, Arvid Winkelsdorf

- Für die Benutzung mit den vorinstallierten Indy Versionen von Delphi
  (Indy 9 / Indy 10) bis D2007

  benennen Sie die originale Datei IdSSLOpenSSLHeader.pas im Verzeichnis
  Indy\lib\Protocols um - z.B. in IdSSLOpenSSLHeader.original.pas -
  und kopieren Sie die neue IdSSLOpenSSLHeaders.pas in das 
  Indy\lib\Protocols Verzeichnis

Wenn ich dann das Indy compilieren will, gibt es :
[Pascal Fatal Error] IndyProtocols.dpk(29): E2202 Required package 'System.Windows.Forms' not found.

Trotz googelei, finde ich keine Lösung

[himitsu]

Diese Indy-Version wurde einfach nur für neuere Delphi-Versionen erstellt.
Inzwischen wurden die delphieigenen Units/Packages mit immer mehr Namespaces versehen.
z.B. die heißt die SysUtils.pas nun System.SysUtils.pas

Vermutlich wird das System.Windows.Forms bei dir noch Windows.Forms oder so ähnlich heißen.
Du müsstest also im Packages IndyProtocols.dpk die Abhängigkeiten anpassen, auf die Namen, wie sie bei dir noch heißen.

Abhängigkeiten = das "Require" in der DPK (QuellCode), bzw. in der Projektverwaltung

[mjustin]

Zitat von cramer:

Trotz googelei, finde ich keine Lösung

Indy 10.6 sollte noch mit alten Versionen bis Delphi 5 funktionieren (ich verwende die aktuelle Version noch mit Delphi 6).

Möglicherweise ist die alte Version nicht richtig deinstalliert ...

Anstatt eines Patchs würde ich empfehlen, Indy komplett ohne Packageinstallation zu verwenden. Dazu die Pfade Lib/Core, Lib/Protocols und Lib/System in den Suchpfad des Projekts einbinden.

[cramer]

Hi, danke für die Hinweise.

Zitat von himitsu:

Diese Indy-Version wurde einfach nur für neuere Delphi-Versionen erstellt.
Inzwischen wurden die delphieigenen Units/Packages mit immer mehr Namespaces versehen.
z.B. die heißt die SysUtils.pas nun System.SysUtils.pas
Vermutlich wird das System.Windows.Forms bei dir noch Windows.Forms oder so ähnlich heißen.
Du müsstest also im Packages IndyProtocols.dpk die Abhängigkeiten anpassen, auf die Namen, wie sie bei dir noch heißen.
Abhängigkeiten = das "Require" in der DPK (QuellCode), bzw. in der Projektverwaltung

Aber ich habe doch nur die IdSSLOpenSSLHeaders.pas genommen, die DPK mit dem "requires" ist noch identisch mit der Originalen von der DVD
\install\program files\borland\bds\4.0\source\indy10\protocols\Indy Protocols.dpk

Code:

requires
  System.Windows.Forms,
  Borland.Delphi,
  Borland.VclRtl,
  IndySystem,
  IndyCore;

Zitat von mjustin:

Indy 10.6 sollte noch mit alten Versionen bis Delphi 5 funktionieren (ich verwende die aktuelle Version noch mit Delphi 6).
Möglicherweise ist die alte Version nicht richtig deinstalliert ...
Anstatt eines Patchs würde ich empfehlen, Indy komplett ohne Packageinstallation zu verwenden. Dazu die Pfade Lib/Core, Lib/Protocols und Lib/System in den Suchpfad des Projekts einbinden.

Bedeutet wie folgt verfahren?

Code:

1.
alle Verweise in der IDE auf den Ordner "C:\Programme\Borland\BDS\4.0\lib\Indy10" mit den DCUs rauswerfen. 
2.
"Indy10 — Revision 5187: /tags/Indy 10.6.0 - XE4 RTM/Lib" runterladen und z.B. in 
den Ordner "C:\Programme\Indy10\lib" kopieren
3.
Folgende Pfade dann in der IDE unter "Tools_Options_Environment-Options_Delphi-Options_Library-Win32_Library path" eintragen.
"C:\Programme\Indy10\lib\core"
"C:\Programme\Indy10\lib\protocols"
"C:\Programme\Indy10\lib\system"

und das funktioniert auch mit den vohandenen Komponenten in den Formularen

[mjustin]

Zitat von cramer:

Bedeutet wie folgt verfahren?

Code:

1.
alle Verweise in der IDE auf den Ordner "C:\Programme\Borland\BDS\4.0\lib\Indy10" mit den DCUs rauswerfen. 
2.
"Indy10 — Revision 5187: /tags/Indy 10.6.0 - XE4 RTM/Lib" runterladen und z.B. in 
den Ordner "C:\Programme\Indy10\lib" kopieren
3.
Folgende Pfade dann in der IDE unter "Tools_Options_Environment-Options_Delphi-Options_Library-Win32_Library path" eintragen.
"C:\Programme\Indy10\lib\core"
"C:\Programme\Indy10\lib\protocols"
"C:\Programme\Indy10\lib\system"

und das funktioniert auch mit den vohandenen Komponenten in den Formularen

Fast!

1. - Alles was da ist kann da bleiben. Die bestehende Package-Installation sollte man nur anfassen wenn man sehr viel Zeit hat, denn wenn etwas anschliessend nicht mehr zusammenpasst muss alles rückgängig gemacht werden. Mein Vorschlag, die neue Indy Version nur projektlokal zu konfigurieren, ist sicherer und zeitsparend, da keine Packages installiert werden.
2. - Trunk ist aktuell 5187, warum die unter dem XE4 Tag steht ist mir unbekannt. Neueste Version herunterladen, und Changelog lesen. (Indy ist nie "stable", auch die XE Release-Versionen können buggy sein, und nach der Veröffentlichung werden dann gemeldete Bugs im Trunk gefixt, nie im Tag).
3. - Wenn man die Pfade nur als Suchpfad in dem Projekt hinterlegt, in dem man die neuen Indy Versionen testen will, braucht man den Library Path nicht anzufassen. Vorteil: alle anderen Projekte arbeiten wie bisher mit den installierten Packages.

Wenn man bereits Komponenten in Formularen und Datenmodulen platziert hat, kann dies unter Umständen dennoch funktionieren: die Komponenten greifen zur Designzeit auf die Packages zurückt, kompilieren kann man die Anwendung dann aber gegen die neue Indy Version (ausser beim Einsatz von Laufzeit-Packages). Nur wenn man Methoden benutzt, deren API sich geändert hat, wird es Probleme geben. Ich verwende daher GExperts und wandle damit die Komponenten in Sourcecode um. Dadurch kann man sehr viel einfacher - ohne Package-Installationshölle - auf andere Indy Versionen switchen, wenn man mit der verwendeten auf einen Bug stößt und auf eine ältere wechseln will.

[cramer]

Super, danke für die Tips.

1. + 3 - Habe ich so gemacht, klappt prima, nur an 4 Stellen im Programm musste eine SMTP Constante angepasst werden.
2. - Trunk ich habe die 5188

Wohl war Zitat "Package-Installationshölle"

Problem ist nur, das ich trotz Beachtung des Hinweise immer noch den Fehler habe:

"Could not load SSL library"

Hinweis:
Mit dem letzten Indy Trunk (10.2.3) oder dem Source aus dem Indy SVN werden die Indy OpenSSL DLLs nicht länger benötigt.
In diesem Fall verwenden Sie die DLLs aus dem Verzeichnis "openssl-0.9.8h - DLLs - Default - Win32".
Die neuen Headerfiles dürfen dann auch nicht verwendet werden.

[Klaus01]

.. ich weiß nicht ob es schon angesprochen wurde..
Deine Applikation ist eine 32bit Applikation, dann solten auch die ssl DLLs die 32bit Version sein.
Hast Du eine 64bit Applikation, dann musst Du die 64bit ssl DLLs verwenden.

Grüße
Klaus

[mjustin]

Zitat von cramer:

"Could not load SSL library"

Die aktuellen SSL DLLs sind hier zu finden:

http://indy.fulgan.com/SSL/

Aktuell zur Zeit ist die Version 1.0.1i vom 8. August 2014

Damit sollte es auf Anhieb funktionieren. Warum die 0.9.X und die 1.0.X DLLs nicht kompatibel sind kann ich leider nicht erklären (API Änderungen?).

Man kann über eine Indy Methode (WhichFailedToLoad in Unit IdSSLOpenSSLHeaders) jedoch beim Scheitern des DLL Ladens etwas mehr Informationen erhalten.

Beispiel (von Stackoverflow):

Delphi-Quellcode:

procedure TForm32.Button1Click(Sender: TObject);
var
  output: TMemoryStream;
begin
  output := TMemoryStream.Create;
  try
    IdHTTP.Get('https://localhost:444/Folder/service.svc', output);
    output.Position := 0;
    Memo1.Lines.LoadFromStream(output);
  except
    on E: Exception do
    begin
      ShowMessage(WhichFailedToLoad);
    end;
  end;
end;

Hope this helps,

[cramer]

Danke,

WhichFailedToLoad hatte jede Menge kryptisches Zeug angemeckert.

Nach dem Update auf die 1.0.1i dlls ist
. 1. der Fehler "Could not load SSL library." weg und
. 2. WichFailedToLoad meckert nix mehr an.

Hatte dann noch eine "privileged instruction" exeption.
Der Fehler ist jetzt aber auch weg, nachdem ich noch die
. 1. TIdHTTP und
. 2. TIdAntiFreeze
per GExperts "ComponentsToCode" aus der "Package Hölle " befreit habe.

Nun habe ich nur noch ein paar OnXxxx Ereignisse, die nicht mehr kompatibel sind.

Code:

//OnStatusInfo := IdSSLIOHandlerSocket1StatusInfo;
//OnWork       := HTTPWork;
//OnWorkBegin  := HTTPWorkBegin;

Wie bekommt man denn jetzt ohne Visuelle Komponente die richtigen Proceduren mit den entsprechenden Parametern raus
Okay, habs gefunden, die Events aus den Indy Quellcodes raussuchen und entsprechend anpassen.
alte Parameter "... const AWorkCount : integer);"
neue Parameter "... AWorkCount : int64);"