L'appel qui utilise une DLL avec SQL Server Agent requiert l'installation de la DLL sur l'ordinateur appelant et non sur l'ordinateur sur lequel le package est installé.

Question

Nous avons un package SSIS 2005 installé sur un serveur central et appelé à partir de plusieurs emplacements. Ce package utilise une tâche de script pour appeler une DLL .NET que j'ai écrite en C# et installée dans le GAC sur le serveur central. Lorsque j'appelle le package SSIS à partir du serveur sur lequel le package est installé, tout va bien.

Lorsque j'appelle le package à partir d'un serveur distant à l'aide de SQL Server Agent, le travail échoue indiquant qu'il ne peut pas trouver la DLL.

Juste pour tester ce qui se passe, j'ai installé la DLL sur le serveur distant et le package a réussi. Il semble donc que même si le paquet est installé sur une machine, quand il est appelé par un autre utilisant SQL Server agend, il s'exécute sur la machine appelante et c'est la machine appelante qui doit satisfaire toutes les dépendances.

Ce paquet va être appelé à partir de dizaines de serveurs, dont je n'ai pas le contrôle.

Existe-t-il un moyen pour installer, configurer, compiler, appeler ou faire quelque chose à la façon dont ce paquet est construit ou exécuté pour qu'il appelle la DLL du GAC sur la machine où le paquet est installée?

Answer 1

Malheureusement, vous aurez besoin de changer votre conception, car le stockage de paquets SSIS n'est que du stockage. L'exécution a toujours lieu sur la machine à partir de laquelle le paquet est appelé, et toutes les références sont traitées par rapport à cette machine.

Une option consiste à ajouter une tâche au package SSIS qui copie et enregistre la DLL dans le GAC de la machine appelante - mais si vous n'avez pas le contrôle sur certaines machines exécutantes, il n'y a aucune garantie de l'exécution SQL Le compte de l'agent aura les droits suffisants pour enregistrer une DLL.

Une autre solution consisterait à convertir le code DLL en une tâche de script dans le package SSIS. Cela signifierait convertir le code de C# en VB, et pourrait être non trivial selon le détail de votre code. Sans plus de détails sur l'objectif du package et les fonctionnalités de la DLL, il est difficile d'évaluer d'autres alternatives, mais vous pouvez envisager s'il est possible de paramétrer le package pour qu'il s'exécute toujours depuis le serveur de stockage.