Zweiter versuch RIO vs Tokyo TStringDynArray

[Stevie]

Seit der Einführung von TArray<T> hab es immer wieder das Problem, dass ein TArray<string> nicht kompatibel war zu TStringDynArray , welches historisch in der RTL verwendet wurde, wenn array von string übergeben oder zurückgegeben wurde.

Daher hat man sich schon lange gewünscht (siehe RSP-16737), dass das angeglichen wird - nun endlich die Änderung in 10.3.

Die Deklaration TStringDynArray = TArray<string> ist nur ein Typalias im Gegensatz zu der vorherigen Deklaration, wo es ein neuer eigener Typ war (und nein, TStringDynArray = type TArray<string> geht nicht).

Welche Implikationen dies nun auf die Kompatibilität von Anwendungen vor und nach 10.3 hat, wurde scheinbar übersehen (war mir auch nicht klar - ich mach nix mit dem eingebauten Webservice Zeugs).

Mir ist nur gerade nicht klar, an welcher Stelle die beiden Versionen nicht kompatibel sind - in der Beschreibung der Webservice Schnittstelle nach außen? Das könnte sich durchaus fixen lassen, indem 10.3 dann erkennt, was es mit einem TStringDynArray oder wie auch immer es nach außen spezifiziert ist, anstellen soll).

Kannst du evtl ein Demoproject erstellen, um den Fehler darzustellen? Lässt sich dann auch gut als Bug bei Embarcadero reporten.

[QuickAndDirty]

Zitat von Stevie:

Kannst du evtl ein Demoproject erstellen, um den Fehler darzustellen? Lässt sich dann auch gut als Bug bei Embarcadero reporten.

Ich kann meist kein Bug reports in QC machen, weil das alles über meinen Chef gehen müsste.

Zitat von Stevie:

Mir ist nur gerade nicht klar, an welcher Stelle die beiden Versionen nicht kompatibel sind - in der Beschreibung der Webservice Schnittstelle nach außen? Das könnte sich durchaus fixen lassen, indem 10.3 dann erkennt, was es mit einem TStringDynArray oder wie auch immer es nach außen spezifiziert ist, anstellen soll).

Ich kann es mit einem Muster code verdeutlichen, so das dass problem auch ohne ein Projekt in der IDE zu öffnen deutlich wird.

Ausschnitt Interface unit des Webservice also Also Serverseitig

WebserviceIntf.pas

Delphi-Quellcode:

[...]
type

  TAnswer= Class(TRemotable)
  private
    fsuccess: boolean;
    fError: String;
  published
    property Error:String read fError write FError;       // Fehlermeldung, in der regel eine Exception
    property Success:boolean read fsuccess write fsuccess;// nur false wenn Error angezeigt werden muss
  End;

  TResponseDevicePersonRelation = Class(TAnswer)
  private
    FDevices:  TStringDynArray;
    FResource: TIntegerDynArray;
    FGroups:   TBooleanDynArray;
  public

  published
    property Devices:  TStringDynArray read fDevices write fDevices;    //Handy
    property Resource: TIntegerDynArray read fResource write fResource; //RessourcenID
    property Groups:   TBooleanDynArray read fGroups write fGroups;     //Ist Ressource eine Gruppe
  End;
[...]

Diese Klasse TResponseDevicePersonRelation wird als SOAP envelope bei einer SOAP abfrage durch den Client erzeugt....
Der Webservice erzeugt eine WSDL datei aus der sich eine dieser Delphicode wieder kompatibel erzeugen lässt!
SO SOLLTE ES SEIN!
Es galt immer für Delphi um Listen unter SOAP ordentlich abszubilden zu können müsste man DYNARRAY typen nehmen oder selber Tstrings oder TList<Tobject> serialisieren und deserialisieren.
Natürlich macht man nicht SOAP um selbst den Transport und das serialisieren programmieren zu müssen.
Also DYNARRAY

WebserviceClient.pas generiert aus WSDL datei vor Umstellung auf RIO

Delphi-Quellcode:

  TResponseDevicePersonRelation = class(TAnswer)
  private
    FDevices: TStringDynArray;
    FResource: TIntegerDynArray;
    FGroups: TBooleanDynArray;
  published
    property Devices:  TStringDynArray   read FDevices write FDevices;
    property Resource: TIntegerDynArray  read FResource write FResource;
    property Groups:   TBooleanDynArray  read FGroups write FGroups;
  end;

WebserviceClient.pas generiert aus WSDL datei nach Umstellung auf RIO

Delphi-Quellcode:

  TResponseDevicePersonRelation = class(TAnswer)
    FDevices: TArray<System.string>;
    FResource: TArray<System.Integer>;
    FGroups: TArray<System.Boolean>;
  published
    property Devices:  TArray<System.string>   read FDevices write FDevices;
    property Resource: TArray<System.Integer>  read FResource write FResource;
    property Groups:   TArray<System.Boolean>  read FGroups write FGroups;
  end;

Verwendung der klasse in der APP: Dieser Code ist nicht mehr in Tokyo compilierbar

Delphi-Quellcode:

Procedure Demo;
  function IndexOfDevice(Devices:TStringDynArray):integer
  Begin
    //bla
  end; 
  var aResponseDevicePersonRelation:TResponseDevicePersonRelation 
Begin 
  aResponseDevicePersonRelation := WebserviceClient.Request_DevicePersonRelation(a,b,c);
  myindex := IndexOfDevice(aResponseDevicePersonRelation.Devices);//<------DAS HIER KANN IN RIO KOMPILIERT WERDEN ABER IN TOKYO NICHT
end;

"DAS HIER KANN IN RIO KOMPILIERT WERDEN ABER IN TOKYO NICHT"
weil TStringDynArray in RIO ist

Code:

TStringDynArray = TARRAY<String>;

aber in Berlin ist es

Code:

TStringDynArray = array of String;

Und das mag der compiler nicht.

[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.