Announcement

**Andreas Kosch** · 02.09.2004, 12:07

Hallo,

ich habe das SP1 zwar noch nicht installiert, aber auch die Installation vom .NET Framework 2.0 setzt den Delphi 8-Kompiler au�er Funktion (der Borland C#Builder 1.0 wird im Gegensatz dazu aber nicht beeintr�chtigt).

>Offenbar �berschreibt das Servicepack irgend einen zentralen Suchpfad.

Das glaube ich nicht, denn alle "wichtigen" Teile sollten im GAC (Global Assembly Cache) bereitliegen - und dort wird jede Version separat archiviert. Ich vermute einmal, dass sich Delphi 8 (Win32-Anwendung, die als Host das .NET Framework nur zus�tzlich einbindet) zu eng an mscorlib/mscoree.dll bindet. Wird dann nicht die erwartete Version vorgefunden, scheint es zu Haken.

Tritt der Effekt auch beim dem folgenden Mini-Projekt auf?
<pre>
library Library1;
 
{%DelphiDotNetAssemblyCompiler 'c:\programme\gemeinsame dateien\borland shared\bds\shared assemblies\2.0\Borland.Delphi.dll'}
 
uses
System.Reflection;
 
[assembly: AssemblyVersion('1.0.0.0')]
 
const
cDATA = 'Testdaten';
 
begin
end.
</pre>
&#10

**Peter M�ller-Mannhardt** · 02.09.2004, 12:23

Danke Andreas Kosch,
Das Mini-Projekt l�sst sich ohne Fehlermeldung �bersetzen. Interessanterweise auch, wenn die {%DelphiDotNetAssemblyCompiler Zeile auskommentiert wird. Was zeigt uns dass? 
PM

**Andreas Kosch** · 02.09.2004, 12:28

Hallo,

in diesem Fall w�rde ich das Experiment wiederholen, nachdem der uses-Auflistung die Eintr�ge SysUtils, Classes hinzugef�gt wurden und die Library-Assembly irgend eine Funktion aus SysUtils aufruft.

Das n�chste Experiment k�nnte untersuchen, ob im Objektinspektor der Eintrag Link Units f�r Borland.Delphi.dll eine Auswirkung auf das Verhalten hat

**Peter M�ller-Mannhardt** · 02.09.2004, 13:21

Das Projekt sieht nun so aus: <PRE>
library Library1;

{%DelphiDotNetAssemblyCompiler 'c:\programme\gemeinsame dateien\borland shared\bds\shared assemblies\2.0\Borland.Delphi.dll'}

uses
System.Reflection,
SysUtils, Classes ;

[assembly: AssemblyVersion('1.0.0.0')]

const
cDATA = 'Testdaten';
MyData = sysUtils.fmOpenRead;
begin
end
</PRE>
und l�sst sich immer noch compilieren. 
Was hasst du mit: 
"..,ob im Objektinspektor der Eintrag Link Units f�r Borland.Delphi.dll eine Auswirkung auf das Verhalten hat" genau gemeint? 
Ich denke, ich sollte das NET Framework de- und dann ohne SP1 neu-installieren. Sind dabei Besonderheiten zu beachten/erwarten? 
PM

**Peter M�ller-Mannhardt** · 02.09.2004, 18:47

Fataler weise hatte auch dies keinen Erfolg. Jetzt bin ich ratlos! Was kann man noch tun? 
PM

**Peter M�ller-Mannhardt** · 02.09.2004, 20:51

Nach dem ich NET und D8 deinstalliert und anschliessend in der Reihenfolge NET / D8 / D8_Upd2 erneut installiert habe, ist der Spuk verschwunden - um einem neuen Problem Platz zu machen: 
1. Build Versuch f�r mein zuvor complierbares Projekt ergiebt: 
[Fataler Fehler] TBuchNet.dpr(1): 'Never-build' Package 'System' muss neu compiliert werden 
2. Versuch mit dem gleichen, unver�nderten Projekt: 
[Fataler Fehler] TBuchNet.dpr(1): Unit Borland.Delphi.System wurde mit einer unterschiedlichen Version von System.Attribute compiliert 
Bin wohl von der DLL-H�lle direkt in die NET-H�lle gelangt. Ich weiss noch nicht welche mir besser gef�llt :-( 
Was soll ich tun

**Stefan Bedel** · 03.09.2004, 09:47

Leider scheint hier ein grunds�tzliches Problem mit dem Net-Framework-Service-Pack und Delphi 8 vorzuliegen. Nach Installation des SP l�sst sich nicht einmal eine neue, leere Windows Form-Anwendung ausf�hren. Versuchr man sie zu starten gibt es den Fehler:
[Fataler Feler] Project1.dpr(1): Package 'Borland$' wird ben�tigt, konnte aber nicht gefunden werden.
Geht man �ber Projekt compilieren, wird das mit:
[Fataler Feler] Project1.dpr(1):Unit Borland.Delphi.System wurde mit einer unterschiedlichen Version von System.Diagnostics.Process compiliert quittiert.
Ich habe das Framework und Delphi deinstalliert und wieder installiert. Leider ohne Erfolg.
Braucht es vielleicht ein Update von Borland

**eMPie** · 03.09.2004, 11:35

Don't panic!

.NET Framework und BDS deinstallieren ist nicht n�tig.

1. Versuch:
Alle Referenzen aus dem Projekt entfernen und dieses komplett neu erzeugen, d.h. alle DCUIL, EXE u.�. Dateien vorher l�schen.
Notwendige Referenzen wieder einf�gen.

2. Versuch:
Alle Referenzen aus der Projektdatei mittels Editor entfernen.

3. Versuch:
Ein neues Projekt erstellen und alle Source (PAS-Dateien) hinzuf�gen

**Peter M�ller-Mannhardt** · 04.09.2004, 08:32

Methode 3 scheint hier zu funktionieren - ich bin allerdings noch nicht durch. 
Bei mir ist es nur ein Hobby / �bungsprojekt. Wenn ich mir aber vorstelle, so was passiert in einem kommerziellen Projekt kann schon Panik aufkommen. Insgesamt zeigt das doch, das MS mit einem kleinen Update die Entwicklungsumgebung der Konkurrenz aushebeln kann. Ob bewusst oder unbewusst ist dabei schon fasst egal. 
Wenn ich demn�chst eine Empfehlung f�r eine NET - Entwicklungsplattform in unserer Firma aussprechen soll, komm mir "Borland D8" vermutlich nur sehr z�gerlich �ber die Lippen... 
PM

**Andreas Kosch** · 06.09.2004, 07:04

Hallo,

>..das MS mit einem kleinen Update die Entwicklungsumgebung der Konkurrenz aushebeln kann...

hier ist nicht MS der �bert�ter. Delphi 8 generiert *.dcuil-Dateien, um sich beim Kompilieren einen Geschwindigkeitsvorteil zu verschaffen. Das hat allerdings auch Nebenwirkungen. In meinem Crashkurs-Buch liest sich das so: "Wird nun ein Programm compiliert, so muss der Compiler alle Daten nicht erst m�hsam zur Laufzeit ermitteln, sondern er greift statt dessen sofort auf die bereits in bin�rer Form vorliegenden Informationen zur�ck. Der Haken an der Sache ist nur der, dass dieser Weg immer dann in die Irre f�hrt, wenn sich die Versionsnummer einer der betroffenen Assemblies in der Zwischenzeit ge�ndert hat. W�hrend die Microsoft-Compiler diese Daten erst zur Laufzeit beim Compilierungsvorgang ermitteln und somit nicht von einer anderen Versionsnummer betroffen sind, hat die von Borland gew�hlte �Abk�rzung� zwangsl�ufig die Nebenwirkung, dass diese Dateien nach jedem Versionswechsel vorher aktualisiert werden m�ssen.".

P.S: Zum Beispiel verzichtet der Delphi.NET-Konkurrent Chrome (http://chrome.remobjects.com) v�llig auf die vorkompilierten DCUIL-Dateien, so dass dieses Problem dort nicht auftritt. Ich gehe davon aus, dass auch Borland wieder auf den "Pfad der Tugend" zur�ckkehren wird

**Peter M�ller-Mannhardt** · 06.09.2004, 07:29

>..hier ist nicht MS der �belt�ter 
Es ist halt f�r Otto Normalentwickler sehr schwierig, den "�belt�ter" zu ermitteln. Insbesondere wenn, wie in realen Projekten unvermeidlich, noch 3Party Komponenten mit ihren Macken dazu kommen. Hier scheint mir der Unterschied zwischen NET- und DLL-H�lle z.Z. nur marginal zu sein und Borland l�sst seine seine Clientel wohl ziemlich im Regen stehen. 

>..Der Haken an der Sache ist nur der, dass dieser Weg immer dann in die Irre f�hrt, wenn sich die Versionsnummer einer der betroffenen Assemblies in der Zwischenzeit ge�ndert hat... 

Eigentlich sollte dann doch ein "Build" die Sache bereinigen k�nnen oder? Tut es bei mir aber definitiv nicht. 
PM

**Stefan Bedel** · 06.09.2004, 10:13

L�uft �berhaupt bei irgend jemand D8 mit dem SP ?

Wie bereits gesagt l�sst sich nicht mal eine neue, leere WinForm-Anwendung compilieren.
Gibt es eigentlich irgend eine Reaktion von Borland ? Ich finde n�mlich nichts und dieses Problem m�ssten doch wirklich eine Menge Entwickler haben.
Von der Seite gesehen ist der Support bei Borland wirklich schlecht. Bei BP7 gab es ja auch schon einmal das Problem mit CRT und schnellen Rechnern. Aber da gab es wenigstens z�gig einen Patch.

Das �rgerliche ist auch, dass das Problem auch nach einer kompletten Deinstallation und Reinstallation des Frameworks, SDK und D8 weiterhin besteht. Ein Hoch auf ein Immage oder mehrer Rechner aber das kann es doch nicht sein

**Peter M�ller-Mannhardt** · 06.09.2004, 12:06

Im Forum: borland.public.delphi.nontechnical gibt es einen Thread zum Thema. Dort wurde folgender Link ver�ffentlicht: 
http://blogs.borland.com/abauer/archive/2004/09/01/1208.aspx 
Nutzen tut's nix, aber man f�hlt sich nicht so alleine.. 
PM

**Andreas Kosch** · 07.09.2004, 06:20

Hallo,

>Eigentlich sollte dann doch ein "Build" die Sache bereinigen k�nnen oder?

aus Geschwindigkeitsgr�nden (das einmalige Generieren der *.dcuil/dcpil-Dateien f�r externe Assemblies dauert unter Umst�nden seine Zeit) werden beim Build nur die "eigenen" Units neu kompiliert. Manche Entwickler legen daher immer eine BAT-Datei im Projektverzeichnis an, die regelm��ig aufr�umt (d.h. diese und andere tempor�re Dateien l�scht). Denn auch im regul�ren Betrieb kommt ja Delphi 8 h�ufig so au�er Tritt, dass man die IDE beenden, �ber die BAT-Datei aufr�umen und dann Delphi 8 neu starten muss.

---

>..nach einer kompletten Deinstallation ...

Die Frage ist, wie "komplett" die Deinstallation war. Denn neben dem GAC (der u.U. vom Hand aufger�umt werden muss) gibt es da noch ein kritisches Element. Die in jedem Fall eingebundene DLL mscoree.dll (exportiert die Routine _CorExeMain) liegt nur einmal vor, d.h. hier �berschreibt eine neue .NET Framework-Version die alte Version (diese DLL liegt im System32-Unterverzeichnis von Windows und hat nur eine Aufgabe � sie sucht nach der auf dem Rechner installierten CLR-Version, die f�r die Anwendung ben�tigt wird)

Announcement

NET Framework Servicepack 1.0 zerschiesst D8!?

NET Framework Servicepack 1.0 zerschiesst D8!?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment