Spaß mit Visual Studio 2008 – hier: Deployment Projekte

Da denkt man sich, man nimmt mal eben so ein Visual Studio 2005 Projekt, lädt es in Visual Studio 2008 und alles ist hipp. Naja, zumindest bei MSI Setups (Deployment Projekte) hat sich Microsoft erlaubt, einige Fehler leicht inkompatibel zu beheben.

Da ist erst einmal ein Upgrade Setup. Früher war es so, dass bei einem Upgrade erst die alte Version deinstalliert wurde und dann die neuen Dateien installiert wurden. Diese Reihenfolge wurde umgekehrt (ohne eine direkte Konfiguration, die den alten Zustand wieder herstellt). Mit dem Effekt, dass eine Datei nur noch dann ersetzt wird, wenn sich die Dateiversion (nicht der Inhalt) ändert. Bei DVB.NET ist es etwa so, dass alle Dateien die Versionsnummer des Produktes tragen, also 3.2 oder 3.5. Also kein Problem? Leider doch: während der Beta-Phase ändere ich die Versionsnummern im Allgemeinen nicht. Wird also eine 3.5 Beta über eine andere eingespielt, werden die Dateien nicht ausgetauscht! Fazit im Moment: das Setup prüft, ob bereits eine Installation mit gleicher Versionsnummer vorliegt und verweigert dann seinen Dienst mit dem Hinweis, die vorhandene Version zu deinstallieren. Das ärgert für DVB.NET erst mal nur die Beta-Tester, bei VCR.NET leider auch den normalen Endanwender.

Meiner Ansicht nach noch einen Zahn schärfer ist das Ausführen so genannter Custom Actions. Beim VCR.NET etwa sorgt eine solche Custom Action dafür, dass die Konfiguration der Vorgängerversion aus der .EXE.CONFIG.CPY in die .EXE.CONFIG eingepflegt wird, die von der Installation als Template mitgeliefert wird. Bei einer ‚All Users‘ Installation laufen Custom Actions nun (wieder nicht durch eine direkte Konfiguration im Visual Studio zu beeinflussen) unter dem Konto LocalSystem. Technisch gesehen ist das auch gut so, da eine ‚All Users‘ Installation auch Zugriff auf Ressourcen haben muss, die dem normalen Anwender verwehrt sind. Leider startet beim VCR.NET die Custom Action aber auch die Überwachung. Die erscheint dann auch brav sichtbar, kennt aber nicht die Konfiguration des aktuellen Anwenders und läuft ebenso als LocalSystem. Das ist hier nicht im Sinne des Erfinders. Bis zu einer guten Lösung habe ich das Feature erst mal deaktiviert, der Anwender muss nach der Installation nun die Überwachung manuell in seinem Kontext starten – oder sich ab- und wieder anmelden, da die Überwachung in der Autostart Gruppe landet.

Selbst wenn diese Änderungen durchaus sinnvoll sind (zumindest in fast allen Fällen) hätte ich mir bei einer derart inkompatiblen (breaking change) Änderung schon gewünscht, dass man das alte Verhalten leicht wieder herstellen kann (und nicht durch Manipulation der fertigen MSI mit irgendwelchen COM Schnittstellen). Naja, zuviel erwartet…

Frohes Codieren

Jochen

Zusatz: Hier ein kleiner Vortrag, den ich voraussichtlich am 22. April 2008 bei Bonn-to-Code halten werde.

Bookmark the permalink.

Schreibe einen Kommentar