@Jelly: Habe nun das ganze WE mit Überlegungen und Recherchen verbracht und denke eine geeignete Lösung gefunden zu haben die ich auch schon weitestgehend umgesetzt habe.
Das AppDater-Objekt hat nun ein neues Flag "TempDirLocation" dessen 3 mögliche Werte die folgenden sind:
- LoggedOnUserTemp: Das Temp-Verzeichnis des angemeldeten Benutzers wird zum Download der Dateien verwendet (Vorgehensweise wie bisher, diese Einstellung wird auch Standard sein)
- DriveC: Ein Verzeichnis der Form C:$_936DA01F-9ABD-4d9d-80C7-02AF85C822A8 wird verwendet. Dabei ist dann sichergestellt dass beim Ausführen eines Updates unter einem anderen Benutzer auch tatsächlich ins Temp-Verzeichnis geschrieben werden kann
- UserSpecified: Verwende ein benutzerdefiniertes Verzeichnis
Das Problem dass du beschrieben hast, dass der Benutzer unter dem das Update durchgeführt werden kann nicht ins Verzeichnis des Benutzers schreiben kann der das Update veranlasst hat konnte ich nachstellen und durch Variante "DriveC" lösen.
An dieser Stelle wäre auch denkbar sich direkt in der DLL noch vor dem Aufruf der updater.exe per Impersonation am Konto des Benutzers anzumelden der das Update durchführen soll und in dessen Temp-Ordner zu schreiben. Eventuell füge ich diese Funktion dann später noch hinzu.
Auch habe ich nun die Einstellmöglichkeiten unter "Rechte" geändert. Bisher war es ja nur möglich entweder Adminrechte zu fordern oder ein anderes Benutzerkonto zu verwenden. Allerdings ist das ja quatsch. Denn das eine schließt das andere ja nicht aus. Somit stehen nun 4 Szenarien zur Verfügung unter denen ein Update durchgeführt wird
- Angemeldeter Benutzer, keine Adminrechte
- Angemeldeter Benutzer, Adminrechte
- Anderes Benutzerkonto, keine Adminrechte
- Anderes Benutzerkonto, Adminrechte
Die ersten Tests liefen eben erfolgreich. Nun schreibe ich noch die Routine die die Tempordner auch wieder löscht und dann gibts den nächsten Build.
Ein Szenario bereitet noch Probleme bei benötigten Adminrechten: Sollte ein Update unter dem angemeldeten Benutzer durchgeführt werden und auf Fehler auflaufen und will man dann während dem Update "händisch" das Benutzerkonto wechseln, so können noch keine Adminrechte angefordert werden.
@Zony: Deine Datei habe ich erhalten - vielen Dank. Jedoch kam ich heute noch nicht dazu das Problem zu lösen. Tatsächich erkennt die Routine die beiden identischen Versionsnummern und wählt dann dennoch das Update aus - also hat sih da irgendwo ein Fehler eingeschlichen.
Update: Habe gestern noch ne Weile dran gesessen und das Löschen der Temp-Dateien korrigiert. Nach einem Update werden sämtliche temporäre die angelegt wurden wieder gelöscht. Ein weiteres neues Flag "DeleteTempFilesAfterUpdate" dass standardmäßig auf "true" steht ermöglicht zu Debugzwecken das Löschen zu deaktiveren.