VS2017 et "api-ms-win-core-rtlsupport-l1-2-0.dll" manquants sur Win7/XP
Après le portage de certains de mes programmes de VS2015 à VS2017, nous avons constaté que les fichiers binaires ne fonctionnaient plus sous Windows 7 ou Windows XP, même s'ils ont été compilés avec le groupe d'outils v141_xp. Le programme ne parvient pas à démarrer avec DLL api-ms-win-core-rtlsupport-l1-2-0.dll manquant (notez le2).
Je suis bien conscient que ces DLL api-ms-win-* appartiennent à UCRT et que, à partir de VS2015, je dois redistribuer les DLL UCRT à partir du SDK Windows 10 (à trouver à Redist\ucrt\DLLs dans le répertoire Windows 10 SDK), avec mon application. - il suffit de redistribuer le vcruntime140.dll et le msvcp140.dll estnotsuffisant. Mais il n'y a que api-ms-win-core-rtlsupport-l1-1-0.dll dans mon répertoire SDK Windows, maisnotapi-ms-win-core-rtlsupport-l1-2-0.dll. Je viens de télécharger et de réinstaller le dernier SDK Windows (10.0.15063), juste pour être sûr. Toujours le DLL en question est absent!
J'ai également essayé d'installer le package VS2017 redistribuable sur la machine Windows 7 (ou XP) via VC_redist.x86.exe - dernière version téléchargée à partir du site Web de Visual Studio (14.11.25325). Évidemment, cela copie la DLL api-ms-win-* dans le répertoire "System32". Mais, encore une fois, seul api-ms-win-core-rtlsupport-l1-1-0.dll, maisnotapi-ms-win-core-rtlsupport-l1-2-0.dll. L'application ne démarre toujours pas: - /
Des idées?
Merci et meilleures salutations,
MuldeR
[EDIT]
Cela ne s'applique bien entendu que si je crée un lien avec le DLL runtime (/MD). Si je fais un lien avec le runtime "statique" (/MT), je reçois un binaire qui dépend denoDLL sur UCRT et fonctionne correctement sous Windows 7 et XP.
[EDIT # 2]
S'il vous plaît se référer à mon autre poste (y compris EDIT) pour la résolution du désordre:
https://stackoverflow.com/a/45773325/1766377
OK, c’est assez intéressant: Je viens de terminer mon VS2017 a trouvé une nouvelle mise à jour. Apparemment, cela a mis à jour mon VS2017 de v15.2 à v15.3.1. Les bibliothèques d'exécution ont également été mises à jour, semble-t-il!
Il y a maintenant deux répertoires, VC\Redist\MSVC\14.11.25325etVC\Redist\MSVC\14.11.25415, à l'intérieur du répertoire d'installation VS2017. Le vcruntime140.dll existe dans les deux répertoires. Mais la version plus récente (25415, à droite) présente des dépendances bien différentes de celle de la version précédente (25325, à gauche):
.__ Seule la "nouvelle" version a des dépendances qui manquent sous Windows 7. Donc, je devrais aller avec "l'ancienne" version. Mais cela signifie que je suis verrouillé à la "vieille" version. Est-ce normal/prévu ???
(BTW: les deux DLL versions de VS2017 v15.3.1 sont plus récentes que celles que j'ai initialement extraites de v15.2)
Cordialement,
MuldeR
[MODIFIER]
Ainsi, on vient de me signaler qu'il existe une différence subtile entre les répertoires VC\Redist\MSVC\14.11.25325etVC\Redist\MSVC\14.11.25415: le répertoire 25415 contient tous les fichiers DLL dans un autre sous-dossier. appelé onecore, l'autre pas. Apparemment, cela signifie que les "plus récentes" DLL versions (celle avec le sous-dossier onecore) sont pas censées être redistribuées avec des applications de bureau normales; ils sont strictement destinés à la plate-forme Mobile/IoT «OneCore».
Conclusion:
M $ a fait un excellent travail pour concevoir la structure de répertoires Redist aussi déroutante que possible. Placer les numéros de version des redistribuables "normal" et "onecore" au même niveau de la hiérarchie des répertoires (plutôt que de disposer des répertoires onecore et desktop séparés sur le niveau) indique que ces répertoires représentent versions de la même chose - ce qui n'est pas le cas du tout: - /
Ne * pas * redistribuer les DLL */onecore/* avec les applications de bureau normales!
Dans les pages de propriétés du projet, essayez de modifier la version du Kit de développement logiciel (SDK) Windows de 10.0.15063.0 à 10.0.10240.0. Je pense que cela résoudra le problème, à condition que l’ancien SDK soit installé sur votre machine de compilation. Vous pouvez également essayer de changer le jeu d’outils de la plate-forme en v140_xp. VS 2017 est ensuite construit avec la chaîne d'outils VS 2015, à condition que VS 2015 soit installé.
Ma préférence personnelle est d’éviter tout «enfer de DLL» en liant avec le runtime statique, bien que cela ne fonctionnera pas si un exe et un dll doivent partager un tas et encourir des pénalités d’espace si vous construisez plusieurs deux).