Implementazione automatica di una soluzione mista SSIS/DLL

Question

Attualmente abbiamo una soluzione sviluppata utilizzando SSIS/C#. Il pacchetto SSIS (tra le altre cose) ha un'attività di script che utilizza la logica sviluppata nelle librerie di classi. Questa funzionalità deve rimanere separata dal pacchetto SSIS.

Poiché stiamo utilizzando un pacchetto SSIS, capisco che le DLL compilate devono essere distribuite nel GAC e quindi referenziate dall'attività di script. Tuttavia questo sta creando un problema di distribuzione per noi.

Il nostro strumento di distribuzione automatizzata (giustamente) incrementa automaticamente i numeri di versione delle DLL, che vengono quindi pubblicati nel GAC. Tuttavia questo rompe il pacchetto SSIS, poiché proverà ad accedere alle DLL in base al numero di versione che sono state pubblicate nel computer di sviluppo GAC come.

L'unica soluzione a nostra disposizione è ottenere le DLL compilate, modificare manualmente l'attività di script del pacchetto SSIS e quindi pubblicare il pacchetto.

Sembra che ci sia un modo migliore per farlo: qualcuno ha riscontrato questo problema e ha trovato una soluzione migliore? O c'è qualcosa di fondamentale nel nostro approccio che dobbiamo cambiare (oltre a eliminare la necessità delle DLL)?

Grazie!

Answer 1

Bene, dopo molte ricerche non ho mai trovato una soluzione soddisfacente per questo. Alla fine il più vicino ho potuto ottenere era una soluzione in cui ho caricato i miei riferimenti in modo dinamico:

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) 

Questo mi ha permesso di creare l'oggetto che ho richiesto (anche se la pena di notare che eventuali altri riferimenti dipendenti devono anche da caricare dinamicamente o parte del GAC, anche se almeno senza la dipendenza dal numero di versione).

postato qui per i cercatori di futuro, ma se qualcuno esce con qualcosa di meglio mi sarebbe ancora molto curioso di sapere come si è risolto - post qui e io vi accrediterà con la risposta :)

Answer 2

Sei assolutamente sicuro che quelle DLL condivise devono essere distribuite al GAC? Se si trovano nella stessa cartella del pacchetto SSIS, dovrebbero essere rilevabili dal framework senza la necessità di aggiungerli al GAC.

Non è possibile aggiornare il sistema di generazione per evitare il cambio del numero di versione? Se il codice di questi assembly non cambia, non è necessario aggiornare il numero di versione.

Se non è possibile evitare l'incremento della versione, l'altra alternativa è creare un file di criteri insieme agli assembly condivisi e utilizzarlo per "reindirizzare" il pacchetto SSIS alla nuova versione con ogni generazione.

Answer 3

ho notato problemi simili con il nostro mix SSIS/C#. Ci affidiamo anche a una dll esterna (a SSIS). Nel nostro caso la DLL doveva essere copiata nella directory 100/DTS/Binn per consentire al pacchetto SSIS di funzionare da Visual Studio, tuttavia quando tentiamo di eseguire il pacchetto utilizzando l'utilità di esecuzione pacchetto SQL otteniamo un errore sull'effetto che il file non è stato trovato. Non sembra indicare un problema di versione tanto quanto una differenza di PERCORSO tra Visual Studio e Package Execution Utility. Anche l'esecuzione del pacchetto senza debug da Visual Studio funziona. Ho intenzione di esaminare il problema della versione per vedere se forse questo è il problema principale del nostro sistema, ma dalla memoria penso che sia stato un errore di tipo file non trovato che ci ha colpito. Stiamo utilizzando MSSQL 2008 se questo fa la differenza.