Laden...

Wie bekomme ich einen Eintrag eines Projekts in "Systemsteuerung" -> "Programme und Funktionen"?

Erstellt von MoaByter vor 5 Jahren Letzter Beitrag vor 5 Jahren 2.535 Views
M
MoaByter Themenstarter:in
68 Beiträge seit 2016
vor 5 Jahren
Wie bekomme ich einen Eintrag eines Projekts in "Systemsteuerung" -> "Programme und Funktionen"?

Hallo!

Ich habe für eines meiner Projekte ein eigenes Installationsprogramm geschrieben, das soweit auch gut funktioniert. Nur klappt das mit dem Eintrag unter Programme und Funktionen nicht. Den Betrag

"Programme und Funktionen" registrieren

habe ich gelesen, funktioniert nicht. Auf Microsofts Seiten - wie z.B.

https://docs.microsoft.com/de-de/windows/desktop/Msi/uninstall-registry-key

habe ich mich informiert und die Hinweise genau befolgt, funktioniert nicht. Ich habe bei anderen Programmen in meiner Registry geschaut und es so nachgebaut, funktioniert nicht.
Eine intensive Internetsuche förderte auch nichts hilfreiches zutage.
Hat jemand 'ne Idee, was ich falsch mache?

Hier etwas Code dazu:


using Microsoft.Win32;
...
string key = @"SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ReForm";
RegistryKey newKey = Registry.LocalMachine.CreateSubKey(key);		
newKey.SetValue("DisplayIcon", exepfad + ",0");  
newKey.SetValue("DisplayName", "ReForm (x86) 0.70");  
newKey.SetValue("DisplayVersion", "0.7");
newKey.SetValue("EstimatedSize", "1200");
newKey.SetValue("InstallLocation", exepfad + "\\");
newKey.SetValue("Publisher", "MoaByter");
newKey.SetValue("UninstallString", uninstexe);
newKey.SetValue("VersionMajor", 0);
newKey.SetValue("VerisonMinor", 7);

exepfad und uninstexe sind die Pfade zur jeweiligen exe-Datei einschließlich Dateiname. Die EstimatedSize habe ich getestet, die Zahl ausgedacht anhand annderer Einträge.

Mit externen Installer-Programmen habe ich noch nicht gearbeitet, aber die können ja auch nicht mehr tun, als den richtigen Code erstellen, oder?

709 Beiträge seit 2008
vor 5 Jahren

Hallo MoaByter,

vielleicht schreibst du in die falsche Ansicht.
Registry mit C# auslesen

M
MoaByter Themenstarter:in
68 Beiträge seit 2016
vor 5 Jahren

Danke für Deine Antwort, pinki.

Ich wusste gar nicht, das es zwei Ansichten gibt. Leider ändert das nichts, funktioniert auch nicht:


string key = @"SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ReForm";
RegistryKey key64 = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64);
RegistryKey key32 = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry32);

RegistryKey newKey = key64.CreateSubKey(key);   // dieser
RegistryKey newKey = key32.CreateSubKey(key);   // oder der

usw. ...

In der Systemsteuerung/Programme und Funktionen ist beides nicht zu finden.
Hm... noch 'ne Idee?

4.931 Beiträge seit 2008
vor 5 Jahren

Hast du denn mal mit "RegEdit" nachgeschaut, ob die Daten korrekt reingeschrieben wurden?

Wenn ich von Hand dort einen neuen Registry-Eintrag vornehme, so wird mir der auch unter "Programme und Funktionen" angezeigt.

M
MoaByter Themenstarter:in
68 Beiträge seit 2016
vor 5 Jahren

Mit meine4m Programm habe ich jetzt mal die 32Bit-View und die 64Bit-View ausgelesen, dazu gibt's noch 'nen Screenshot der Registry (regedit). Die 32Bit-Variante ist wohl ein älterer Eintrag, also von gestern. er ist aber bis auf den "EstimatedSize"-Wert identisch - naja, das NoRepair usw. fehlt, was aber nichts ändern dürfte.

M
MoaByter Themenstarter:in
68 Beiträge seit 2016
vor 5 Jahren

Hm - zwei Bilder pro Antwort geht nich'? Dann eben so.
Hier also der Screenshot der Registry:

M
MoaByter Themenstarter:in
68 Beiträge seit 2016
vor 5 Jahren

Ha! Fehler gefunden. Wie unschwer zu erkennen, ist das Programm im Unterschlüssel eingetragen. Wenn ich das "lypo_eu" weglasse, funktioniert's - egal ob ich es 32bit- oder 64bit-Schlüssel eintrage.
Was würdest Du empfehlen? Das Programm ist unter x86 eingetragen, im Visual Studio habe ich allerdings die "32bit-bevorzugen" (Reiter Build) 'rausgenommen. Ich könnte die Selection im Code auch weglassen, mal sehen, wo VS dann den Schlüssel einträgt. 😃)

Danke für Deine Hilfe, gehab Dich wohl ...lypô

PS.: Dein Avatar - stammt der von "Blender3D"?

4.931 Beiträge seit 2008
vor 5 Jahren

Generell solltest du 32bit-Programme unter dem 32bit-Registryschlüssel eintragen und 64bit eben unter dem 64bit-Registryschlüssel.
Bei "AnyCPU" Builds würde ich es unter 32bit eintragen (da es ja auch auf reinen 32bit-Systemen dann noch laufen würde).

PS: Mein Avatar ist die "Diablo 2 Sorcerer" (mein Alter Ego und ich nenne sie "KaiLid", nach einer Zauberin von den Eisebenen aus einem der Dragonlance-Büchern).

M
MoaByter Themenstarter:in
68 Beiträge seit 2016
vor 5 Jahren

Generell solltest du 32bit-Programme unter dem 32bit-Registryschlüssel eintragen und 64bit eben unter dem 64bit-Registryschlüssel.
Bei "AnyCPU" Builds würde ich es unter 32bit eintragen (da es ja auch auf reinen 32bit-Systemen dann noch laufen würde).

Gutes Argument. Es wird zwar kaum noch 32bit-Systeme geben, aber vorsichtshalber...
Ob es ein 32bit-Programm ist, weiß ich nicht. Ich hörte/las mal, VS könne nur 32bit-Programme erstellen, woran ich leise Zweifel hege. Da ich es aber unter x86 speichere, wird die 32bit-Wahl kein Fehler sein.

PS: Mein Avatar ist die "Diablo 2 Sorcerer" (mein Alter Ego und ich nenne sie "KaiLid", nach einer Zauberin von den Eisebenen aus einem der Dragonlance-Büchern).

Hm - ich dachte, ich hätte diesen Avatar mal auf blendpolis gesehen. Eisebenen? Dragonlance-Bücher ...ähm...? 😃)

16.807 Beiträge seit 2008
vor 5 Jahren

Es wird zwar kaum noch 32bit-Systeme geben, aber vorsichtshalber...

Ein 32 Bit Prozess und ein 32 Bit System: das sind zwei paar Stiefel. ⚠

Ich hörte/las mal, VS könne nur 32bit-Programme erstellen, woran ich leise Zweifel hege.

Wo auch immer Du das gehört hast: Bullshit. 😉
Zudem erstellt Visual Studio selbst gar keine Programme, sondern spricht nur den Compiler an: und der erzeugt die Artifakte.
Du kannst auch mit nem Notepad-Editor und der MSBuild.exe auf der Kommandozeile .NET Anwendungen erstellen.
Visual Studio ist und war noch nie ein Muss.

M
MoaByter Themenstarter:in
68 Beiträge seit 2016
vor 5 Jahren

Danke für Deine Info, Abt.

32bit-Prozess/32bit-System: Is' schon klar, ich weiß halt nur nicht, wie ich das anweise, habe es allerdings auch noch nicht gebraucht.

Und dass VS die Programme nicht erstellt, ist auch klar. Da aber der Compiler - für den Anwender transparent im Hintergrund - von VS angestoßen wird, habe ich mal die kurze Definition verwendet.

Wenn man halbwegs stressfrei programmieren will, ist VS schon - mehr oder weniger - ein Muss. 🙂
Meine html-Seiten erstelle ich mit Notepad++, dazu geht's noch, nur für C# bietet es sehr wenig Unterstützung. Da lob ich mir VS, auch wenn es hin und wieder mal ganz merkwürdige Fehler an den Tag legt. Dazu hatte ich ja auch 'nen Beitrag erstellt.

4.931 Beiträge seit 2008
vor 5 Jahren

Bei den Projektoptionen unter "Build" -> "Platform Target" kann man diese einstellen: x86, x64 oder "Any CPU" (je nach Betriebssystem-Plattform).

16.807 Beiträge seit 2008
vor 5 Jahren

Wenn man halbwegs stressfrei programmieren will, ist VS schon - mehr oder weniger - ein Muss. 😃

Ansichtssache. VSCode ist bei vielen Dingen deutlich stressfreier als VS-IDE - weil schlanker und schneller.
Einfach mal über den Tellerrand schauen.. 😉

2.207 Beiträge seit 2011
vor 5 Jahren

Hallo MoaByter,

wenn man halbwegs stressfrei programmieren will, ist VS schon - mehr oder weniger - ein Muss.

das bezieht sich auch nur auf .NET. Rede mal mit einem Java-Entwickler. Und selbst bei .NET: Ich mache selbst Backends (ASP.NET Core) meistens (nicht immer) mit VSCode. Ich starte seit VSCode das VS2017 wesentlich seltener.

Gruss

Coffeebean

4.931 Beiträge seit 2008
vor 5 Jahren

Aber sicherlich nicht für WinForms- oder WPF-Projekte (wenn ich mir die anderen Beiträge von Moabyter so anschaue). VS Code ist ja für Crossplatform unter .NET Core oder Mono gedacht, s.a. Visual Studio Code: Working with C#.

16.807 Beiträge seit 2008
vor 5 Jahren

VS Code ist ja für Crossplatform unter .NET Core oder Mono gedacht

Nein.
Mit "Cross Platform" ist hier nicht das Target Deiner Anwendung gemeint, sondern, dass VSCode auf Windows, Linux, MacOS und im Browser läuft und Du damit eben .NET entwickelt kannst; implizit .NET Core.

VSCode ist eigentlich ein "Abfallprodukt" von Visual Studio Team Services aka Azure DevOps.
Es ist aus dem Projekt Monaco entstanden - einem Code Editor im Browser (für Code Reviews und Co).

Und WinForms kommt mit .NET Core 3.0 (und dem Desktop Pack) auch auf Linux und MacOS.

Aber sicherlich nicht für WinForms- oder WPF-Projekte

Doch - durchaus. Warum denn nicht?

Mittlerweile ist es mehr als ein Editor; und hat durchaus auch XAML Support.
Dafür ist auch die Pluginfähigkeit enorm mit entsprechenden Resultaten: VSCode WPF Plugin

Ich verwende VSCode wann immer ich kann - ich bin damit einfach "schneller".
Einige Dinge sind aber nicht so komfortabel (zB. Erkennung von nicht korrekten Namespaces) wie es VS bzw. ReSharper mich drauf hinweist, weil dies Roslyn derzeit nicht kann.
VSCode kann nur das Beitragen (in C# bzw. .NET), was der Roslyn Compiler kann - und dadurch hat man derzeit "etwas weniger" komfort.