it-swarm.com.de

VS2017 und fehlende "api-ms-win-core-rtlsupport-l1-2-0.dll" auf Win7/XP

Nach dem Portieren einiger meiner Programme von VS2015 nach VS2017 in wurde festgestellt, dass die Binärdateien unter Windows 7 oder Windows XP nicht mehr ausgeführt werden - obwohl sie haben mit dem Toolset v141_xp kompiliert wurden. Das Programm startet nicht mit fehlendem DLL api-ms-win-core-rtlsupport-l1-2-0.dll (beachten Sie die 2 ).

Mir ist bekannt, dass diese api-ms-win-*-DLLs zum UCRT gehören und dass ich ab VS2015 die UCRT-DLLs aus dem Windows 10-SDK (zu finden unter Redist\ucrt\DLLs im Windows 10-SDK-Verzeichnis) zusammen mit meiner Anwendung neu verteilen muss - Nur die Neuverteilung von vcruntime140.dll und msvcp140.dll ist nicht ausreichend. In meinem Windows SDK-Verzeichnis befindet sich jedoch nur api-ms-win-core-rtlsupport-l1-1-0.dll, jedoch nicht api-ms-win-core-rtlsupport-l1-2-0.dll. Ich habe gerade das neueste Windows SDK (10.0.15063) heruntergeladen und neu installiert, nur um sicherzugehen. Immer noch fehlt das fragliche DLL!

Ich habe auch versucht, das VS2017 Redistributable-Paket über VC_redist.x86.exe auf dem Windows 7- (oder XP-) Computer zu installieren - die neueste Version wurde von der Visual Studio-Website heruntergeladen (14.11.25325). Offensichtlich kopiert das die api-ms-win-* DLL's in das "System32" Verzeichnis. Aber wieder nur api-ms-win-core-rtlsupport-l1-1-0.dll, aber nicht api-ms-win-core-rtlsupport-l1-2-0.dll. App startet immer noch nicht: - /

Irgendwelche Ideen?

Danke und viele Grüße,
MuldeR

enter image description here

enter image description here


[EDIT]

Dies gilt natürlich nur, wenn ich gegen die DLL Laufzeit (/MD) verlinke. Wenn ich eine Verknüpfung zur "statischen" Laufzeit (/MT) herstelle, erhalte ich eine Binärdatei mit no DLL Abhängigkeiten zu UCRT und läuft einwandfrei unter Windows 7 und XP.


[EDIT # 2]

In meinem anderen Beitrag (einschließlich EDIT) finden Sie Informationen zur Lösung des Problems:
https://stackoverflow.com/a/45773325/1766377

7
MuldeR

Okay, das ist ziemlich interessant: Gerade jetzt mein VS2017 hat ein neues Update gefunden. Anscheinend hat mein VS2017 von v15.2 zu v15.3.1 aktualisiert. Die Laufzeitbibliotheken wurden ebenfalls aktualisiert.

Es gibt jetzt zwei Verzeichnisse, VC\Redist\MSVC\14.11.25325undVC\Redist\MSVC\14.11.25415, in meinem VS2017-Installationsverzeichnis. Der vcruntime140.dll ist in beiden Verzeichnissen vorhanden. Die neuere Version (25415, rechts) hat jedoch ganz andere Abhängigkeiten als die ältere (25325, links):

enter image description here
Nur die "neue" Version hat Abhängigkeiten, die unter Windows 7 fehlen. Ich sollte also gut mit der "alten" Version umgehen. Aber ich bin an die "alte" Version gebunden. Ist das normal/beabsichtigt ???

(BTW: Beide DLL -Versionen von VS2017 v15.3.1 sind neuer als die, die ich ursprünglich von v15.2 genommen habe).

Grüße,
MuldeR


[BEARBEITEN]

So wurde ich gerade darauf aufmerksam gemacht, dass es einen subtilen Unterschied zwischen den Verzeichnissen VC\Redist\MSVC\14.11.25325undVC\Redist\MSVC\14.11.25415 gibt: Das Verzeichnis 25415 enthält alle DLL -Dateien in einem anderen Unterordner genannt onecore, der andere nicht. Offenbar bedeutet dies, dass die "neueren" DLL -Versionen (die mit dem onecore-Unterordner) nicht sind, die mit normalen Desktop-Anwendungen umverteilt werden sollen; Sie sind ausschließlich für die "OneCore" Mobile/IoT-Plattform.

Fazit:
M $ hat die Redist-Verzeichnisstruktur so verwirrend wie möglich gestaltet. Wenn die Versionsnummern der umverteilbaren Dateien "normal" und "onecore" auf dieselbe Ebene der Verzeichnishierarchie gesetzt werden (anstatt onecore und desktop-Verzeichnisse auf that - Ebene zu haben), zeigt dies an, dass diese Verzeichnisse unterschiedliche Darstellungen enthalten Versionen desselben - was überhaupt nicht der Fall ist: - /

Verteilen Sie keine */onecore/*-DLLs mit normalen Desktop-Anwendungen!

5
MuldeR

Versuchen Sie, auf den Eigenschaftenseiten für das Projekt die Windows SDK-Version von 10.0.15063.0 auf 10.0.10240.0 zu ändern. Ich denke, das wird das Problem beheben, vorausgesetzt das ältere SDK ist auf Ihrem Build-Computer installiert. Etwas anderes zu versuchen ist, das Plattform-Toolset in v140_xp zu ändern. VS 2017 baut dann mit der VS 2015-Toolkette auf, sofern VS 2015 installiert ist.

Meine persönliche Präferenz ist es, jegliche "DLL-Hölle" durch die Verknüpfung mit der statischen Laufzeit zu vermeiden. Dies funktioniert jedoch nicht, wenn ein Exe und eine DLL einen Heap gemeinsam nutzen müssen, und wenn Sie mehrere Binärdateien erstellen, führt dies zu Speicherplatzbelastungen zwei).

0
Paul Sanders