Hallo,
bei der Programminstallation werden wichtige Programmdaten in den Systemordner (Environment.SpecialFolder.ProgramFiles) gespeichert. Wenn das Programm darauf zugreifen soll, muss man es ja mit Administratorrechten starten. In diesem ProgramFiles Ordner liegt nun eine Datei, die einen wichtigen Pfad beinhaltet, den die Hauptanwendung (die man ohne Administratorrechten starten soll) dringend braucht. Gibt es irgend eine andere Speichermethode, die auch so "Professionell" ist?

Zitat:

Wenn das Programm darauf zugreifen soll, muss man es ja mit Administratorrechten starten.

Nur wenn Du Schreibrechte brauchst, Leserechte hast Du dort.

Zum Speichern von programmspezifischen Daten ist aber der AppData-Ordner gedacht, nicht ProgrammFiles.
Wenn Du das Settings-Features nutzt, werden dir darüber abgewickelten Settings auch unter AppData gespeichert und automatisch gelesen/gespeichert.



Wenn ich mir deinen Thread-Titel so anschaue, würde ich aber eher vermuten, dass Du dir merken willst, wohin ein programm installiert wurde.
Wenn Du die Installation über den Microsoft Installer abwickelst, dann brauchst Du das aber gar nicht tun, das tut Windows nämlich schon von sich aus, Du musst es "nur" noch abfragen.
Einfach mal Google dazu befragen.

Naja aber dann müsste ich wieder ein anderes Programm nutzen. Ich möchte wirklich sagen können, dass alles (Setup, Updater, DLLs und andere Dateien) alle ich gemacht habe. Der Installer funktioniert schon. Der Knackpunkt ist nur, dass beim Installer das Verzeichnis gelöscht werden muss, in dem der Installer sich befindet. Nun würde ich eine Datei schreiben, wie einen Code hat. Anhand von diesem Code soll nun geguckt werden, ob das Programm zum ersten mal gestartet wird und dann eben das eine Verzeichnis löschen.

Also den AppData Order soll ich benutzen?

Zum Speichern von anwendungsbezogenen Daten (Application Data -> AppData) ist der Ordner gedacht.
Und zum Speichern von z.B. Einstellungen ist das Settings-Feature in .NET gedacht, einfach mal unter Projekteigenschaften links auf Einstellungen gehen.
Da bekommst Du dann eine Tabelle, wo Du einen Key (der später auch der Property-Name wird) eintragen kannst, ob es Benutzer- oder Anwendungbezogen ist, der Wert dazu und eine Beschreibung.



Und nutze bitte den Microsoft-Installer.
Was ich so gar nicht leiden kann, ist ein Programm, dass sich irgendwie selber "installiert", möglicherweise Probleme macht und am Ende nicht von Windows normal gefunden oder deinstalliert werden kann.
Gerade Letzteres wird über MSI nämlich auch geregelt.

Ich will jetzt nichts falsches behaupten, aber ich meine, dass ein solcher Microsoft Installer gleichzeitig auch deinstallieren kann, anhand der eigens mit geschriebenen Schritte, die während der Installation ausgeführt wurden.

Zweiter Vorteil:
Jeder kennt ihn, da er immer und überall genutzt wird.

Hm ja okay. Ich habe mir dieses Video angesehen und finde Setup and Deployment bei mir nicht

Da muss ich mich dann aber leider auch aus klinken.
Ich weiß nur, dass es nicht unbedingt eine gute Idee ist, den Installer selber zu machen.
Du hast dann auch gleich den Vorteil, dass der Installer mehr als nur ein paar mal getestet wurde

Ja naja das stimmt schon. Jetzt habe ich mich bereits erklärt, den Installiert zu nutzen und es gibt ihn in meinem VS 2015 nicht. Tolle erste Begegnung zwischen dem installier und mir ...

- Nachträglich durch die Entwickler-Ecke gelöscht -

Registry? Wie kann ich mir das Vorstellen? Wie ein Dateienverzeichnis, was für jeden Benutzer separat existiert und an das man ohne besondere Software nicht herankommt?

Oder ich würde eine XML Datei als Einstellung schreiben, die sich dann per Wunsch auf einer HDD installieren kann. Weil die Registry befindet sich ja dann auf einer (falls vorhanden) SSD.

Das Problem mit meinem Installiert ist dann, wie Palladin schon schrieb, dass Windows diese Anwendung dann nicht kennt...

Was Frühlingsrolle schreibt, stimmt schon: Du kannst Windows sagen, was Du da installierst, das musst Du dann aber selber machen.
Sprich: Ausführlich informieren, was der Standard-Installer so alles tut und das dann nach bauen, damit Windows danach damit arbeiten kann.

Und ich weiß nicht, wie ihr das seht, aber ich mag das nicht, wenn irgendein Programm auf eigene Faust in meiner Registry rum schreibt

Schließlich ist das sozusagen die Datenbank von Windows, wird darin was falsch gemacht, kann das im schlimmsten Fall dazu führen, dass Windows nicht mehr richtig startet.
Ich bezweifle, dass das so schnell passiert, wenn Du dich vorher gut informierst und es auch brav testest, aber die Gefahr besteht trotzdem.


Oder - und das finde ich persönlich am besten - du lässt den Installer weg und sorgst dafür, dass es nicht installiert werden muss.
Das funktioniert bei vielen Anwendungen sehr gut. Anwendungen wie Visual Studio dagegen greifen sehr tief in's System ein, die brauchen einen Installer. Notepad++ dagegen muss nicht installiert werden, dazu gibt's auch eine portable-Version, die kannst Du hin kopieren wo Du lustig bist und dann von dort aus nutzen.

- Nachträglich durch die Entwickler-Ecke gelöscht -

Okay. Vielen Dank, aber wir werden erstmal nur eine Einstellungsdatei erstellen. Da das Programm ja nicht über den Windows Installer installiert wird, erkennt Windows dieses Programm auch nicht als Standartprogramm. Gibt es irgendeine Möglichkeit, dass Windows unser Programm als Standartprogramm erkennt?

Standardprogramm für was? Und was hat diese Frage mit dem Titel des Threads zu tun?

Zitat:

Gibt es irgendeine Möglichkeit, dass Windows unser Programm als Standartprogramm erkennt?

Ja, indem Du alle nötigen Daten in der Registry manuell registrierst.
Was das für Daten sind und wo die hin kommen, weiß ich nicht, eine kurze Google-Suche hat aber das ergeben:
msdn.microsoft.com/e...872121(v=vs.85).aspx
stackoverflow.com/qu...-uninstall-a-program

Csharp-programmierer hat folgendes geschrieben :

Naja aber dann müsste ich wieder ein anderes Programm nutzen. Ich möchte wirklich sagen können, dass alles (Setup, Updater, DLLs und andere Dateien) alle ich gemacht habe.

Bei privaten Programmen ist das in Ordnung (auch wenn ich sie dann eher nicht nutze), bei professionellen Programmen ist das im Normalfall ein No-Go. Bei einigen Kunden wird etwas anderes als ein MSI-Setup auch gar nicht akzeptiert, weil nur das optimal in das Deployment in einer Domäne eingebunden werden kann.

Palladin007 hat folgendes geschrieben :

Und ich weiß nicht, wie ihr das seht, aber ich mag das nicht, wenn irgendein Programm auf eigene Faust in meiner Registry rum schreibt Schließlich ist das sozusagen die Datenbank von Windows, wird darin was falsch gemacht, kann das im schlimmsten Fall dazu führen, dass Windows nicht mehr richtig startet. Ich bezweifle, dass das so schnell passiert, wenn Du dich vorher gut informierst und es auch brav testest, aber die Gefahr besteht trotzdem.

Solange du dich nur in dem vorgesehenen Pfad unter Software\Firma\Anwendung herumtreibst passiert da auch nichts. Für einfache kleine Einstellungen ist die Registry nach wie vor der empfohlene Weg, zumindest für native Windows-Anwendungen.
Für Daten (und ggf. auch umfangreichere Konfigurationsdaten) gibt es das AppData-Verzeichnis wie schon genannt. Für ein paar einfache Einstellungen ist das aber weniger sinnvoll, insbesondere wenn die Einstellungen benutzerspezifisch innerhalb einer Domäne transportiert werden sollen.

Da bei .NET Anwendungen Settings.Default leider in eine Datei schreibt, weicht Microsoft da von seinem eigenen Standard ab. Da .NET-Anwendungen heute aber auch auf anderen Plattformen funktionieren, auf denen es die Registry nicht gibt, macht das durchaus Sinn.

Palladin007 hat folgendes geschrieben :

Oder - und das finde ich persönlich am besten - du lässt den Installer weg und sorgst dafür, dass es nicht installiert werden muss.

Das dürfte bei .NET Anwendungen schwerfallen, es sei denn du beschränkst dich auf Windowsversionen, die die notwendige .NET Version bereits mitliefern...

Naja, ich bin immer noch kein Freund von der Registry
Ich werde nie in der Registry schreiben, wenn ich nicht muss, schon allein, weilman dann bei Problemen entsprechende Anwendungs-Einstellungen kontrollieren und bearbeiten kann ohne Admin-Rechte zu brauchen.
Aber das muss dann wohl jeder für sich entscheiden. Unter .NET ist es ja denkbar einfach, die Settings zu nutzen

Zitat:

Das dürfte bei .NET Anwendungen schwerfallen, es sei denn du beschränkst dich auf Windowsversionen, die die notwendige .NET Version bereits mitliefern...

Stimmt, das hab ich übersehen
Allerdings kann man für den Fall dann ein Script bei legen, was prüft, ob die nötige .NET-Version installiert ist und gegenenfalls installiert, bevor es dann die Hauptanwendung startet. Ist nicht weiter schwierig, Windows bietet alle nötigen Optionen dafür.
Wem eine Script-Datei zu unschön ist, der kann das ja als Exe kompilieren. Sowohl für Batch als auch für PowerShell gibt's Tools, die das machen.
Stimmt zwar, dass dann auch etwas installiert wird, allerdings finde ich das bei .NET nicht weiter wild. Das ist sehr klein und ist auf den meisten halbwegs aktuellen Windows-Rechnern sowieso vorhanden.

Das Schöne bei dem Vorgehen ist einfach, dass ich als Anwender weiß, was da mit meinem System gemacht wird.
Aber ich gebe zu, für weniger affine Anwender ist das nicht so schön...