Despliegue automatizado de la solución mixta SSIS/DLL

Question

Actualmente tenemos una solución desarrollada utilizando SSIS/C#. El paquete SSIS (entre otras cosas) tiene una tarea de script que usa lógica desarrollada en las bibliotecas de clase. Esta funcionalidad debe permanecer separada del paquete SSIS.

Debido a que estamos utilizando un paquete de SSIS, entiendo que las DLL compiladas deben implementarse en el GAC y, a continuación, hacer referencia a ellas desde la tarea de secuencia de comandos. Sin embargo, esto está creando un problema de implementación para nosotros.

Nuestra herramienta de implementación automatizada (correctamente) aumenta automáticamente los números de versión de las DLL, que luego se publican en el GAC. Sin embargo, esto rompe el paquete de SSIS, ya que tratará de acceder a las DLL en función del número de versión en que se publicaron en la máquina de desarrollo GAC.

La única solución que tenemos para esto es obtener las DLL compiladas, modificar manualmente la tarea del script del paquete SSIS y luego publicar el paquete.

Parece que debe haber una forma mejor de hacerlo: ¿alguien ha encontrado este problema y ha encontrado una solución mejor? ¿O hay algo fundamental en nuestro enfoque que necesitamos cambiar (más allá de eliminar la necesidad de los DLL)?

Gracias!

Answer 1

Bueno, después de mucha investigación nunca encontré una solución satisfactoria para esto. Al final, el más cercano que pudimos conseguir fue una solución en la que he cargado mis referencias de forma dinámica:

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) 

Esto me permitió crear el objeto que requería (aunque cabe destacar que las demás referencias dependientes también necesitan por dinámicamente cargar o parte del GAC, aunque al menos sin la dependencia del número de versión).

publicado aquí por los solicitantes futuros, pero si alguien se le ocurre algo mejor todavía sería muy curioso saber cómo resolviste - post aquí y te daremos un crédito con la respuesta :)

Answer 2

¿Está absolutamente seguro de que esas DLL compartidas deben estar implementadas en el GAC? Si están en la misma carpeta que el paquete SSIS, deben ser detectables por el framework sin la necesidad de agregarlos al GAC.

¿No hay forma de que actualices tu sistema de compilación para evitar el cambio del número de versión? Si el código de esos conjuntos no cambia, no es necesario actualizar el número de versión.

Si no puede evitar el incremento de versión, la otra alternativa es crear un archivo de política junto con los ensamblados compartidos y usarlo para "redirigir" el paquete SSIS a la nueva versión con cada compilación.

Answer 3

he notado problemas similares con nuestra mezcla de SSIS/C#. También dependemos de un dll externo (a SSIS). En nuestro caso, el archivo DLL tuvo que copiarse en el directorio 100/DTS/Binn para permitir que el paquete SSIS funcione desde Visual Studio; sin embargo, cuando intentamos ejecutar el paquete utilizando SQL Package Execution Utility obtenemos un error del efecto que el archivo no pudo ser encontrado No parece indicar un problema de versión tanto como una diferencia en PATH entre Visual Studio y Package Execution Utility. Incluso funciona el paquete sin depurar desde Visual Studio. Voy a analizar el problema de la versión para ver si tal vez esa es la queja principal en nuestro sistema, pero de memoria creo que fue un error de tipo archivo no encontrado que nos afectó. Estamos usando MSSQL 2008 si eso hace la diferencia.