Ce que vous essayez de faire n'est pas pris en charge par l'hôte CLR de SQL Server. Le CLR dans SQL Server est très limité pour éviter de déstabiliser SQL Server car il fonctionne différemment des applications exécutées sur le système d'exploitation. Ainsi, il existe un ensemble très limité de DLL prises en charge (c'est-à-dire vérifiées pour fonctionner et garanties pour continuer à fonctionner pendant les mises à jour de .NET). WindowsBase n'en fait pas partie, vous devrez donc le charger manuellement en tant que UNSAFE dans SQL Server. Mais cela vous laisse avec soit le problème que vous avez rencontré de la version dans le changement GAC principal (les DLL communes entre le GAC et l'hôte CLR de SQL Server doivent être de la même version), ou pire, si la DLL devient "mixte" (à la fois du C++ non managé et du code managé) et n'est plus "pur". Dans ce cas, la nouvelle version ne se charge pas et l'ancienne version reçoit l'erreur "mauvaise version", vous avez donc du travail à faire.
Pour des informations plus détaillées, veuillez consulter les articles/la documentation suivants :
- SQL Server 2005 pris en charge .NET Framework Bibliothèques
- SQL Server 2008 / 2008 R2 / 2012 / 2014 Bibliothèques .NET Framework prises en charge
- Politique de prise en charge pour les assemblys .NET Framework non testés dans l'environnement hébergé par SQL Server CLR
- Message d'erreur lorsque vous exécutez une routine CLR ou utilisez un assembly dans SQL Server :"L'assembly dans le magasin hôte a une signature différente de l'assembly dans GAC. (Exception de HRESULT :0x80131050)"
Cet ensemble de liens est extrait de la section "Lectures supplémentaires" d'un article que j'ai écrit :Escalier vers SQLCLR Niveau 5 :Développement (Utilisation de .NET dans SQL Server) .
Pour plus d'informations sur l'utilisation de SQLCLR en général, veuillez visiter mon site :Info SQLCLR
