Setup Projekt mit VS2019: erforderliche Komponenten ...



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



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



  • @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.



  • @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.



  • @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.



  • @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.



  • @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



  • @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.



  • @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.



  • @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.



  • @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.



  • @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



  • @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!



  • @Swordfish Wozu beleidigend werden, gewinnst du elender Troll dadurch deine Kraft ?



  • @elmut19 Nachtrag:
    Was irgendwie blöd ist: Man muss dieses "vc_redist.x86.exe" extra in folgendes Verzeichnis kopieren:
    C:\Program Files (x86)\Microsoft SDKs\ClickOnce Bootstrapper\Packages\vcredist_x86

    Zu finden ist das "vc_redist.x86.exe" aber in einem anderen Verzeichnis:
    C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Redist\MSVC\v142

    Im Setup Projekt ist dann auch unter den "Prerequisites" die "C++14 runtime lib" anzukreuzen.
    Diese landet dann im Setup Projekt automatisch im Verzeichnis "vcredist_x86", parallel zur "setup.exe".
    Es wird beim Erstellen des Setup Projekts jedesmal neu erstellt.
    Wenn man das Setup ausführt, wird dann zunächst dieses Redist installiert. Dauert sehr lange, bei mir.

    Neben diesem "vc_redist.x86.exe" gibt es noch ein "vcredist_x86.exe" mit gleicher Grösse und Version.
    Keine Ahnung warum. Mit der "vc_redist.x86.exe" hat die Installation funktioniert. Die ist auch in der
    MS-Doku zu finden. Vorteil, man hat nur eine Installation der c++ Libs.
    Ich denke, dass die auch über das Windows Update gepflegt wird. Aber wer weiss...
    Aber ich habe die Microsoft Doku dazu nicht verstanden.



  • Wie das mit VCRedist ins Setup integrieren funktioniert, damit hab ich mich nie beschäftige. Kann dazu keine Hilfe anbieten. Es würde mich aber nicht wundern wenn da ein paar Dinge etwas komisch wären.

    Das wichtigste ist aber dass es für den User möglichst angenehm ist, also nur 1 Setup File runterladen, ausführen, und läuft. Danach käme für mich dann der Punkt dass das installierte Programm nur einen Eintrag in der Applications Liste haben sollte.

    Wenn man das Setup ausführt, wird dann zunächst dieses Redist installiert. Dauert sehr lange, bei mir.

    OK, das ist doof. Und komisch. Die letzten male wo ich VCRedist installiert habe, ging das immer halbwegs flott. Was heisst denn "sehr lange" ca.?



  • @hustbaer Hallo Hustbaer
    Ich teste das derzeit nur unter meinem virtuellen Win7. Da hängt der Prozess geschätzt schon 1 bis 3 Minuten.
    Und der Fortschrittsbalken bleibt dabei stehen. Warum, weiss ich natürlich nicht.
    Aber es ist ein einziger Setup-Prozess. Man muss sonst nichts weiter bestätigen.

    Mein Chef hätte gerne eine Mehrplatz Installation, bei der man von allen weiteren Rechnern aus die Anwendung
    nur über einen Desktop-Link auf die exe im Netzlaufwerk startet. Dort würde sich dann anbieten, auch nur
    das Redist zu installieren. Also wenn wir dann rausbekommen, wie man da eine Auswahl treffen kann.
    Ausserdem ist das Redist dabei ja komplett im Setup-Verzeichnis enthalten und kann separat aufgerufen werden.

    Wenn man weiss, dass man das benötigte Redist, mit besagtem Namen, extra in das besagte Verzeichnis kopieren
    muss, ist diese Variante auch recht einfach herzustellen.



  • Zum Starten von einem Netzlaufwerk aus würde sich doch eher anbieten die DLLs neben die EXE hinzulegen, oder? Natürlich werden die dann nicht automatisch upgedated. Aber zumindest hat man dann nur einen Platz wo man die DLLs updaten muss.



  • @hustbaer
    Tja, das sind keine leichten Entscheidungen.
    Aber derzeit sind für uns nachträgliche Updates kaum machbar.
    Wir bräuchten da schon eine Automatisierung.
    Die Updates erfolgen nur bei Bedarf, wenn neue Funktionen gewünscht werden.



  • Also erstmal würde ich mich schlau machen ob es überhaupt irgendeine Variante gibt wo die Runtime DLLs von Windows Update serviciert werden. Ich bin mir da nämlich nicht so sicher. Und wenn das nicht der Fall ist, dann würdest du die für den Kunden einfachste Variante ausschliessen, wegen eines Vorteils einer anderen Variante, der gar nicht real ist.


Anmelden zum Antworten