IDE FixPack 3.5 (2007-XE) (2010-09-12)

[MaBuSE]

Hallo,
zuerst möchte ich mal Danke sagen für Deine Tools rund um Delphi.
Wir verwenden Idefix, DDevExtentions und DelphiSpeedUp bei und im Haus mit Delphi 7, 2007 und XE und sind sehr zufrieden.

Ich habe noch einen kleinen Bug in der IdeFix 4.5 gefunden.

Beim Delphi XE Start werden einige Dateien in %TEMP% erstellt und csc.exe aufgerufen um daraus eine *.dll Datei zu erzeugen.
(*.cs, *.out, *.err, *.cmdline, *.tmp und *.dll Dateien)
Diese Dateien werden nach der Benutzung der *.dll Dateien wieder gelöscht.

Aus irgend einem Grund werden die dynxmlserializer.8.0.15_TaskMetadata.cs und dynxmlserializer.8.0.15_TaskMetadata.dll Dateien nicht in %TEMP% erzeugt, sondern in %LOCALAPPDATA%\IDEFixPack erstellt und nicht wieder gelöscht.

Wird Delphi beendet und erneut gestartet, so bleibt Delphi bei uns im SplashScreen beim Laden der DDevExtentions 2.5 hängen.

Wenn der Delphi Prozess via TaskManager gekillt wurde. Und die Dateien in %LOCALAPPDATA%\IDEFixPack wieder gelöscht wurden lässt sich Delphi wieder starten.

Auf einem lokalen PC tritt der Fehler bei uns nicht auf. Der Fehler tritt nur in unserer virtualisierten Welt auf.

Folgende Umgebung verwenden wir:

• Embarcadero RAD Studio XE Enterprise
• Embarcadero License Server
• Windows 7 64 bit

in einer

• VM auf ESX Server 4.1
• Citrix Xen Desktop 5
• AppSense
• provisionierte VHDD (Citrix provisioning Services) ReadOnly im Cached Mode

Die Daten in %LOCALAPPDATA%\IDEFixPack werden auch auf dem lokalen PC angelegt, aber dort stört sich Delphi nicht daran

Ich hoffe diese Infos helfen Dir das Problem zu lösen.

Im Moment haben wir den Workarround, das %LOCALAPPDATA%\IDEFixPack Verzeichnis vor jedem Delphi Start zu löschen.

Danke und viele Grüße
MaBuSE

[jbg]

Zitat von MaBuSE:

Aus irgend einem Grund werden die dynxmlserializer.8.0.15_TaskMetadata.cs und dynxmlserializer.8.0.15_TaskMetadata.dll Dateien nicht in %TEMP% erzeugt, sondern in %LOCALAPPDATA%\IDEFixPack erstellt und nicht wieder gelöscht.

Der Grund ist, dass dies das Cache-Verzeichnis ist, so dass der CSC.EXE Aufruf ausbleiben kann. Deswegen werden sie nicht gelöscht. (Ab XE2 ist dieser Cache nicht mehr notwendig, da Embt meinen Vorschlag mit dem Vorkompilieren und Signieren der dynxmlserializer.dll aufgegriffen hat)

Zitat:

Wird Delphi beendet und erneut gestartet, so bleibt Delphi bei uns im SplashScreen beim Laden der DDevExtentions 2.5 hängen.

DDevExtensions bleibt da nicht hängen, es ist nur das letzte IDE Plugin, das geladen wurde und seinen Text im Splashscreen hinterlassen hat.


Man kann diesen IDEFixPack Cache abschalten, indem man die Umgebungsvariable "IDEFixPack.DisabledPatches" auf den Wert "Start.XmlSerializer" (beides ohne Quotes) setzt.

Aber dass das Problem nur in der VM auftritt ist schon komisch. Bei meinen VMs (VMWare+WinXP32/Vista64) habe ich da keine Probleme.

[MaBuSE]

Zitat von jbg:

Man kann diesen IDEFixPack Cache abschalten, indem man die Umgebungsvariable "IDEFixPack.DisabledPatches" auf den Wert "Start.XmlSerializer" (beides ohne Quotes) setzt.

Danke, das werde ich nachher ausprobieren.

Zitat von jbg:

Aber dass das Problem nur in der VM auftritt ist schon komisch. Bei meinen VMs (VMWare+WinXP32/Vista64) habe ich da keine Probleme.

Wir haben einen Pool aus vielen gleichen VMs, der auf mehreren Servern gehostet wird.
Bei jeder Anmeldung bekommt der Benutzer (Entwickler) eine andere VM.
Die Umgebung des Benutzers wird durch AppSense zur Verfügung gestellt.

Das bedeutet, es existiert ein virtuelle Layer zwischen dem OS und der App. Vermutlich liegt da das Problem, z.B. dass Delphi es sieht, aber nicht darauf zugreifen kann.

Wir stellen gerade von D2007 auf XE um. Das wird bei über 40 Entwicklern auch eine Weile dauern. Bis wir dann soweit sind auf was Neueres umzusteigen gibt es bestimmt schon XE5

Danke und
Viele Grüße
MaBuSE

[jbg]

Zitat von MaBuSE:

Zitat von jbg:

Man kann diesen IDEFixPack Cache abschalten, indem man die Umgebungsvariable "IDEFixPack.DisabledPatches" auf den Wert "Start.XmlSerializer" (beides ohne Quotes) setzt.

Danke, das werde ich nachher ausprobieren.

Es reicht aber nicht aus, die Umgebungsvariable in Delphi zu setzen. Sie muss auf Benutzer- bzw. Systemebene gesetzt werden, da IDE Fix Pack die Umgebungsvariablen bereits zu einem Zeitpunkt ausliest, an dem die IDE diese noch nicht überschrieben hat.

[CCRDude]

Oh, es gibt einen eigenen Thread zum IDEFixPack, super

Da frage ich doch hier auch noch nach, ob jemand anders ebenfalls Probleme mit beendendem BDS aufgrund von "Lizenzproblemen" hat, die mit dem IDEFixPack zusammenhängen (siehe hier)?