J'ai un cauchemar en essayant de faire installer un simple installateur dans InstallShield LE (celui livré avec VS 2012). Il y a toutes sortes de problèmes sur lesquels je peux travailler (comme le fait que je ne peux plus faire de "Reconstruire tout" sans tout gâcher - je dois simplement décharger le projet InstallShield pendant le développement). Mais le gros problème est que, lorsque je construis mon programme d'installation, il inclut la mauvaise version de plusieurs DLL (y compris celles qui font partie de mon projet et les versions tierces telles que la DLL Entity Framework).
Faire une "solution propre" n'a même pas résolu le problème avec les DLL qui sont dans ma solution. Il cherchait une version aléatoire quelque part sur ma machine (dans un répertoire temporaire du compilateur) et insistait pour l'inclure. J'ai finalement résolu le problème en effectuant une recherche dans l'Explorateur Windows et en supprimant tous les fichiers trouvés, mais je crains que la prochaine fois que je publie une version, il sera toujours possible de choisir le mauvais fichier.
De plus, je dois disposer des versions Entity Framework .NET 4 et .NET 4.5 sur ma machine, et choisir la mauvaise version pour mon installateur. Je ne peux pas supprimer celui que je ne veux pas inclure.
Quel produit absolument de mauvaise qualité. Je pourrais "passer" à la version complète pour voir si cela résout ces problèmes, mais mon expérience récente avec la version LE me dissuade de jamais utiliser l’un de leurs produits.
Quelqu'un at-il eu des problèmes similaires? Avez-vous trouvé une solution?
J'ai récemment rencontré le problème que vous décrivez: une application de console est construite correctement, avec des versions à jour des dépendances dans le répertoire bin
, mais lorsqu'elle est fournie avec InstallShield LE, elle utilise les anciennes versions des DLL de dépendance.
Comme tu dis:
Faire une "solution propre" n'a même pas résolu le problème avec les DLL qui sont dans ma solution. Il s'agissait de trouver une version aléatoire quelque part sur ma machine (dans un répertoire de compilation du compilateur), en insistant pour l’inclure.
Dans mon cas, les fichiers incriminés se trouvaient dans le cache de compilation dynamique ASP.NET à C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root
et C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root
.
Effacer le contenu de ces répertoires a résolu le problème.
En passant, j'ai pensé à ajouter une action de construction pour vider ces répertoires automatiquement, mais je ne pouvais pas le faire automatiquement sans tomber à terre.
Chaque outil de configuration a ses problèmes. Veuillez noter qu'aucun outil ne peut détecter avec précision les dépendances de votre application. Le mieux qu'un outil puisse faire est de faire des suggestions. C'est pourquoi la plupart des développeurs d'installation déterminent eux-mêmes les dépendances et les incluent manuellement dans le programme d'installation.
Si InstallShield ne vous convient pas, vous pouvez essayer un autre outil de configuration: http://en.wikipedia.org/wiki/List_of_installation_software
La version gratuite du programme d'installation avancée inclut un projet d'installation Visual Studio qui peut aider.
J'avais un problème avec ma DLL. Il était en train de récupérer un homme beaucoup plus âgé quelque part. Rien n'était dans le GAC pour cette DLL. J'ai tout essayé. Enfin, je viens d’ajouter la chose à la main (ISLE) dans la section Fichiers en cliquant avec le bouton droit de la souris et en sélectionnant Ajouter. J'ai trouvé le DLL dans mon dossier\obj\Release. Ensuite, je viens de construire à nouveau la version (SingleImage) et tout a fonctionné correctement.
Vous pouvez résoudre les problèmes d'ordre de construction (comme lorsque vous essayez de reconstruire la solution) en cliquant avec le bouton droit de la souris sur la solution -> Dépendances du projet -> Sélectionnez votre projet d'installation et vérifiez les projets qu'il utilise. (Testé dans VS2013)
Je m'attendais à ce que le projet InstallShield définisse ces dépendances automatiquement lorsque vous sélectionnez ses fichiers source, mais ce n'est apparemment pas le cas.