Problem mit DCPIL Files

[Boombuler]

Hi @ all

so ich bin gerad dabei unsere 1,2 Mio. Zeilen Quellcode von VCL auf VCL.net zu portieren. Dabei haben wir Thirdparty Komponenten welche wir in einem Assembly vorliegen haben. Diese Komponenten sind mit Delphi geschrieben. Deshalb brauche ich vom Hersteller die DCPIL File dieses Assemblys. Der hat sie mir auch nach 2 Wochen betteln entlich geschickt.
Problem: So wie das aussieht programmieren diese Leute mit D2006 und wir mit D2005 deswegen meint Delphi, "Falsches Dateiformat 'xxxx.dcpil'".

Meine nächste Überlegung war eine Wrapper Klasse in C# zu schreiben weil C# keine dcpils braucht. ABER: Dank eines coolen Bugs in Delphi kann ich keine C# Assemblies importieren die Irgendwo von einer Delphi Klasse erben...

So langsam gehen mir die Ideen aus wie ich das noch zum laufen kriegen soll...

Ich bin für jede Hilfe Dankbar...

Greetz
Boombuler

PS: Wenn ich noch mehr von diesen Aktionen erlebe freu ich mich demnächst sogar drauf auf C# umzusteigen :(

[Bernhard Geyer]

Du setzt Komponenten ein von denen Du keine Sourcen besitzt? Wieso denn das? Das ist eigentlich ein großer Vorteil in Delphi das man bei einem Versionswechsel der IDE nicht auf gedeih und verderb auf den Hersteller angewießen ist und im Notfall selbst Anpassungen vornehmen könnte.

Aber Grundsätzlich: Wieso willst Du eine (ich denke es ist eine "normale" GUI-Anwendung) nach .NET-Portieren. Welchen Vorteil versprichst Du dir?

[Boombuler]

Zitat:

Zitat von Bernhard Geyer

Du setzt Komponenten ein von denen Du keine Sourcen besitzt? Wieso denn das? Das ist eigentlich ein großer Vorteil in Delphi das man bei einem Versionswechsel der IDE nicht auf gedeih und verderb auf den Hersteller angewießen ist und im Notfall selbst Anpassungen vornehmen könnte.

War nicht meine Idee... Aber wenn das da drin ist darf ich das auch mit umstellen...

Zitat:

Zitat von Bernhard Geyer

Aber Grundsätzlich: Wieso willst Du eine (ich denke es ist eine "normale" GUI-Anwendung) nach .NET-Portieren. Welchen Vorteil versprichst Du dir?

Auf VCL.NET zu gehen ist nur der erste Schritt... Letztendlich werden wir nach C# gehen. Und wir können nicht 1 Jahr nichts mehr weiterentwickeln um die Umstellung direkt zu machen, weil uns sonst unsere Kunden aufs Dach steigen!

Aber back to topic: Hat wer ne Idee?

[Elvis]

Zitat:

So langsam gehen mir die Ideen aus wie ich das noch zum laufen kriegen soll...

Tja, der ganze Krempel, der an jede D.Net Klasse/Assembly gewurschtelt wird, macht dich von der Borland.Delphi.Dll abhängig.
Da diese zwischen den Delphi-Versionen verändert wird hast du mit D.Net natürlich die Rektalkarte. ;)

Du hast allerdings einen Ausweg. Wenn die Assemblies von der Firma nicht signiert sind, kannst du sie so patchen, dass sie die Borland.Delphi.dll von BDS2005 referenzieren. Nicht schön, aber wenigstens ein Weg. ;)
Den Source code zu kaufen wäre wohl zu einfach? *g*

Zitat:

Zitat von Boombuler

PS: Wenn ich noch mehr von diesen Aktionen erlebe freu ich mich demnächst sogar drauf auf C# umzusteigen :(

Nur so am Rande: C# heißt alles nehmen und wegschmeißen.
Dephi32/VCL -> Delphi.Net/VCL -> Chrome/ShineOn -> Chrome/FCL wäre ein Weg um eine Migration zu "reinem" .Net/Mono zu ermöglichen, in der du durchgehend eine funktionierende, debugfähige Code basis hast.
Und am Ende hast du mit Chrome Assemblies und eine Sprache, die denen von C# in nichts nachstehen. (im Gegenteil, der Chrome output wird sogar ständig gegen Mono geprüft :zwinker: )

[Bernhard Geyer]

Zitat:

Zitat von Boombuler

Auf VCL.NET zu gehen ist nur der erste Schritt... Letztendlich werden wir nach C# gehen. Und wir können nicht 1 Jahr nichts mehr weiterentwickeln um die Umstellung direkt zu machen, weil uns sonst unsere Kunden aufs Dach steigen!

Strategische Entscheidung oder nur das man auch in einiger Zeit was in .NET hat? Mit einem VCL.NET-Projekt gewinnt man auch keinen Blumentopf.

Zitat:

Zitat von Boombuler

Aber back to topic: Hat wer ne Idee?

Nicht Back to the Topic! Evtl. ist VCL.NET der vollkommen falsche Ansatz. Schau dir mal Hydra an. U.u. ist dies ein viel besserer Weg als den Borland vorschlägt. Soweit ich das verstehe bleibt dein Win32-Code praktisch unverändert und schnappst .NET-Controls/Panels in dein Win32-Formulare ein so wie du z.B. mittels TFrame arbeiten könntest.

Vorteil:
- Code bleibt wirklich unverändert und muß erst nicht VCL.NET-Kompatible gemacht werden
- Man ist mit einem Schritt bei neuen Dingen gleich bei C#

Nachteil (Von Borland-Sicht):
- Kompilierbarkeit als reine Win32-Anwendung für das komplette Projekt ist nicht mehr möglich