ServicePacks für .Net

[lizzard]

Danke Bernd! Ich hab das auf dem Zweitsystem mal ausprobiert, die bisherigen Fehlermeldungen kommen nicht mehr, dafür bei jedem Compile-Vorgang

Code:

[Fehler] Methode '&op_Implicit' mit identischen Parametern und Ergebnistyp bereits vorhanden
[Fehler] Methode '&op_Implicit' mit identischen Parametern und Ergebnistyp bereits vorhanden
[Fehler] Methode '&op_Implicit' mit identischen Parametern und Ergebnistyp bereits vorhanden
[Fehler] Methode '&op_Implicit' mit identischen Parametern und Ergebnistyp bereits vorhanden
[Fataler Fehler] SU.Plugin.dpk(32): Interner Fehler: U1590

Nach dem Compilieren ist eine dcpil-Datei da, der "Interne Fehler U1590" bleibt im Gegensatz zu vorher immerhin stabil der gleiche, ich kriege jetzt nicht mehr völlig unterschiedliche Fehler. Mein Testprojekt war ein Package, das gleiche Phänomen taucht allerdings bei Exe-Assemblies auch auf.

Weiß jemand, wo man was zu den internen Fehlern finden kann?

[Bernd Ua]

Hi

was die Compilerfehler angeht, kann ich mich dunkel an eine Dokument erinnern,
in dem etwas zu den Buchstaben stand L für Linker etc pp - ich finde es nur leider nicht mehr.
Das einzige was ich wieder gefunden habe war das hier
( was Dir beim konkreten Problem aber nicht viel nützen wird)

http://homepages.borland.com/strefet...ernalError.htm

Ansonsten muss ich gestehen, dass ich nach dem Motto "never Change a Running System" das Svp
noch nicht eingespielt hatte ( wäre wohl sonst ein lustiges Training geworden am nächsten Tag <g>)

Nevertheless - bin gerade dabei es zu tun (erstmal in einer eigenen Virtual Machine ),
mal schauen was bei mir raus kommt

Bernd

[Bernd Ua]

Soooo - jetzt hab ich es getestet.

Svp 1.1 für NET + Upd2 für D8 + "Shotgun-Fix"

Ergebnis, für WinForms u. ASP.NET geht der Shotgun-Fix.

Was man ausserdem machen sollte ist:
- dcpil im Projektverzeichnis löschen, danach :
- Referenzen im Projekt merken (System.Data, System.Drawing etc) und dann löschen
- Referenzen neu zufügen

Bei VCL.NET bekomme ich auch den internen Compilerfehler Uxxxx.
Entfernen und zufügen der Referenz auf von Borland.Delphi.Dll bringt nix.
Aber : Wenn für die Borland.Packages statisches Linken aktiviert wird geht es !
( Projektverwaltung, Referenz auswählen -> Units verknüpfen im Objektinspektor)
Dh temp kann man normale, kleine VCL.NET Applikationen mit dem Shotgun-Fix erstmal kompilieren.

Anwendungen mit dyn. Packages und eigene Packages o.ä. gehen erstmal nicht, da es
Delphi.System nur einmal geben darf, schliesst sich das mit Packages zur Zeit aus :-(

Das allerschlimmste aber ist, dass das ServicePack jetzt im automatischen Update drin ist
und bei dem einen oder anderen System automatisch installiert wird.

Bernd

[lizzard]

Genau die Sache mit dem automatischen Update ist halt sehr ärgerlich - ich habs hier mal per SUS geblockt, aber das kann ja nicht die Lösung sein (hoffe ich). Auf der Testmaschine kann ich auch mit deiner Vorgehensweise leider keinen Compile hinkriegen (nebenbei: ich habe nur WinForms-Anwensungen, VCL.NET benutze ich gar nicht).

Seis drum: die Compilate laufen jedenfalls mit oder ohne SP auf allen Zielrechnern, die ich bisher getestet habe, und das ist ja schonmal was. Und so bleib ich jetzt bei SP und ohne Update 2, denn letztlich funzt es so sehr gut - da das SP ist auf den Zielrechnern halt in absehbarer Zeit überall drauf, das ist für mich entscheidender.

Und ganz ehrlich, so oder so: die Architektur und die Möglichkeiten von .NET find ich trotzdem genial - der kleine Informatiker freut sich halt über Modularität und stringente OO. Da kann ich mit solchen Unschönheiten leben...

Grüßle,
Phil

[Bernd Ua]

Hi lizzard,

Zitat:

(nebenbei: ich habe nur WinForms-Anwensungen, VCL.NET benutze ich gar nicht).

In deinem Fehlermeldungen tauchte aber ein Plugin-Package auf, das ist eine Borland-spezifische Sache,
insofern als "normale" .NET Assemblies garnicht statisch gelinkt werden könnten, im Gegensatz zu Packages
unter Delphi 8.

Bernd

[lizzard]

Hi Bernd -

das ist eine normale .NET-Assembly, die lediglich als dynamische Referenz Borland.Delphi.dll enthält - das Ergebnis ist eine Assembly, die ich über einen eigenen Plugin-Loader dynamisch lade. Das klappt eigentlich perfekt, und VCL.NET ist da soweit ichs übersehe nicht im Spiel - oder täusch ich mich da?

Viele Grüße
lizzard

[Bernd Ua]

Zitat:

und VCL.NET ist da soweit ichs übersehe nicht im Spiel - oder täusch ich mich da?

Nein VCL.NET nicht, da täuscht Du dich nicht.
Habe mich wohl etwas undeutlich ausgedrückt :-)
Das Problem ist die Borland.Delphi.DLL, die für Packages benötigt wird
und die zur Zeit das Problem mit Svp1 macht.
Sobald Du ein Package machst, kommst Du um diese DLL nicht drum herum.
Für das Scenario (Plugin Framework), was Du da beschreibst brauchst Du das
aber eigentlich nicht,das geht IMHO mit puren Assemblies genauso.

Grüsse Bernd

[sakura]

Danny Thorpe, derjenige, der bei der Delphi Compiler Entwicklung den Hut auf hat soll auf der BorCon einen Fix für das SP1.1 Problem bis Ende nächster Woche angekündigt haben.

...:cat:...

[sakura]

Es gibt leider noch kein Update für Delphi 8, aber Danny Thorpe arbeitet daran:
http://homepages.borland.com/dthorpe...63479886920612

...:cat:...

[sakura]

Update zum Service Pack für Delphi 8.

...:cat:...