2009-05-25 3 views
0

J'ai plusieurs bibliothèques de classes contenant des commandes et des mises à jour automatiques pour ArcGIS. Jusqu'à présent, chaque bibliothèque contenait une classe d'installation, et nous avions un seul projet d'installation qui était responsable de l'installation de toutes les DLL. Tout comme in here.
J'ai maintenant créé une autre bibliothèque contenant une barre d'outils, qui devrait contenir toutes les commandes que nous avons. Le projet réoriente les autres projets, et le AddItem (De la classe de base BaseToolbar) utilise la surcharge AddItem(Type type), pour que tout soit fortement typé et pas seulement basé sur des chaînes (pour CLSID ou noms).
Naturellement, le projet Toolbar contient l'insallter. Je voulais juste savoir si c'est une bonne idée de changer l'implémentation suggérée du programme d'installation (à partir du lien ci-dessus), afin de s'assurer que toutes les commandes seront enregistrées (Iterating sur les fichiers dll dans le dossier de sortie, et l'enregistrement Existe-t-il un meilleur moyen?)
Cela va déplacer le souci d'installation de chaque projet de commande, dans un endroit centralisé. Je pense qu'il sera plus facile d'ajouter plus de commandes, car je n'aurai qu'à ajouter une référence à partir du projet Toolbar. Est-ce logique, ou devrais-je m'en tenir à mettre un installateur dans chaque projet séparément, et les ajouter au projet d'installation un par un?arcgis com enregistrement

Et une autre chose - existe-t-il un moyen facile de trouver d'où viennent plusieurs commandes, à l'intérieur d'ArcMAP? J'ai là des catégories étranges (créées par les anciens utilisateurs sur cette machine), avec d'anciennes commandes que je voudrais supprimer.

Répondre

0

Je pense que c'est logique. Vous devez juste être sûr que tout est au bon endroit quand l'installateur (comme dans Wise, installshield, etc.) appelle RegisterAssembly et UnregisterAssembly sur votre assembly d'installation. Par exemple, si la désinstallation supprime vos assemblys "command" avant d'appeler UnregisterAssembly, cela peut poser un problème. Je pense que vous avez juste à le tester pour le savoir. Tant que vous savez que tous les assemblages de "commande" seront disponibles, il semblerait que cela fonctionnerait bien.

Vous pouvez également le résoudre en incluant simplement le code d'installation commun dans un ensemble commun distinct et implémentez toujours les classes d'installateur.

0

Un workflow meilleur et pratique consisterait à avoir toutes les commandes ect dans une bibliothèque/ensemble lui-même. De cette façon, vous n'avez qu'un seul DLL à enregistrer.

Pour trouver les DLL d'autres outils personnalisés: Il y a un truc. Déboguer toute extension ou échantillon ArcGIS personnalisé, qui exécute ArcMap. Gardez un œil sur la fenêtre de sortie dans Visual Studio. Cela vous donnera une liste de toutes les DLL qui sont chargées par ArcMap

+0

Oui, je sais que nous aurions dû créer une DLL unique pour toutes nos commandes. Devrait avoir le mot clé :-) merci pour le pourboire vs. Je vais regarder cette liste. –