Déploiement automatisé de mixte SSIS / DLL solution

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 qui utilise la logique développée dans les bibliothèques de classes. Cette fonctionnalité doit rester distincte de l'package SSIS.

Parce que nous sommes à l'aide d'un package SSIS je comprends que la DLL compilée doivent être déployés pour le GAC, puis référencés de la tâche de script. Cependant, c'est la création d'un déploiement problème 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ées sur le GAC. Cependant cela rompt avec le package SSIS, car il va essayer d'accéder à la DLL est basé sur le numéro de version qu'ils ont été publiés pour la machine de développement consultatif gouvernemental (GAC).

La seule solution que nous avons pour cela est d'obtenir la DLL compilée, la main de modifier le package SSIS tâche de script, puis de publier le package.

Il semble qu'il doit y avoir une meilleure façon de le faire - quelqu'un a rencontré ce problème et de trouver une meilleure solution? Ou est-il quelque chose de fondamental dans notre approche, nous avons besoin de changer (au-delà de l'élimination de la nécessité pour les DLL)?

Merci!

OriginalL'auteur Chris | 2009-12-07

8

Bien, après beaucoup de recherches, je n'ai jamais vraiment venu avec une solution satisfaisante pour cela. En fin de compte le plus proche que je pouvais faire était une solution où j'ai chargé mes références dynamiquement:
```
    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)
```
Cela m'a permis de créer l'objet que j'nécessaire (bien qu'intéressant de noter que de toute autre personne à charge, les références doivent également en charge dynamique ou d'une partie de la GAC, bien qu'au moins sans la dépendance sur le numéro de version).

Posté ici pour les futurs demandeurs d', mais si quelqu'un arrive avec quelque chose de mieux, je serais toujours très curieux de savoir comment vous l'avez résolu post ici et j'ai un crédit de la réponse 🙂

OriginalL'auteur Chris

Dans mon cas, il suffit d'appeler Assembly.LoadFile n'a pas fonctionné. Ce n'travail a été cette approche:

Chez le constructeur de la classe:

AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve);

Et alors cette méthode, avec toutes les dll que vous avez besoin:

 private Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
 {
     if (args.Name.Contains("libName.dll"))
         return Assembly.LoadFile(System.IO.Path.Combine(_libraryFolder, "libName.dll"));

     if (args.Name.Contains("libName2.dll"))
         return Assembly.LoadFile(System.IO.Path.Combine(_libraryFolder, "libName2.dll"));

     return null;
 }

Si ils sont beaucoup, vous pouvez refactoriser qu'avec un List<string>.

OriginalL'auteur Andrew

1

J'ai remarqué le même problème avec notre SSIS/C# mélanger. Nous nous appuyons également sur un externe (SSIS) dll. Dans notre cas, la DLL a dû être copié à l'100/DTS/Binn pour permettre le package SSIS de travailler à partir de Visual Studio, cependant lorsque l'on tente d'exécuter le package à l'aide de SQL Package Utilitaire d'Exécution, on obtient une erreur à l'effet que le fichier n'a pas pu être trouvé. Il ne semble pas indiquer une version de question qu'il y a autant de différence dans le CHEMIN entre Visual Studio et l'Exécution du Package Utilitaire. Même à l'exécution du package sans débogage de Visual Studio fonctionne. Je vais regarder dans la version en question pour voir si peut-être que c'est la base de la plainte sur notre système, mais de mémoire je crois que c'est un fichier non trouvé erreur de type qui nous touchent. Nous sommes à l'aide de MSSQL 2008 si cela fait une différence.

En réponse, j'ai été en mesure d'exécuter le package avec succès par la copie de la DLL pour les machines hôtes windows\assembly répertoire. Apparemment, c'est l'insaisissable GAC emplacement? De toute façon notre mécanisme de déploiement n'est pas si automatisé encore peut-être que c'est pourquoi nous sommes, de ne pas avoir de problèmes de version. Une fois que j'ai copier la dll dans le windows\assembly dir le package s'exécute à la fin.
Salut Travis - oui, c'est l'emplacement de la GAC, pas sûr que les restrictions sur SQL 2008, mais si ça aide, je peux vous confirmer que dans un serveur déployé sur SQL 2005 la DLL doit être déployé pour le GAC 🙁

OriginalL'auteur Travis
0

Êtes-vous absolument sûr que ces Dll partagées doit être déployé à la GAC? Si ils sont dans le même dossier que le package SSIS, ils devraient être détectables par le cadre, sans la nécessité pour les ajouter à la GAC.

Est-il pas de mise à jour de 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 la version incrément, l'autre alternative est de construire une politique de fichier avec l'partagé assemblées et de l'utiliser pour "rediriger" le package SSIS pour la nouvelle version avec chaque version.

Les renseignements que j'ai, c'est que les packages SSIS doit être déployé pour le GAC, excellent si ce n'est - mais êtes-vous sûr? developerdotstar.com/community/node/333 numéro de Build - je suppose que nous pourrions, mais cette idée me fait un peu mal à l'aise. Je n'ai pas utilisé les fichiers de Stratégie avant, je vais aller y jeter un oeil, merci
Je n'ai pas essayé un package SSIS avec dépendances externes, donc je ne suis pas sûr. Devrait être assez facile de construire une maquette de votre colis avec la dépendance et de faire un rapide test de fumée...
Salut Dave - j'ai étudié la politique de fichiers tels qu'ils se rapportent à la SSIS de solutions, je ne vois pas vraiment comment je pourrais aller sur l'introduction de l'un sans créer également une autre dépendance. J'ai peut-être raté quelque chose, mais si vous avez des informations supplémentaires sur la façon dont ils peuvent être utilisés avec des packages SSIS il serait bien apprécié!
Oui, nous avons essayé le test de détection de fumée sans l'aide de la GAC, les approches que nous avons pris a échoué. La seule autre chose que l'on pourrait penser a l'aide de la réflexion pour charger dynamiquement la classe à partir d'un fichier de localisation, mais qui semble aussi à l'extrême, une façon de contourner ce problème

OriginalL'auteur Dave Swersky

Vous devez vous connecter pour publier un commentaire.