Setup Projekt mit VS2019: erforderliche Komponenten ...

hustbaer

@elmut19 sagte in Setup Projekt mit VS2019: erforderliche Komponenten ...:

Aber mir kommt es drauf an, dass das VisualStudio für mich die nötigen "System-DLLs"
herausfindet und sie, wie früher im VisualStudio 2005, separat in ein "Windows"-Verzeichnis im Setup
kopiert, von dem sie zentral ins Windows integriert werden, so dass sie dort über "Windows Update"
weiter verwaltet werden.

Das sind keine System-DLLs. Und ob die VCRuntime Merge-Modules von Windows-Update mit upgedated werden, das weiss ich nicht.

Auch werden bei neueren VS Versionen (ab 2005) die Runtime-DLLs nicht mehr ins Windows bzw. System32 Verzeichnis kopiert. Die landen im Windows component store (SxS).

Grundssätzlich entspricht dies dem Vorgang, wenn ich das entsprechende Redistrib "vcredist_x86.."
oder so von Hand installiere (evtl mit weniger DLLs, weil nicht benötigt).

VCRedist macht soweit ich weiss auch nix anderes als die entsprechenden Merge-Modules zu installieren.

elmut19

@hustbaer
Vielen Dank Hustbaer.
Wenn man das "Setup"-Projekt einrichtet, hat man ja (wie auch beim VS2005) drei Möglichkeiten.
Bei der obersten (benötigte DLLs von der Website des Herstellers) oder so ähnlich, hat bei VS2005
das VS die DLLs gesammelt und bei der Installation auf den Zielrechner verteilt. In der Microsoft Doku
steht ja, dass man eine Variante wählen soll, die dem Windows Update erlaubt, anschliessend diese
DLLs zu verwalten.

Und das ist ja bei der zweiten Variante (... Komponenten aus Speicherort der Anwendung ..)
nicht der Fall. Und ich muss mir die Dinger selber aus meinem Rechner raussuchen!

Und die dritte Variante (... von folgendem Speicherort runterladen ...) habe ich nicht verstanden.
Und ausserdem darf es per Konvention keinen externen Speicherort geben.
Die Anwendung muss auf einem Rechner installierbar sein, der keine Verbindung zum Internet hat.

Unter VS 2005 hat das alles funktioniert.
Und bei den "Prerequisits" habe ich dort den obersten Radio-Button (von vendors Website herunterladen ...)
angeklickt. Es werden alle Microsoft DLLS gefunden, die nötig sind und ins "Setup" reingepackt.
Sowas brauche ich eben wieder. Und ich habe ebenfalls keine der Checkboxen bei den "Choose prerequisites ..."
angeklickt. Wo sie letztlich im System des Zielrechners landen ist mir eigentlich egal. Es ist jedenfalls nicht
das erstellte Anwendungsverzeichnis. Und das ist mir eigentlich wichtig.

elmut19

@hustbaer
Ich habe dann ein einfaches "Hello World" als MFC Anwendung erstellt.
Da drin habe ich dann das Setup Projekt dazu erstellt.
Alles mit den minimalsten Clicks. Keine Einstellungen dabei ergänzt oder verändert
Nur die "Primäre Ausgabe" ins Applikations-Verzeichnis integriert.
Die "Dependencies" wurden dabei aufgelistet!

Dann habe ich das "Setup" erstellt.
Als Resultat bekam ich auch die "Setup.exe" mit der ".msi" und der zu installierenden Anwendung.
Nur die Windows-DLLs fehlten.
Ausserdem verschwanden nach dem Erstellen alle "Dependencies" wieder aus ihrer Liste.
Danach bekommt man sie auch nicht wieder rein.
Wenn ich allerdings das "Setup"-Projekt komplett lösche und es neu erstelle,
bekomme ich wieder die Auflistung der "Dependencies", und alles beginnt von vorne.
Ich habe es, neben meinem Computer in der FIrma auch auf meinem eigenen ausprobiert.
Ist alles dasselbe.
Ich kanns mir leider nicht erklären.

Liegt es an der Community-Edition? Und ich brauche eine "Professional-Edition"?

hustbaer

Das scheint mit VS 2019 einfach nicht mehr automatisch zu gehen. Muss man nicht gut finden, ist aber wohl so.
Kannst du fixen indem du z.B. die Merge Modules zum Setup Projekt hinzufügst.

Visual Studio Paket für die Merge Modules installieren.
Dazu den VS Installer starten und unter "Individual components" die Komponenten "C++ 2019 Redistributable MSMs" und "C++ 2019 Redistributable Update" installieren.
Merge Modules deinem Setup Projekt hinzufügen
Rechtsklick auf das Setup Projekt, Add Merge Modules...
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Redist\MSVC\v142\MergeModules
und von dort dann

Microsoft_VC142_CRT_x64.msm
Microsoft_VC142_MFC_x64.msm
Microsoft_VC142_MFCLOC_x64.msm

Ob das letzte Paket wirklich nötig ist weiss ich nicht, hab's nur mal schnell mit diesen 3 probiert.

Was nicht schön ist, ist dass dabei der Pfad C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Redist\MSVC\v142\MergeModules fix in das Setup Projekt-File geschrieben wird. Das Projekt ist dadurch abhängig davon dass die Files auch genau dort liegen. Auch nicht schön. Keine Ahnung wie man das am besten behebt.

Alternativ dazu kannst du die VCRedist EXEn verwenden. Der Nachteil dabei ist dann aber dass VCRedist nach dem Installieren deiner Anwendung als eigene installierte Anwendung gelistet wird. Der Benutzer kann VCRedist dann auch einzeln de-installieren - wonach dann deine Anwendung nicht mehr starten würde.

Wie man die VCRedist Pakete in ein Setup Projekt integriert hab' ich mir nicht angesehen.

Schlangenmensch

@elmut19 sagte in Setup Projekt mit VS2019: erforderliche Komponenten ...:

Aber vielleicht funktioniert Dein Setup-Tool?
Welches wäre das?

Ich nutze Inno Setup. Aber ich füge alle DLLs im Prinzip manuell hinzu (via Skript) und habe alle benötigten DLLs dann im Ordner der Anwendung. Also, keine Installation in irgendwelche Windows Ordner, und kein automatisches herausfinden der benötigten DLLs.

Ja man muss dieses fucking tool extra installieren, wir sind jedoch alle sehr froh das es dies wieder gibt, es wurde nämlich zwischenzeitlich an einen GeldHai verborgt, seit 2019 ist es wieder dabei, und man tut gut dran jedwedes Setup damit zu gestalten.

Man kann es nachinstallieren im VS Menu/Extensions/Manage-Extensions - Dort in Suche Setup eingeben.

Es erscheint eine wirre liste mit lauter setup tools, das einzig richtige hier ist der Name ;*
Microsoft Visual Studio Installer Projcts xxx

Fraglich warum man hier keine Bilder hochladen kann, scheinbar platte voll wa ^^ loool..

Swordfish

@KahnSoft sagte in Setup Projekt mit VS2019: erforderliche Komponenten ...:

Fraglich warum man hier keine Bilder hochladen kann

Niemand braucht hier Bilder. Außer Du und ähnlich bemitleidenswerte Zeitgenossen.

elmut19

@hustbaer
Vielen Dank Hustbaer!
Das bringt wenigstens Klarheit in die Situation.
Dann werd ich das eben ausprobieren

elmut19

@Schlangenmensch
Auch Dir vielen Dank Schlangenmensch.
Und ja, das wäre nicht die Methode meiner Wahl.
Ich probier erstmal das von Hustbaer.

elmut19

@hustbaer
Ich habe die Installation auf einem mit VS2019 unverseuchtem Win7 probiert.
Die Installation lies sich durchführen, und das Programm startet auch.
Ebenfalls sind die Verschlüsselungs-Libs dabei, mit denen ich ein Passwort
verschlüsselt in einer INI ablege. Mit dem vorherigen Setup startete es nicht.

Allerdings meldete sich das Setup mit einer Warnung, es müsste System-Dateien updaten
und ob man fortfahren oder abbrechen oder ?? will.
Hm... Das verwirrt jedenfalls so manchen Installateur. Nicht so gut!
Ich habe auf "trotzdem installieren" geklickt, und es ging.

hustbaer

@elmut19 Ich würde empfehlen für Tests von Installern VMs zu verwenden. Damit ist es super einfach auf "unverseuchten" Systemen zu testen. Ich persönlich verwende Hyper-V als Hypervisor, was ab der "Professional" Version von Windows mit dabei sein sollte. VirtualBox ist aber auch OK und gratis -> gute Alternative wenn man nur eine "Home" Version von Windows hat.

Allerdings meldete sich das Setup mit einer Warnung, es müsste System-Dateien updaten
und ob man fortfahren oder abbrechen oder ?? will.

OK, keine Ahnung worum es da geht. Ich hatte Installation nur auf einem Windows 10 System ohne VS 2019 DLLs probiert. Dort ist keine solche Meldung gekommen.

Hm... Das verwirrt jedenfalls so manchen Installateur. Nicht so gut!

Ja, da wirst du Recht haben. Google selbst mal ob es ne Lösung dafür gibt, und wenn du nichts findest, dann poste die Meldung hier.

hustbaer

@Schlangenmensch sagte in Setup Projekt mit VS2019: erforderliche Komponenten ...:

Also, keine Installation in irgendwelche Windows Ordner, und kein automatisches herausfinden der benötigten DLLs.

Die DLLs einfach neben die Anwendung hinlegen funktioniet mit den Visual Studio runtime DLLs ab spätestens VS 2005 nur mehr wenn man die runtime DLLs selbst gebaut hat. Die mitgelieferten runtime DLLs müssen im SxS installiert werden damit sie gefunden werden.

Also entweder merge modules oder VCRedist oder runtime DLLs selbst bauen.

Schlangenmensch

@hustbaer sagte in Setup Projekt mit VS2019: erforderliche Komponenten ...:

Also entweder merge modules oder VCRedist oder runtime DLLs selbst bauen.

Redistributables sind doch auch "nur" DLLs, und die neben die Anwendung legen funktioniert noch. Auch wenn das nicht der von Microsoft empfohlene Weg ist.

elmut19

@hustbaer sagte in Setup Projekt mit VS2019: erforderliche Komponenten ...:

@elmut19 Ich würde empfehlen für Tests von Installern VMs zu verwenden. Damit ist es super einfach auf "unverseuchten" Systemen zu testen. Ich persönlich verwende Hyper-V als Hypervisor, was ab der "Professional" Version von Windows mit dabei sein sollte. VirtualBox ist aber auch OK und gratis -> gute Alternative wenn man nur eine "Home" Version von Windows hat.

Allerdings meldete sich das Setup mit einer Warnung, es müsste System-Dateien updaten
und ob man fortfahren oder abbrechen oder ?? will.

OK, keine Ahnung worum es da geht. Ich hatte Installation nur auf einem Windows 10 System ohne VS 2019 DLLs probiert. Dort ist keine solche Meldung gekommen.

Hm... Das verwirrt jedenfalls so manchen Installateur. Nicht so gut!

Ja, da wirst du Recht haben. Google selbst mal ob es ne Lösung dafür gibt, und wenn du nichts findest, dann poste die Meldung hier.

Ich arbeite da mit VMWare. Es dauert aber, bis ich wieder an die Original-Installation komme.
Bei einem zweiten Installationsversuch, nachdem ich Anwendung und Redist deinstalliert hatte,
kam diese Meldung nicht mehr.
Also ich hatte davor das "Redist für VS2015 bis 2019" installiert. Das hat aber (habs getestet) diesen
"Pre-Updatewunsch ?" des Systems nicht ausgelöst. Ich weiss also nicht, ob ich das wieder so wieder hinbekomme.
Die Merge Module werden jedenfalls nicht im Anwendungsverzeichnis installiert, was schon mal gut ist.

Nachtrag:
Ich kann auch dieses Redist wieder deinstallieren, ohne die installierte Anwendung dadurch unbrauchbar zu machen.
Startet also trotzdem noch.
Wenn ich aber die Anwendung deinstalliere und im Anschluss die Anwendung einfach wieder draufkopiere,
ohne sie zu installieren, funktioniert sie nicht.
Und ein anschliessendes Nachinstallieren dieses Redists bringt die Anwendung wieder in Gang.

Also, da diese Merge Module in irgendeinem Systemverzeichnis liegen, hoffe ich, dass sie gegebenenfalls
auch durch Windows Update gewartet werden.

Also nochmals vielen herzlichen Dank für eure Hilfe

hustbaer

@elmut19 sagte in Setup Projekt mit VS2019: erforderliche Komponenten ...:

Ich arbeite da mit VMWare. Es dauert aber, bis ich wieder an die Original-Installation komme.
Bei einem zweiten Installationsversuch, nachdem ich Anwendung und Redist deinstalliert hatte,
kam diese Meldung nicht mehr.
Also ich hatte davor das "Redist für VS2015 bis 2019" installiert. Das hat aber (habs getestet) diesen
"Pre-Updatewunsch ?" des Systems nicht ausgelöst. Ich weiss also nicht, ob ich das wieder so wieder hinbekomme.

Naja, ein Vorteil von VMs ist ja dass man da Snapshots machen kann. Ich hab da VMs mit allen interessanten Windows Versionen, und jede VM hat nen Snapshot der RTM Installation ohne weitere Windows Updated oder sonst was installiert. Testen einer Installation auf einem frischen System ist dann super einfach: Revert auf den Snapshot, Installationsfiles draufkopieren und starten.

Ich kann auch dieses Redist wieder deinstallieren, ohne die installierte Anwendung dadurch unbrauchbar zu machen.
Startet also trotzdem noch.

Wenn du auf einem frischen Windows nur eine Anwendung installierst, die die VS DLLs mit dem VCRedist installiert, und danach das VCRedist deinstallierst, dann lässt sich die Anwendung danach nicht mehr starten.

Es sei denn die Anwendung würde sowohl das VCRedist als auch die Merge Module installieren, oder es sind noch andere Anwendungen installiert die Merge Module verwenden.

Also, da diese Merge Module in irgendeinem Systemverzeichnis liegen, hoffe ich, dass sie gegebenenfalls
auch durch Windows Update gewartet werden.

Ich würde eher davon ausgehen dass das nicht passiert. Kann's aber nicht sicher sagen.

hustbaer

@Schlangenmensch sagte in Setup Projekt mit VS2019: erforderliche Komponenten ...:

@hustbaer sagte in Setup Projekt mit VS2019: erforderliche Komponenten ...:

Also entweder merge modules oder VCRedist oder runtime DLLs selbst bauen.

Redistributables sind doch auch "nur" DLLs, und die neben die Anwendung legen funktioniert noch. Auch wenn das nicht der von Microsoft empfohlene Weg ist.

Wenn ich mich richtig erinner hat es nicht funktioniert als ich es das letzte Mal versucht habe. Der entscheidende Unterschied ist soweit ich weiss auch nicht in den DLLs, sondern in den Programmen die die DLLs benötigen. Da ist die Dependency auf die Runtime DLLs irgendwie anders eingetragen als bei "normalen" DLLs. Frag mich nicht wie das genau heisst, ich kann dir nur sicher sagen dass da irgendwas anders ist, und es einen Unterschied macht.

Was ich sicher weiss ist dass es nicht funktioniert die Runtime DLLs von VS 2005 irgendwo in den Suchpfad zu kopieren. Ob es neben der Anwendung noch geht kann ich nicht 100% sicher sagen. Ich hätte angenommen nein, aber möglich dass das noch geht.

Schlangenmensch

@hustbaer sagte in Setup Projekt mit VS2019: erforderliche Komponenten ...:

Wenn ich mich richtig erinner hat es nicht funktioniert als ich es das letzte Mal versucht habe.

Mach mich nicht schwach. Ich bin mir eigentlich sehr sicher, dass es funktioniert. Aber natürlich habe ich gerade keine saubere VM zur Hand um das mal schnell durchzuspielen.

hustbaer

@Schlangenmensch sagte in Setup Projekt mit VS2019: erforderliche Komponenten ...:

@hustbaer sagte in Setup Projekt mit VS2019: erforderliche Komponenten ...:

Wenn ich mich richtig erinner hat es nicht funktioniert als ich es das letzte Mal versucht habe.

Mach mich nicht schwach. Ich bin mir eigentlich sehr sicher, dass es funktioniert. Aber natürlich habe ich gerade keine saubere VM zur Hand um das mal schnell durchzuspielen.

Hm. Also ich hab's jetzt mit VS 2022 probiert, und anscheinend geht dort sowohl neben der EXE hinlegen als auch irgendwo im Suchpfad. Hm. Komisch. Ich bin mir zu 95% sicher dass es mit VS 2005 zumindest im Suchpfad nicht ging. Aber vielleicht hat MS das auch wieder zurück-geändert? Keine Ahnung.

Schlangenmensch

@hustbaer sagte in Setup Projekt mit VS2019: erforderliche Komponenten ...:

m. Komisch. Ich bin mir zu 95% sicher dass es mit VS 2005 zumindest im Suchpfad nicht ging

Das ist eine Stelle, die ich "hier" noch nicht angepackt habe. Und wir haben jetzt mit VS 2015, 2017 und 2019 gearbeitet und die Redistributables neben die exe gelegt. Hier war auch mal VS 2010 im Einsatz, mit dem gleichen Ansatz, soweit ich weiß. Was vorher war, kann ich ehrlich gesagt nicht sagen.

Aber, dass das so möglich ist, wird auch von Microsoft so dokumentiert:

It's also possible to directly install the redistributable DLLs in the application local folder. That's the folder that contains your executable application file. For servicing reasons, we don't recommend you use this installation location.

https://docs.microsoft.com/en-us/cpp/windows/redistributing-visual-cpp-files?view=msvc-170

elmut19

@hustbaer sagte in Setup Projekt mit VS2019: erforderliche Komponenten ...:

@elmut19 sagte in Setup Projekt mit VS2019: erforderliche Komponenten ...:

Ich arbeite da mit VMWare. Es dauert aber, bis ich wieder an die Original-Installation komme.

Es sei denn die Anwendung würde sowohl das VCRedist als auch die Merge Module installieren, oder es sind noch andere Anwendungen installiert die Merge Module verwenden.

Also, da diese Merge Module in irgendeinem Systemverzeichnis liegen, hoffe ich, dass sie gegebenenfalls
auch durch Windows Update gewartet werden.

Ich würde eher davon ausgehen dass das nicht passiert. Kann's aber nicht sicher sagen.

Ich habe das mehrmals probiert.
Die Merge Modules sind demnach eine eigene Installation.
Die Anwendung funktionierte ohne das VCRedist.

In der Zwischenzeit hat mein Kollege auch das mit "... Im Verzeichnis der Anwendung ..." hinbekommen.
Das installiert nun wirklich das VCRedist separat. und wenn man da das VCRedist wieder deinstalliert,
geht die Anwendung auch nicht mehr.
In den Verzeichnissen des erstellten Setup sind dann auch keine einzelnen DLLs, wie bei den Merge Modules,
sondern nur das VCRedist. Somit wäre dann diese Variante noch besser, da keine doppelte Installation (evtl durch anders Setup-Progr).
Auch die Wartung durch "Windows Update" könnte ich mir so sogar eher vorstellen (weil nicht mehrere Pfade gewartet werden müssen).

Ich muss mir das aber noch ansehen.
Irgendwie habe ich den Verdacht, dass der Schreiberling bei Microsoft selbst nicht weiss, wie es funktioniert.
Ich habe da jedenfalls nix verstanden!