Nous avons actuellement une solution développée à l'aide de SSIS / C #. Le package SSIS (entre autres choses) a une tâche de script utilisant la logique développée dans les bibliothèques de classe. Cette fonctionnalité doit rester séparée du paquet SSIS.
Parce que nous utilisons un paquet SSIS, je comprends que la DLL compilée doit être déployée sur le GAC, puis référencée de la tâche de script. Cependant, cela crée un problème de déploiement pour nous.
Notre outil de déploiement automatisé (à juste titre) incrémente automatiquement les numéros de version de la DLL, qui sont ensuite publiés sur le GAC. Cependant, cela enfreint le paquet SSIS, car il essaiera d'accéder à la DLL basée sur le numéro de version qu'ils ont été publiés dans la machine de développement GAC comme.
La seule solution que nous ayons à obtenir pour obtenir la DLL compilée, manuellement modifier la tâche de script de package SSIS, puis publier le package.
On dirait qu'il doit y avoir une meilleure façon de le faire - a-t-il rencontré ce problème et propose une meilleure solution? Ou y a-t-il quelque chose de fondamental dans notre approche que nous devons changer (au-delà de l'élimination de la nécessité de la DLL)?
Merci!
4 Réponses :
Êtes-vous absolument sûr que ces dlls partagées doivent être déployées sur le GAC? S'ils sont dans le même dossier que le paquet SSIS, ils doivent être découverts par le cadre sans la nécessité de les ajouter au GAC.
N'y a-t-il aucun moyen de mettre à jour votre système de construction pour éviter le changement de numéro de version? Si le code de ces assemblées ne change pas, il n'est pas nécessaire de mettre à jour le numéro de version.
Si vous ne pouvez pas éviter l'incrément de version, l'autre alternative consiste à créer un fichier de stratégie avec les assemblys partagés et à utiliser cela pour "rediriger" le package SSIS à la nouvelle version avec chaque construction.
Les informations que j'ai sont que les packages SSIS doivent être déployés sur le GAC, excellent sinon - mais êtes-vous sûr? développeurdotStar.com/community/node/333 Numéro de construction - Je suppose que nous pourrions, mais Cette idée me rend un peu mal à l'aise. Je n'ai pas utilisé les fichiers de politique avant, je vais aller les regarder, merci
Je n'ai pas essayé un paquet SSIS avec des dépendances externes, je ne suis donc pas sûr. Devrait être assez facile d'accumuler une maquette de votre colis avec la dépendance et faites un test de fumée rapide ...
Bonjour Dave - J'ai enquêté sur des dossiers de politique alors qu'ils concernent des solutions SSIS, je ne peux pas vraiment voir comment j'irais en introduire un sans créer une autre dépendance. Il se manquera peut-être quelque chose, mais si vous avez des informations supplémentaires sur la manière dont ils peuvent être utilisés avec des packages SSIS, il serait très apprécié!
Oui, nous avons essayé des tests de fumée sans utiliser le GAC, les approches que nous avons adoptées ont échoué. La seule autre chose que nous aurions pu penser était d'utiliser la réflexion pour charger de manière dynamique la classe à partir d'un emplacement de fichier - mais cela semble également un moyen extrême de se déplacer
Eh bien, après de nombreuses recherches, je n'ai jamais vraiment trouvé une solution satisfaisante pour cela. À la fin, le plus proche que je puisse avoir été une solution où j'ai chargé mes références de manière dynamique:
Dim rsAssembly As Assembly = Assembly.LoadFile("path from config file")
Dim rsType As Type = rsAssembly.GetType("class name from config file")
Dim obj As Object = Activator.CreateInstance(rsType)
J'ai remarqué des problèmes similaires avec notre SSIS / C # Mix. Nous comptons également sur une DLL externe (à la SSIS). Dans notre cas, la DLL devait être copiée dans le répertoire 100 / DTS / Binn pour permettre au package SSIS de fonctionner à partir de Visual Studio, mais nous essayons d'exécuter le paquet à l'aide de l'utilitaire d'exécution du package SQL, nous obtenons une erreur à l'affect. le fichier n'a pas pu être trouvé. Il ne semble pas indiquer une version de version tant qu'une différence de chemin entre le studio Visual Studio et l'utilitaire d'exécution du package. Même en exécutant le paquet sans débogage de Visual Studio Works. Je vais examiner la question de la version pour voir si peut-être que c'est la plainte de base de notre système, mais de la mémoire, je pense que c'était une erreur de type de fichier non trouvée qui nous a affectés. Nous utilisons MSSQL 2008 si cela fait une différence.
Dans Suivi, j'ai pu exécuter le colis avec succès en copiant la DLL vers le répertoire Windows \ Assembly Machines. Apparemment, c'est l'emplacement de GAC insaisissable? Quoi qu'il en soit, notre mécanisme de déploiement n'est pas encore automatisé, alors peut-être que c'est pourquoi nous n'avons pas les problèmes de version. Une fois que je copie la DLL vers le Dir Windows \ Assembly Dir, le colis s'allume à la fin.
Salut Travis - Oui, c'est l'emplacement du GAC, pas sûr des restrictions sur SQL 2008, mais si cela aide, je peux vous confirmer que dans un serveur déployé sur SQL 2005, la DLL doit être déployée sur le GAC :(
Dans mon cas, appelez simplement appelez ceci dans le constructeur de classe: puis avez cette méthode, avec toutes les DLL dont vous avez besoin: < Pré> xxx S'ils en sont beaucoup, vous voudrez peut-être refroidir avec une liste assembly.loadfile n'a pas fonctionné. Ce qui a eu lieu cette approche: