Lorsque des dépendances des assemblées 3ème partie sont ajoutées à une application typique .NET, il est très facile d'oublier de les ajouter à l'installateur. Ce problème a tendance à se révéler uniquement après l'installation de l'application et sous la forme d'un accident au démarrage avec peu d'informations utiles facilement disponibles.
Quels sont les meilleurs outils et techniques pour déterminer quels assemblages doivent être ajoutés à l'installateur?
3 Réponses :
Dépendance Walker est un excellent petit utilitaire qui suit une chaîne de dépendances à partir d'une application ou d'une DLL et met en évidence tout ce qui manque. Ce n'est pas vraiment que cela soit intuitif pour que l'utilisateur final soit à utiliser, mais j'espère que si vous commencez à l'utiliser, vous attrapez vous-même des objets manquants.
Walker de dépendance n'est pas très utile avec les assemblées .NET
Les constructions entièrement automatisées aident à réduire le composant humain et donc l'erreur. S'il est automatiquement construit à chaque fois, vous savez que chaque construction sera la même, alors une fois que vous l'avez travaillé une fois, cela va toujours travailler.
Nous utilisons des outils tels que MSBUILD et Cruisecontrol.net
Si vous recherchez des outils qui vous aident à déterminer la cause de l'accident, prenez un journal sur le Viewer de la liaison (Fusion) Log (ou fuslogvw) . Si vous le démarrez avant de démarrer votre application, définissez l'emplacement du fichier journal et tournez la liste de journalisation complète indiquant toutes les tentatives pour lier les assemblys et répertorier les échecs.
Ma candidature est construite avec MsBuild par CCNet qui exécute également des tests d'acceptation automatisés mais ne teste actuellement pas l'installateur. Je suppose que ce serait une approche pour attraper le problème le plus tôt possible, mais je demande spécifiquement de l'aide pour trouver ce que le problème est quand il s'est déjà produit.
Donc, vous n'êtes pas après quelque chose qui l'empêche de se produire, mais après quelque chose qui vous indique que .dll manquait lorsque l'application se bloque sur une machine client?
Oui, eh bien, sur une machine d'essai d'abord, j'espère! ;)
Ahh, j'ai mal compris la question de la première fois. Voir l'édition que j'ai fait re fuslogvw.
J'étais au courant de Fuslogvw, mais j'espérais quelque chose qui était un peu plus facile à utiliser. Tant pis! Merci.
dépend des capacités de votre installateur. Les projets de configuration intégrés VS peuvent choisir automatiquement tous les assemblages à charge. Vous voudrez peut-être vérifier si votre installateur a des caractéristiques similaires.
D'autre part, vous pouvez demander à vos projets VS de copier toutes les dépendances dans le répertoire de sortie et incluez simplement tous les fichiers de là dans votre installateur.
J'utilise Wix et énumère explicitement les fichiers à inclure.
Je ne suis pas au courant d'outils WIX qui peuvent vous aider, afin que vous puissiez rester avec ma suggestion pour simplifier simplement tous les fichiers du répertoire de sortie. Que le plus facile que je puisse penser. Si le projet fonctionne à partir du répertoire de sortie, il doit également être installé sur la machine cible.