Y compris l'exécution MS C++ dans VS2005 généré MSI

Question

J'ai un projet qui dépend d'une version particulière de MSVCR80.dll (le MS Visual C Runtime) et je rencontre des problèmes où, en fonction de la configuration du système particulier, mon application n'obtient pas toujours la bonne version de ce fichier. Cela a été un peu un connerie quant au chemin qu'il faut pour trouver un fichier avec ce nom, et ce n'est pas toujours correct ...

Y at-il un moyen, lors de la création d'un projet de déploiement dans VS2005, à assurer que mon application va toujours utiliser le runtime que j'ai fourni ?? Lorsque j'ajoute le fichier d'exécution au projet, il pose la question de la création d'un module de fusion ... mais pas vraiment sûr de ce que cela fait. Et indépendamment de la création d'un, le problème demeure.

Answer 1

Martin Richter a écrit un article à ce sujet sur CodeProject: Create projects easily with private MFC, ATL and CRT assemblies

Cette solution ne repose pas sur vos packages MSI, mais sur l'application qui utilise les fichiers CRT.

Answer 2

Je ne suis pas sûr si c'est votre application après l'installation qui ne fonctionne pas, ou si c'est une DLL que vous utilisez dans le cadre de l'installation qui ne fonctionne pas? Pour faire une histoire très longue, très courte: les nouvelles versions des runtimes C/C++ sont installées en tant que assemblages Win32, ou installation côte à côte. Cela signifie que les fichiers vont dans des dossiers sous C: \ Windows \ winsxs - l'équivalent Win32 du GAC, et plusieurs versions du même fichier peuvent coexister ici.

Les applications compilées avec Visual Studio 2005/2008 mettra un fichier manifeste dans le binaire, et ce manifeste spécifie ce côté-à-côte version d'exécution pour se lier à. Ce n'est pas grave si vous mettez le MSVCR80.dll à côté de votre EXE ou même dans system32 - le manifeste incorporé dans le fichier EXE chargera le fichier de C: \ Windows \ winsxs.

Tout est "cercle complet". Dans l'ancien temps, les temps d'exécution allaient à System32. Cela a causé l'original dll-hell: les applications écrasant les fichiers d'exécution globaux de l'autre. Pour remédier à tout cela, l'idée était d'isoler les changements à chaque application. La nouvelle approche consistait donc à isoler une copie locale du fichier d'exécution à côté de l'EXE. Cela a provoqué un problème entièrement nouveau: comment vous assurez-vous que les mises à jour de sécurité pour la DLL isolée ont été déployées? Dans la plupart des cas, cela ne s'est jamais produit et vous avez eu beaucoup d'applications exécutées avec des DLL locales non sécurisées. Alors que faire? La décision a été d'introduire la seconde venue de dll-hell: l'approche de l'assemblage côte-à-côte. Dans cette approche, les temps d'exécution ne sont pas locaux, mais globaux - avec la différence critique d'installations côte-à-côte. De cette façon, en théorie, les applications peuvent fonctionner sans écraser les DLL d'exécution de l'autre.

Donc, c'était le résumé rapide de "comment compliquer le déploiement d'exécution". Je ne suis pas positif, il est encore possible de le faire, mais avez-vous vérifié si vous pouvez lier statiquement à l'exécution? Parfois, la vieille école est vraiment plus facile ...