Ho una vasta libreria di funzioni C/C++, che deve essere chiamata da SQL Server 2008. Ho scritto una classe di adattatore C# che carica queste funzioni da Win32 DLL con DllImport e li espone al codice .Net. Funziona perfettamente nella maggior parte delle applicazioni .Net.
Ora, stavo cercando di utilizzare la stessa tecnica con SQL Server CLR. Creo un set di funzioni CLR e stored procedure, che chiamano la classe dell'adattatore. Ciò non funziona come un tentativo di caricare i risultati DLL non gestiti in System.BadImageFormatException.
È possibile eseguire questa operazione con stored procedure estese, ma tale metodo è deprecato e potrebbe essere sospeso in qualsiasi nuova versione di SQL Server.
Quale sarebbe il modo corretto di chiamare le funzioni non gestite dalla procedura memorizzata CLR? La mia ipotesi è che questo dovrebbe essere fatto fuori processo.Chiamare le funzioni DLL C/C++ non gestite da SQL Server 2008
che sto cercando di fare il mio proc chiamata di stored un servizio Web che espone queste funzioni. Sembra una buona idea, ma finora ho un problema nel distribuire l'assembly SQLCLR che effettua chiamate al servizio Web. Non riesco a caricare l'assemblaggio System.ServiceModel.dllversion=3.0.0.0, che dipende dalla versione di assemblaggio System.Web.dll2.0.0.0.
Caricamento System.Web assemblea mi dà il seguente errore:
Assembly 'System.Web' references assembly 'system.web, version=2.0.0.0, culture=neutral, publickeytoken=b03f5f7f11d50a3a.', which is not present in the current database. SQL Server attempted to locate and automatically load the referenced assembly from the same location where referring assembly came from, but that operation has failed (reason: version, culture or public key mismatch). Please load the referenced assembly into the current database and retry your request.
ho trovato la soluzione per il problema della distribuzione System.Web assemblaggio. Invece di distribuirlo da C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Web.dll, dovrebbe essere distribuito da C:\Windows\Microsoft.NET\Framework64\v2.0.50727\System.Web.dll. Quindi vengono implementati anche tutti gli altri assembly richiesti.
L'elenco dei gruppi in ordine di schieramento:
- C: \ Windows \ Microsoft.NET \ Framework \ v3.0 \ Windows Communication Foundation \ SMdiagnostics.dll
- C: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ System.Web.dll
- C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ System.Messaging.dll
- C: \ Programmi \ Assiemi di riferimento \ Microsoft \ Framework \ v3.0 \ System.IdentityModel.dll
- C: \ Programmi \ Assiemi di riferimento \ Microsoft \ Framework \ v3.0 \ System.IdentityModel.Selectors.dll
- C: \ Windows \ Microsoft.NET \ Framework \ v3.0 \ Windows Communication Foundation \ Microsoft.Transactions .Bridge.dll
Si sta tentando di caricare una DLL non gestita a 32 bit in un server a 64 bit? – GSerg
Come riferimento a lato, [questo può essere fatto out-of-process] (http://stackoverflow.com/questions/752357/sql-server-2008-how-crash-safe-is-a-clr-stored- procedure-that-loads-unmanaged-l), ma sono sicuro che non è un requisito. – GSerg
Beh, ho bisogno di farlo in ogni modo possibile. Sì, a 32 bit non gestito, credo che il server sia a 32 bit, ma su sistema operativo a 64 bit. Ho visto quel post. Stanno usando le stored procedure estese, che sono deprecate. – Ramzay