Laden...

AutoUpdater.NET gibt Fehler, wenn Programm aus Autostart gestartet wird

Erstellt von LittleTester vor 2 Jahren Letzter Beitrag vor 2 Jahren 978 Views
L
LittleTester Themenstarter:in
158 Beiträge seit 2019
vor 2 Jahren
AutoUpdater.NET gibt Fehler, wenn Programm aus Autostart gestartet wird

Hallo ihr lieben,

Ich habe mir mit Inno-Setup einen Installer für mein Programm gebaut und lasse es in den Autostart eintragen. Programm startet auch und tut was es soll.
Inno-Setup


[Registry]
Root: HKLM; Subkey: "SOFTWARE\Microsoft\Windows\CurrentVersion\Run"; \
    ValueType: string; ValueName: "Systeminventory"; \
    ValueData: """{app}\Systeminventory.exe"" /login"

Probleme gibt, es wenn eine neue Version zur Verfügung steht. Das erledige ich mit AutoUpdater.NET.
Wenn das Programm nach dem Einloggen dann startet und mir automatisch anzeigt, dass es ein Update gibt und ich updaten will, dann gibt es folgenden Fehler. Das Update wird auch nicht durchgeführt.


System.UnauthorizedAccessException

Der Zugriff auf den Pfad "C:\Windows\SysWOW64\AutoUpdater.NET.dll" wurde verweigert.

OK

Starte ich das Programm ganz normal funktioniert das Update. Momentan arbeite ich mit Administratorrechten. An mangelnden Benutzerrechten kann es also nicht liegen, zumal das Programm ohnehin an einem Ort installiert ist, wo der Anwender Schreibzugriff hat und AutoUpdater.RunUpdateAsAdmin = false; gesetzt ist.

Ich habe keine Idee was ich machen kann oder warum das Problem auftritt. Debuggen geht ja auch nicht. Könnt ihr bitte helfen?

IDE: Visual Studio 2022
Sofern nicht anders genannt basieren meine Projekte auf C# und .net 6

16.807 Beiträge seit 2008
vor 2 Jahren

Weil auch niemals irgendeine DLL/EXE von Dir in den C:\Windows\SysWOW64 Ordner sollte.
Das ist das Subsystem von Windows. Einer der wichtigsten Ordner von Windows, mit sehr hohen Sicherheitsanforderungen.

Wenn Du nicht gerade System WoW Komponten baust hast Du nix, aber auch gar nix in dem Folder zu suchen.
Warum denkst Du, dass Du dort rein schreiben musst?

Und nur weil Du etwas als Admin startest heisst das nicht, dass Du unter Windows mit jedem Zugriff Adminrechte hast.
Schau Dir dazu die Basics an, wie Windows UAC funktioniert.

L
LittleTester Themenstarter:in
158 Beiträge seit 2019
vor 2 Jahren

Jetzt wo du es sagst... in dem Ordner schreibe ich nichts rein und es liegt dort auch gar keine AutoUpdater.NET.dll.
Wie kommt die Anwendung nur darauf das die dort liegen soll? Die AutoUpdater.NET.dll liegt dort, wo sie hingehört, nämlich im Verzeichnis der Anwendung zu der sie gehört (In dem Fall C:\Systeminventory\Systeminventory)

Edit: So setze ich AutoUpdater.NET ein:


            // Auf Update kontrollieren.
            // AutoUpdater.NET über NuGet installieren.
            try
            {
                AutoUpdater.Start(updatePath);
                AutoUpdater.ShowSkipButton = false;
                AutoUpdater.ShowRemindLaterButton = false;
                AutoUpdater.Mandatory = true;
                //AutoUpdater.UpdateMode = Mode.Forced;
                AutoUpdater.RunUpdateAsAdmin = false;
                var currentDirectory = new DirectoryInfo(Environment.CurrentDirectory);
                if (currentDirectory.Parent != null)
                {
                    AutoUpdater.InstallationPath = currentDirectory.FullName;
                }
            }
            catch (Exception)
            {
                MessageBox.Show("Problem im Abschnitt Update");
            }

IDE: Visual Studio 2022
Sofern nicht anders genannt basieren meine Projekte auf C# und .net 6

D
261 Beiträge seit 2015
vor 2 Jahren

Wenn deine Anwendung als Dienst läuft, dann müsste Environment.CurrentDirectory ein Windows Verzeichnis sein. Deswegen versucht er es dort hinzuschreiben.

Edit:
Das hier sollte dein Problem lösen: system.unauthorizedaccessexception · Issue #378 · ravibpatel/AutoUpdater.NET

L
LittleTester Themenstarter:in
158 Beiträge seit 2019
vor 2 Jahren

Danke dannoe. Klappt aber leider auch nicht. Mit


AutoUpdater.DownloadPath = Environment.CurrentDirectory;

(wie im Link vorgeschlagen) gibt es folgenden Fehler, aber auch nur wenn das Programm beim Login gestartet wird. Manuell gestartet läuft alles durch.


System.Net.WebException

Ausnahmefehler während einer WebClient-Anforderung.

OK

Ich habe mal mit O&O RegEditor (x64) geguckt, wo der Installer den Autostarteintrag macht. Sieht wie folgt aus. Könnt ihr da was mit anfangen?


Schlüssel: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run
Daten: "C:\Systeminventory\Systeminventory\Systeminventory.exe" /login

Habs auch ohne den Schalter "/login" probiert.

IDE: Visual Studio 2022
Sofern nicht anders genannt basieren meine Projekte auf C# und .net 6

A
764 Beiträge seit 2007
vor 2 Jahren

Hallo Little Tester

Kannst du bei Inno-Setup ein 'working directory' mit angeben?

Gruß
Alf

D
261 Beiträge seit 2015
vor 2 Jahren

Bitte gib mal anstatt Environment.CurrentDirectory testweise (!) ein festen Pfad an. Beim automatischen Start ist vermutlich das Arbeitsverzeichnis (CurrentDirectory) ein anderes.
Du kannst auch mal die automatisch gestartet Anwendung debuggen, indem du dich nachträglich an den Prozess hängst.

L
LittleTester Themenstarter:in
158 Beiträge seit 2019
vor 2 Jahren

Auch das feste Angeben eines Downloadpfad funktioniert nicht. Immerhin wurde jetzt aber was heruntergeladen und ich habe eine *.log-Datei, die ich hier mal einstelle:

Anwendung startet automatisch:

Donnerstag, 19. August 2021 09:59:41

ZipExtractor started with following command line arguments.
[0] C:\Systeminventory\ZipExtractor.exe
[1] C:\Systeminventory\update.zip
[2] C:\Windows\SysWOW64
[3] C:\Systeminventory\Systeminventory\Systeminventory.exe

Waiting for application process to exit...
BackgroundWorker started successfully.
Found total of 20 files and folders inside the zip file.

System.UnauthorizedAccessException: Der Zugriff auf den Pfad "C:\Windows\SysWOW64\AutoUpdater.NET.dll" wurde verweigert.
bei ZipExtractor.FormMain.<>c__DisplayClass4_1.<FormMain_Shown>b__2(Object _, RunWorkerCompletedEventArgs eventArgs)

Wenn ich die Anwendung manuell starte:

Donnerstag, 19. August 2021 10:00:59

ZipExtractor started with following command line arguments.
[0] C:\Systeminventory\ZipExtractor.exe
[1] C:\Systeminventory\update.zip
[2] C:\Systeminventory\Systeminventory
[3] C:\Systeminventory\Systeminventory\Systeminventory.exe

BackgroundWorker started successfully.
Found total of 20 files and folders inside the zip file.
Extracting AutoUpdater.NET.dll [5%]
Extracting AutoUpdater.NET.pdb [10%]
Extracting AutoUpdater.NET.xml [15%]
Extracting Flurl.dll [20%]
Extracting Flurl.Http.dll [25%]
Extracting Flurl.Http.pdb [30%]
Extracting Flurl.pdb [35%]
Extracting Flurl.xml [40%]
Extracting Interop.WUApiLib.dll [45%]
Extracting Microsoft.WindowsAPICodePack.dll [50%]
Extracting Microsoft.WindowsAPICodePack.Shell.dll [55%]
Extracting Microsoft.WindowsAPICodePack.Shell.xml [60%]
Extracting Microsoft.WindowsAPICodePack.xml [65%]
Extracting Newtonsoft.Json.dll [70%]
Extracting Newtonsoft.Json.xml [75%]
Extracting System.ValueTuple.dll [80%]
Extracting System.ValueTuple.xml [85%]
Extracting Systeminventory.exe [90%]
Extracting Systeminventory.exe.config [95%]
Extracting Systeminventory.pdb [100%]
Successfully launched the updated application.

Ich frage mich mittlerweile, ob ich nicht auf einen Bug gestoßen bin und ich es auf der Projektseite bei GitHub melden sollte? Was meint ihr? Interessant wäre halt zunähst raus zu bekommen, was beim Start der Anwendung über den Autostart anders läuft, als beim manuellen Start.

@dannoe: Wie kann ich das mit dem Debuggen und Anhängen eines Prozesses machen Die Anwendung läuft doch unabhängig von VS.

Edit: Der Vollständigkeit wegen hier noch das Installscript. Ich habe den Registry-Eintrag der Dokumentation entsprechend mal abgeändert.


; Script generated by the Inno Setup Script Wizard.
; SEE THE DOCUMENTATION FOR DETAILS ON CREATING INNO SETUP SCRIPT FILES!

#define MyAppName "Systeminventory"
#define MyAppVersion "1"
#define MyAppPublisher "*****"
#define MyAppURL "https://www.*****"
#define MyAppExeName "Systeminventory.exe"

[Setup]
; NOTE: The value of AppId uniquely identifies this application. Do not use the same AppId value in installers for other applications.
; (To generate a new GUID, click Tools | Generate GUID inside the IDE.)
AppId={{*****}
AppName={#MyAppName}
AppVersion={#MyAppVersion}
;AppVerName={#MyAppName} {#MyAppVersion}
AppPublisher={#MyAppPublisher}
AppPublisherURL={#MyAppURL}
AppSupportURL={#MyAppURL}
AppUpdatesURL={#MyAppURL}
DefaultDirName=C:\Systeminventory\{#MyAppName}
DisableDirPage=yes
DisableProgramGroupPage=yes
; Uncomment the following line to run in non administrative install mode (install for current user only.)
;PrivilegesRequired=lowest
OutputBaseFilename=Systeminventory-Setup
SetupIconFile=C:\Users\*****\source\repos\setup.ico
Compression=lzma
SolidCompression=yes
WizardStyle=modern

[Languages]
Name: "german"; MessagesFile: "compiler:Languages\German.isl"

[Files]
Source: "C:\Users\*****\source\repos\Systeminventory\Systeminventory\bin\Release\{#MyAppExeName}"; DestDir: "{app}"; Flags: ignoreversion
Source: "C:\Users\*****\source\repos\Systeminventory\Systeminventory\bin\Release\*"; DestDir: "{app}"; Flags: ignoreversion recursesubdirs createallsubdirs
; NOTE: Don't use "Flags: ignoreversion" on any shared system files

[Registry]
 Root: HKA; Subkey: "SOFTWARE\Microsoft\Windows\CurrentVersion\Run"; ValueType: string; ValueName: "Systeminventory"; ValueData: """{app}\Systeminventory.exe"""; Flags: uninsdeletevalue 

IDE: Visual Studio 2022
Sofern nicht anders genannt basieren meine Projekte auf C# und .net 6

16.807 Beiträge seit 2008
vor 2 Jahren

Und warum machst konfigurierst Du nicht einfach Deinen Update so, wie es die Dokumentation auf GitHub - ravibpatel/AutoUpdater.NET: AutoUpdater.NET is a class library that allows .NET developers to easily add auto update functionality to their classic desktop application projects. beschreibt?
Steht sehr genau, was man konfigurieren muss, dass zB der Download in das richtige Verzeichnis erfolgt. Seh ich bei Dir nirgends. Dann darf man sich halt auch nicht wundern.

309 Beiträge seit 2020
vor 2 Jahren

Kannst du mal einen Userpath (%appdata%/...) statt den C:/SystemInventory ausprobieren?
Kann dort sicher ein normaler User schreiben?! Bei einem Autostart per Registry hast du keine elevated rights, auch nicht als Adminuser, dafür gibts Tasks.

L
LittleTester Themenstarter:in
158 Beiträge seit 2019
vor 2 Jahren

@Abt: Wie meinst du das? Was habe ich überlesen?

IDE: Visual Studio 2022
Sofern nicht anders genannt basieren meine Projekte auf C# und .net 6

A
764 Beiträge seit 2007
vor 2 Jahren

@Abt: Wie meinst du das? Was habe ich überlesen?

Meine Nachfrage hast du auch überlesen:

https://stackoverflow.com/questions/39107878/creating-shortcut-in-startup-folder-using-inno-setup

Bzw auch dort muss ein working folder angegeben werde:


[Registry]
 Root: HKA; Subkey: "SOFTWARE\Microsoft\Windows\CurrentVersion\Run"; ValueType: string; ValueName: "Systeminventory"; ValueData: """{app}\Systeminventory.exe"""; Flags: uninsdeletevalue

L
LittleTester Themenstarter:in
158 Beiträge seit 2019
vor 2 Jahren

Danke, dass du den Link noch dazu gepostet hattest. Ich bezog das WorkingDir auf VS und nicht auf Inno Setup und hatte schon wieder Angst ich kenne wiedermal eine Grundlage nicht und bekomme dafür Kritik.

Also das mit der Verknüpfung funktioniert sowohl mit {userstartup} als auch {commonstartup}.
Ich habe aber gelesen, dass diese Methode veraltet ist und man heutzutage die Registry nutzen sollte. Was meint ihr dazu? Workaround oder Lösung?

[Icons]
Name: "{commonstartup}{#MyAppName}"; Filename: "{app}\Systeminventory.exe"; WorkingDir: "{app}"

IDE: Visual Studio 2022
Sofern nicht anders genannt basieren meine Projekte auf C# und .net 6

16.807 Beiträge seit 2008
vor 2 Jahren

Was habe ich überlesen? Specify where to download the update file

Und da der direkte Code drunter aussieht wie Dein Copy Paste Code haste das Ding maximal überflogen, statt durchzulesen.
Liegt für mich nahe, dass Du das Sample (AutoUpdater.NET/FormMain.cs at master · ravibpatel/AutoUpdater.NET) blind kopiert hast, den unteren Teil aber einfach vergessen hast.
Spätestens bei meinem letzten Beitrag, mit dem Hinweis, dass Du was eben vergessen hast, hättest den Hinweis mit dem DownloadFolder ja finden sollen...

Was ich damit sagen will (wie in den anderen Themen auch schon): lern Dokumentationen zu lesen, dann kommst Du auch schneller und eigenständig ans Ziel.
Das ist Dein Job als Entwickler 😉

L
LittleTester Themenstarter:in
158 Beiträge seit 2019
vor 2 Jahren

Stop Abt. Mit dieser Datei habe ich rein gar nichts zu tun.
Ich habe AutoUpdater.NET über nuget installiert und habe es exakt so verwendet, wie oben geschrieben. Klar halt noch das


using AutoUpdaterDotNET;

und dann halt die Pfadangabe


const string updatePath = "https://example.com/update/systeminventory/AutoUpdaterTest.xml";


            // Auf Update kontrollieren.
            // AutoUpdater.NET über NuGet installieren.
            try
            {
                AutoUpdater.Start(updatePath);
                AutoUpdater.ShowSkipButton = false;
                AutoUpdater.ShowRemindLaterButton = false;
                AutoUpdater.Mandatory = true;
                //AutoUpdater.UpdateMode = Mode.Forced;
                AutoUpdater.RunUpdateAsAdmin = false;
                 var currentDirectory = new DirectoryInfo(Environment.CurrentDirectory);
                if (currentDirectory.Parent != null)
                {
                    AutoUpdater.InstallationPath = currentDirectory.FullName;
                }
            }
            catch (Exception)
            {
                MessageBox.Show("Problem im Abschnitt Update");
            }

Was habe ich da jetzt falsch gemacht? Die Doku habe ich gelesen, ist ja auch sehr einfach gehalten.

Edit: Ich verwende auch die neuste Version von AutoUpdater.NET (Stand heute 1.7.0)

IDE: Visual Studio 2022
Sofern nicht anders genannt basieren meine Projekte auf C# und .net 6

16.807 Beiträge seit 2008
vor 2 Jahren

"Die Datei", wie Du es nennst, ist zeigt in Form eines Tests die Anwendung von AutoUpdaterDotNET.
Soviel dazu.

Auf NuGet gibt es weder ein Paket, das "AutoUpdaterDotNET" heisst noch ein Paket, das "AutoUpdater.NET" heisst; zumindest keine, das gelistet ist.
Dein Code, Deine Versionsangabe von "1.7.0" und meine Glaskugel zeigen, dass Du https://github.com/ravibpatel/AutoUpdater.NET verwendest, das als NuGet Autoupdater.NET.Official heisst.
Steht alles so auf der GitHub Seite, das die Dokumentation darstellt.

Wenn Du also nicht willst, dass die Leute raten müssen, dann sag einfach exakt, welches NuGet Paket Du verwendest.
Aber zumindest die GitHub Seite, die diese "Datei" beinhaltet, hast Du im ersten Beitrag verlinkt, daher wird das schon die richtige NuGet sein - und daher gilt exakt das, was meine letzten Beitrage inhaltlich ausgesagt haben 😉
Wenn Du "diese Datei" noch nie gesehen hast, dann hast Du Dir das Repo, von dem Du das NuGet Paket gezogen hast, einfach nicht richtig angeschaut; denn sowohl die Dokumentation auf der ersten Seite (Readme) wie auch das Beispiel im Test zeigen die Verwendung des DownloadFolders, das Dir fehlt und worauf Du hingewiesen wurdest.

Daher: beachte bitte die Tipps der Helfer.

D
261 Beiträge seit 2015
vor 2 Jahren

Und lass dir bitte mal im Falle des automatischen Starts den Environment.CurrentDirectory ausgeben.

4.931 Beiträge seit 2008
vor 2 Jahren

@Abt: An DownloadPath kann es nicht liegen, denn ohne Angabe wird intern GetTempFileName benutzt, s.a. DownloadUpdateDialog.cs (DownloadUpdateDialogLoad).

Aber Environment.CurrentDirectory halte ich auch für eine schlechte Empfehlung um das Applikationsverzeichnis zu ermitteln (denn dieses kann sich ja auch zur Laufzeit ändern, z.B. mittels OpenFileDialog) - besser wäre wohl (für WinForms) Application.StartupPath.

Ist denn überhaupt bei dir das Installationsverzeichnis ein anderes als das Applikationsverzeichnis (also das, wo die Systeminventory.exe liegt)?
Der Code bzgl. InstallationPathi ist ja nur ein Beispiel-Code (wenn das Installationsverzeichnis eine Ebene höher als das Applikationsverzeichnis liegt).

16.807 Beiträge seit 2008
vor 2 Jahren

@Abt: An DownloadPath kann es nicht liegen, denn ohne Angabe wird intern GetTempFileName benutzt

Jo eben. Wenn aber in den Sys Ordner gedownloaded wird, dann stimmt da was nicht 😉 Ich sehe auf Anhieb kein Standard-Verhalten, dass hier den Sys Ordner wählt; ausser das mag ein Seiteneffekt von CurrentDirectory sein..
Zur Not kann man ja bei so einem Projekt einfach den Source ziehen und debuggen, um zu sehen, wo es hängt 🙂

Und wenn ich da jetzt nich sehe, dass mit C:\Systeminventory gearbeitet wird, was auch so ziemlich jeden Windows Ordner / Applikations Ordner Empfehlungen wiederspricht frag ich mich, wieso man sich nicht einfach an die Windows Empfehlungen hält. Denn auch direkt auf C:\ oder Custom C:&lt;SubFolder> hat man normalerweise keine direkten Schreibrechte.
Environment.SpecialFolder Enumeration (System)
Die gibts ja nicht umsonst 🙂

Ich denke, dass das alles also nur ein Nebeneffekt sein könnte, weil man sich nich an die Ordnerempfehlungen hält.

4.931 Beiträge seit 2008
vor 2 Jahren

Es ist nicht der Download des ZIP-Files, sondern das Extrahieren in diesen Pfad falsch (also das Installationsverzeichnis).

16.807 Beiträge seit 2008
vor 2 Jahren

Okay, wenn dem so ist, dann mea cupla.
Ich hab insbesondere die erste Exception anders wahrgenommen...

4.931 Beiträge seit 2008
vor 2 Jahren

Das sieht man an den Log-Ausgaben bei dem Beitrag von LittleTester AutoUpdater.NET gibt Fehler, wenn Programm aus Autostart gestartet wird (also das Extrahieren der ersten Datei "AutoUpdater.NET.dll").

L
LittleTester Themenstarter:in
158 Beiträge seit 2019
vor 2 Jahren

So, erstmal ein rießen fettes Danke an Th69.

  • dafür, dass er vorbehaltlos meiner programmiertechnischen Defizite analytisch an die Sache rangegangen ist.
  • dafür, dass er rausgefunden hat, dass nicht versucht wird die AutoUpdater.NET.dll aufzurufen, sondern diese in das geschützte Verzeichnis zu schreiben.
  • **dafür, dass er die Lösung gefunden hat. **

var currentDirectory = new DirectoryInfo(Application.StartupPath);

funktioniert.

Ich möchte aber zu meiner Verteidigung sagen, dass ich der Dokumentation gefolgt bin, weil so wie ich es geschrieben hatte steht es auch da.

Trotz alle dem bin ich jetzt irritiert, ob ich die Libray richtig einsetze? Ich bin der Beschreibung auf Startseite des Projekts gefolgt. Abt verweist hingegen auf dieses Script. Ich habe dieses Script übrigens als Teil von AutoUpdater.NET gesehen und nicht als Beispielcode zur Anwendung.

Übrigens: Bei nuget ist es tatsächlich als Autoupdater.NET.Official gelistet. Bei GitHub hingegen als AutoUpdater.NET und beim using wird AutoUpdaterDotNET; angegeben. Daher habe ich es halt so hier geschrieben.

Zudem wäre es schon interessant, was beim Autostart über die Registry anders läuft (und Environment.CurrentDirectory dann quer schießt), als beim manuellen Aufruf, bzw. beim Aufruf über die Verknüpfung im Autostart-Ordner.

IDE: Visual Studio 2022
Sofern nicht anders genannt basieren meine Projekte auf C# und .net 6

4.931 Beiträge seit 2008
vor 2 Jahren

Bitte sehr! Ich bezeichne mich auch selbst als Analyst. 😉

Du hast aber bzgl Abt einen falschen Link angegeben: AutoUpdaterTest/FormMain.cs (dein geposteter ist mein Link bzgl. GetTempFileName).
Das ist also Testcode, um zu zeigen, was man alles einstellen kann (daher auskommentiert, aber mit entsprechendem Kommentar).

Und wie ich schon schrieb, ist das nur Beispielcode auf der AutoUpdater-Seite (es geht nur darum zu zeigen, daß man InstallationPath setzen kann - mit welchem Wert liegt ja am Anwender der Lib selbst, also du).

L
LittleTester Themenstarter:in
158 Beiträge seit 2019
vor 2 Jahren

Ich habe das ganze mal auf der Projektseite eingetragen. Sollen ja am ende alle was von haben.

IDE: Visual Studio 2022
Sofern nicht anders genannt basieren meine Projekte auf C# und .net 6

16.807 Beiträge seit 2008
vor 2 Jahren

Und damit alle was haben, wurde wohl Environment.CurrentDirectory als Beispiel gewählt, denn Application.StartupPath gilt nur für Windows Forms.
Da die Lib aber natürlich neutral ist, sollte da auch niemals Application.StartupPath rein. Der Issue ist damit nicht zielorientiert.
Davon abgesehen ist die Lib offenbar durchaus gut genutzt und verbreitet; und wenn so ein Error nicht grundlegend auftaucht und gemeldet wird, dann ist die Wahrscheinlichkeit gering, dass es ein allgemeiner Fehler ist, sondern eher an der individuellen Implementierung liegt.

Mit Application.StartupPath machst Du _wohl _nichts anderes als das dokumentierte, Runtime-neutrale Standardverhalten, wenn Du die Eigenschaft nicht setzen würdest.

This is only necessary when your installation directory differs from your executable path.

Du Du Dich aber ja den Executable Path verwenden willst, musst Du laut Doku, gar nichts setzen.
Implementierung Standard InstallationPath

Siehe dazu auch [FAQ] Pfad zur eigenen Anwendung (EXE) ermitteln