Vista und der Programme-Ordner

[mec]

Hallo,

mittlerweile haben wir ja alle gelernt, dass das Schreiben in den Programmordner seit XP nicht mehr erwünscht, aber seit Vista auch nicht mehr geduldet ist.

Für Konfigurationsdateien kann ja Abhilfe geschaffen werden, indem man die Application-Klasse und ihre Eigenschaften CommonAppDataPath bzw. UserAppDataPath verwendet.
Dies ist allerdings auch unbefriedigend, da zum einen jeweils die Produktversion Bestandteil des Pfades ist und man nicht mit jedem Release dem Anwender zumuten möchte, seine Konfigurationsdaten neu erfassen zu müssen. Zum anderen, weil ich den Namespace System.Windows.Forms vielleicht gar nicht in meiner Anwendung einbinden möchte, weil es evtl. eine Konsolenanwendung oder ein Windows-Dienst ist.

Ein weiteres Problem entsteht bei Anwendungen, die über einen selbstimplementierten automatischen Update-Mechanismus verfügen, welcher DLLs oder EXEn im Programmorder austauschen soll.

Kennt jemand hierzu Empfehlungen oder allgemeine Richtlinien?

Vielen Dank

[Bernhard Geyer]

mittlerweile haben wir ja alle gelernt, dass das Schreiben in den Programmordner seit XP nicht mehr erwünscht, aber seit Vista auch nicht mehr geduldet ist.

Geht doch auch unter Vista wenn der entsprechende Prozess lokale Admin-Rechte. Und das "nicht gewünschte" verhalten ist schon seit Windows NT (!) wenn der User nur Mitglieder der Benutzer und nicht der Hauptbenutzer ist.

Ein weiteres Problem entsteht bei Anwendungen, die über einen selbstimplementierten automatischen Update-Mechanismus verfügen, welcher DLLs oder EXEn im Programmorder austauschen soll.

Wenn du ClickOnce verwendest wird einfach nicht mehr das Programm nach C:\Programme installiert sondern ins AFAIK AppData-Verzeichnis des Profiles. Diverse andere Proramme verwenden auch nicht mehr C:\Programme.

Alternative ist das du eine enstprechende Update-Anwendung schreibst die per Manifest immer dem OS mitteilt das für den Betreib (Update) Adminrechte nötig sind.

[mec]

Wenn ich einem Prozess lokale Admin-Rechte erteile, kann dies ja auch nicht im Sinne des Erfinders sein. Einerseits ist es nicht erforderlich, da ja die Zugriffsrechte auch das eigene Verzeichnis vollkommen ausreichen würden und zum anderen dem Kunden gegenüber auch schlecht zu argumentieren.

ClickOnce ist für Dienstanwendungen ja ledier völlig ungeeignet. Und wenn sämtliche Anwendungen jetzt dazu übergehen, eigene Verzeichnisse ausserhalb des Programme-Ordners anzulegen, stellt sich doch die Frage, welchen Sinn er dann überhaupt noch macht.

Eigentlich hatte ich gehofft, Microsoft würde endlich einmal Richtlienien veröffentlichen, wie man sich das eigentlich so denkt, aber da ist leider bis dato nichts zu finden.

Eine ähnliche Situation hatten wir früher schon bei der Einführung der Registry, als es dann kurze Zeit später hieß, dass LOCAL_MACHINE nicht mehr verwendet werden soll.

Im Hinblick auf zukünftige Entwicklungen würde ich mich ja gerne an vorgegebenen Richtlienien halten, wenn diese doch endlich einmal deutlich formuliert und dargelegt würden.

Aber die derzeitige Situation ist mal wieder höchst unbefriedigend.

[Bernhard Geyer]

Wenn ich einem Prozess lokale Admin-Rechte erteile, kann dies ja auch nicht im Sinne des Erfinders sein.

Das kann du Programmiertechnisch unter Vista von einem Prozess ohne Adminrechte auch nicht. Nur über die "schönen" UAC-Meldungen geht das über ein ShellExecute.

Einerseits ist es nicht erforderlich, da ja die Zugriffsrechte auch das eigene Verzeichnis vollkommen ausreichen würden und zum anderen dem Kunden gegenüber auch schlecht zu argumentieren.

Das kann ja der Installer machen der ja eh mit Adminrechten laufen muss.

Und wenn sämtliche Anwendungen jetzt dazu übergehen, eigene Verzeichnisse ausserhalb des Programme-Ordners anzulegen, stellt sich doch die Frage, welchen Sinn er dann überhaupt noch macht.

Tja. Mit Vista denken eh einige Firmen ob es in Zukunft noch Windows sein muss ...

Eigentlich hatte ich gehofft, Microsoft würde endlich einmal Richtlienien veröffentlichen, wie man sich das eigentlich so denkt, aber da ist leider bis dato nichts zu finden.

Richtlinien gibt es schon lange und das Programm-Schreibproblem ist ja schon seit Windows NT bekannt, jedoch das 99% der User mit mindestens lokalen Adminrechten liefen (Hauptbenutzergruppe) haben sich wenige Programmier darum gekümmert. Selbst MS-Programme liefen ohne Adminrechte nicht (selbst Spiele nicht).

Eine ähnliche Situation hatten wir früher schon bei der Einführung der Registry, als es dann kurze Zeit später hieß, dass LOCAL_MACHINE nicht mehr verwendet werden soll.

HKLM und das Windows-Programmverzeichnis sind doch rechtetechnisch das gleiche - Ohne Lokale Adminrechte geht nix.

Im Hinblick auf zukünftige Entwicklungen würde ich mich ja gerne an vorgegebenen Richtlienien halten, wenn diese doch endlich einmal deutlich formuliert und dargelegt würden.

Gibts es mit sicherheit in den untiefen der MSDN. Jedoch ändern sich mit jeder Windows-Version einige. War früher das Moto von MS: Erst mal alles erlauben (siehe ActiveX) und dann Jahre die Sicherheitsprobleme damit fixen (Bei ActiveX seit fast 15 Jahren) ist es heutzutage bei MS eher die komplexität (NTFS-Rechte, Lan-Manager-Rechter und jetzt auch noch das nicht gerade einfache .NET-Rechtesystem.

[mec]

... also doch eigener Programmordner ...

Die MSDN durchforsche ich regelmäßig zutiefst. Dabei muss ich aber leider immer feststellen, dass sie alles andere als auf dem neuesten Stand ist.

Es ist zwar ein anderes Thema, aber ein gutes Beispiel dafür ist der folgende Link (wobei man aber anerkennen muss, dass sie sich wenigstens mal kümmern): http://connect.microsoft.com/VisualS...dbackID=345017

Na ja, wir werden sehen ...

[Bernhard Geyer]

... also doch eigener Programmordner ...

Ich würde die Update-Anwendung mit UAC-Elevation bevorzugen.

Die MSDN durchforsche ich regelmäßig zutiefst. Dabei muss ich aber leider immer feststellen, dass sie alles andere als auf dem neuesten Stand ist.

Musste ich leider auch feststellen. Da werden teilweise dinge beschrieben wo dann an anderer Stelle steht das diese Funktion noch nie verwendbar war da immer Fehlerhaft war. Behoben wird dieses Fehlerverhalten jedoch nicht.