Visual C++ : Problème d'intégration de code Windows 8 -> Windows 10

Bonjour,

Actuellement je tente d'exécuter du code développé sous VS 2015 et Windows 8.1. Je possède également VS2015 mais je travaille sur une station Windows 10...

Ce code utilise pas mal de dépendances au niveau des API système (par exemple : écriture dans le registre, gestion des signaux d'erreur, etc...).

Ces DLL ne sont présentes que dans le répertoire C:\Windows\System32 du poste Windows 8.1 auteur du code.

Le code compile et s'exécute parfaitement sur le poste auteur sous Windows 8.1. Il compile également sur le nouveau poste sous Windows 10 mais crashe à l'exécution.

Pour pallier au problème des DLL présentes sur le poste auteur et absentes sur le nouveau poste, j'ai installé les SDK Windows 10 et 8 sur le nouveau poste, qui installe certaines librairies natives Windows 8.1.

Malgré cela, mon explorateur de dépendances m'indique qu'il me manque d'autres librairies... Et je me vois mal aller fouiller sur des sites de dll share pour récupérer ces librairies une par une...

Voyez-vous autre chose à récupérer que les SDK 8 et 10 pour pouvoir exécuter du code développé sous Windows 8.1 à partir d'une station Windows 10 ?

Merci beaucoup !

Jimmy91

Plutôt que le SDK, on est censé utiliser les Redistribuables, sur une machine client...
(ainsi que, le cas échéant, la bonne version du Framework .Net)

Pour compléter la réponse de @Médinoc, votre manière de faire tient plus du bricolage que d'un développement professionnel, ne vous offusquez pas, vous êtes malheureusement pas le seul à faire ce genre de chose, malheureusement.

Pour éviter que cela ne se transforme en cauchemar, il faut juste un peu de méthode.

Le problème n'est donc pas lié ni à Windows 8.1, ni à Windows 10 ni à VS2015 mais au syndrome bien connu du programme qui ne fonctionne que sur la machine du développeur, qui a oublié de noter toutes les dépendances au système et autres composants, et avec la devise "Si ça marche chez moi, ça marche partout" et que "les services de QA (Quality Assurance), c'est que des branleurs".

Si une application utilise des composants qui ne sont pas disponible DE BASE sur TOUTES les machines cibles, il est nécessaire de faire un installeur, MSI ou autre, qui sera en charge d'installer correctement toutes les choses pré-requise à l'exécution du programme.

"C:\Windows\System32" n'est pas un dépotoir, enfin, ne devrait pas l'être. :(
Sauf exception très particulière, aucune Dll autre que celles du système de base, ne devraient exister dans ce répertoire.

Les installeurs des Redistribuables savent où mettre correctement ces Dll. Et pour les Dll de votre cru, essayez de les isoler dans le répertoire d'installation de votre application (quitte à configurer un fichier manifeste pour les plateformes plus durcies d'un point de vue sécuritaire).

Bonjour bacelar et Médinoc, je vous remercie pour vos conseils.

Vous avez raison de me prévenir que C:\Windows\System32 "n'est pas un dépotoir", j'ai donc cessé de comparer la présence de DLL entre les deux machines.

J'avais déjà installé les Redistribuables de Microsoft mais cela s'est avéré inutile.

En fait, le problème provenait du fichier MSVCP100D.DLL présent dans le répertoire d'installation. Il était compilé pour 32 bits alors que mon application était exécutée en 64 bits !

Voilà, mon problème est donc résolu. Encore merci pour votre aide :-)

MSVCP100D.DLL?

Alias la version Debug de la CRT? Elle n'est pas redistribuable, la licence de Visual Studio l'interdit explicitement. Un indice de plus pour dire "Ne publiez pas vos programmes en version Debug".