Zweiter versuch RIO vs Tokyo TStringDynArray

[TiGü]

Wird denn der "Webservice Interfaceteil", also die Pascal-Unit, die aus der WSDL entstanden ist, denn auch immer mit (neu) kompiliert? In beiden IDE-Versionen / Projekten?

[QuickAndDirty]

Zitat von TiGü:

Wird denn der "Webservice Interfaceteil", also die Pascal-Unit, die aus der WSDL entstanden ist, denn auch immer mit (neu) kompiliert? In beiden IDE-Versionen / Projekten?

Der Webservice interfaceteil wird nur in RIO kompiliert . Also der auf seiten des Servers!
Der Client Webservice Interfaceteil wird sowohl in RIO als auch in TOKYO kompiliert, weil ich die APP ja builden muss!
Die Code Generierung für den Client machen ich mit RIO weil der Server ja auch mit einem RIO Kompilat läuft.

[TiGü]

Aha, du hast erneut die WSDL importiert und der Importvorgang ersetzt den TStringDynArray-Alias mit dem dahinter liegenden Typen (TArray<string>) beim Import.
Unschön, aber nachvollziehbar. Ggf. kann man das mit einen der unzähligen Einstellmöglichkeiten des WSDL-Imports steuern.

Aber warum importierst du neu?
Es würde doch ausreichen WebserviceClient.pas nur einmalig zu importieren (in Berlin oder Tokyo) und diese Unit auch in dem Projekt zu verwenden, das mit Rio gebuildet wird. So dass die Aliase erhalten bleiben.
Dann sollte dein Problem auch verschwinden.

[QuickAndDirty]

Ich importiere die ja auch nur einmal für beide compilate!
Leider will Tokyo den Import nicht von RIO nicht! Und er passt ja auch offensichtlich nicht!
Es sei denn ich stelle in diesem seit XE8 gewachsenen sehr umfangreichen projekt alle verwendung von DYNARRAYs und WEBSERVICE aufrufe um.

Das Problem ist nicht eine code stelle wo ich ein DYNARRAY übergebe sondern das ich das eben extensiv nutze..


Ich habe zuletzt neu importiert, weil in RIO TXSDatetime einen bug hat und den Client crashed wenn man TXSDatetime.AsDatetime := 0.0 schreibt.
Habe also neue Funktionen eingebuat die Datetime als iso8061 transportieren....

Außerdem entwickle ich den Webservice und die App immer weiter und muss immer wieder neu importieren...

So importiere.
Import Script für batch file

Code:

c:
cd c:\myproject\MYSCLIENT
powershell.exe -Command "(new-object System.Net.WebClient).DownloadFile('http://myapp.mycompany.com:1234/wsdl/IMyWebService','IMyWebServiceClient.xml') "
Pause
c:
CD C:\Program Files (x86)\Embarcadero\Studio\20.0\bin
WSDLIMP -P -Ov+ -Oz- -DC:\myproject\MYSCLIENT C:\myproject\MYSCLIENT\IMyWebServiceClient.xml
Pause

Ich brauche aber vermutlich eine lösung für den EXPORT...

Diese inkompatible Umstellung der Typen ist für mich echt nicht schön....
Vielleicht hilft es eine eigene System.types zu verwenden... vorrausgesetz Embarcadero hat seine eigenen bibliotheken nicht auch umgestellt und ist jetzt auf diesen geänderten Typ angewiesen...

[TiGü]

Zitat:

Leider will Tokyo den Import nicht von RIO nicht! Und er passt ja auch offensichtlich nicht!

Dreh das mal um, dann wird alles gut!
In Tokyo importieren, die Aliase bleiben erhalten und kann in Rio-Projekt verwendet werden.

[TiGü]

Hat jetzt nur sekundär mit deinen Problem zu tun, aber vielleicht hilft es den einen oder anderen interessierten Leser bei ähnlichen Problemen:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

type
  TMyLittleStringArray1 = array of string;
  TMyLittleStringArray2 = TArray<string>;
  TMyLittleStringArray3 = TArray<string>;
  TMyLittleStringArray4 = TMyLittleStringArray1;
  TMyLittleStringArray5 = type TMyLittleStringArray1;
  TMyLittleStringArray6 = array of string;

var
  One: TMyLittleStringArray1;
  Two: TMyLittleStringArray2;
  Three: TMyLittleStringArray3;
  Four: TMyLittleStringArray4;
  Five: TMyLittleStringArray5;
  Six: TMyLittleStringArray6;
begin
//  One := Two; // [dcc32 Error] Project1.dpr(19): E2010 Incompatible types: 'TMyLittleStringArray1' and 'System.TArray<System.string>'
//  Two := One; // [dcc32 Error] Project1.dpr(20): E2010 Incompatible types: 'System.TArray<System.string>' and 'TMyLittleStringArray1'
  One := TMyLittleStringArray1(Two); // geht durch casten
  Two := TMyLittleStringArray2(One); // geht durch casten
  Three := Two; // geht, weil beide Typen nur ein Alias sind für TArray<string>
  Two := Three; // geht, weil beide Typen nur ein Alias sind für TArray<string>
  One := Four; // geht, weil nur Alias und sonst gleicher Typ
//  Five := One; // geht nicht, da durch type Schlüsselwort ein neuer Typ gebildet wird
//  One := Six; // geht auch nicht, weil neuer Typ -> ja, auch wenn bei beiden = array of string steht
end.

[QuickAndDirty]

Zitat von TiGü:

Hat jetzt nur sekundär mit deinen Problem zu tun, aber vielleicht hilft es den einen oder anderen interessierten Leser bei ähnlichen Problemen:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

type
  TMyLittleStringArray1 = array of string;
  TMyLittleStringArray2 = TArray<string>;
  TMyLittleStringArray3 = TArray<string>;
  TMyLittleStringArray4 = TMyLittleStringArray1;
  TMyLittleStringArray5 = type TMyLittleStringArray1;
  TMyLittleStringArray6 = array of string;

var
  One: TMyLittleStringArray1;
  Two: TMyLittleStringArray2;
  Three: TMyLittleStringArray3;
  Four: TMyLittleStringArray4;
  Five: TMyLittleStringArray5;
  Six: TMyLittleStringArray6;
begin
//  One := Two; // [dcc32 Error] Project1.dpr(19): E2010 Incompatible types: 'TMyLittleStringArray1' and 'System.TArray<System.string>'
//  Two := One; // [dcc32 Error] Project1.dpr(20): E2010 Incompatible types: 'System.TArray<System.string>' and 'TMyLittleStringArray1'
  One := TMyLittleStringArray1(Two); // geht durch casten
  Two := TMyLittleStringArray2(One); // geht durch casten
  Three := Two; // geht, weil beide Typen nur ein Alias sind für TArray<string>
  Two := Three; // geht, weil beide Typen nur ein Alias sind für TArray<string>
  One := Four; // geht, weil nur Alias und sonst gleicher Typ
//  Five := One; // geht nicht, da durch type Schlüsselwort ein neuer Typ gebildet wird
//  One := Six; // geht auch nicht, weil neuer Typ -> ja, auch wenn bei beiden = array of string steht
end.

Sowas ist wieder ein klassischer Fall von Irrsin der einen Ducktyping vermissen lässt oder?
Gerade beim bilden der SOAP Schnittstelle...

[QuickAndDirty]

Je nach dem ob das Problem beim erstellen oder beim importieren der WSDL Datei passiert.

Das ganze stimmt mich alles etwas traurig...

[TiGü]

Zitat von QuickAndDirty:

Je nach dem ob das Problem beim erstellen oder beim importieren der WSDL Datei passiert.

Das ganze stimmt mich alles etwas traurig...

Die Pascal-Unit für den Client wird doch DURCH das importieren erst erstellt!?

Du musst einfach für alle Projekte (egal ob Delphi 7, 2009, Berlin, Tokyo, Rio oder Buxtehude am Ende kompiliert und gebaut) diejenige importierte Client-Unit nehmen, die noch die TXXXDynArray-Aliase für die Member und Properties deiner SOAP-Objekte hat.
Dann ist alles gut und es gibt kein Problem.