Je travaille avec du code SQL 2005 CLR écrit en C#. Nous avons récemment modifié quelques-unes des fonctions pour autoriser les paramètres NULL. Nous l'avons fait en changeant les paramètres des types 'double' en 'SqlDecimal'. Nous avons testé avec succès les changements dans le développement et déplacé pour déployer les mises à jour sur le serveur de production. Nous utilisons un script SQL pour supprimer le code existant du serveur et créer ensuite l'assembly mis à jour et les objets associés. Le script SQL que nous avons utilisé dans le développement et le test a été déployé sur le serveur de production sans changement, mais quand nous courons là nous voyons une erreur:Pourquoi CREATE ASSEMBLY échoue-t-il avec l'erreur 'Impossible de résoudre le jeton'?
Creating CLR assemblies
Msg 6218, Level 16, State 2, Line 2
CREATE ASSEMBLY for assembly 'Company.Db.CLRStoredProcedures' failed because assembly 'Company.Db.CLRStoredProcedures' failed verification. Check if the referenced assemblies are up-to-date and trusted (for external_access or unsafe) to execute in the database. CLR Verifier error messages if any will follow this message
[ : StoredProcedures::clrproc_OSGBtoWGS84][mdToken=0x600002e][offset 0x0000002C] Unable to resolve token.
Je googled cette erreur, mais ne semblent trouver quelque chose de sensible. Dans les changements que nous avons faits, il n'y avait pas de références nouvelles ou modifiées et donc je ne crois pas que ce soit lié à quelque chose qui manque sur le serveur, le code a déjà travaillé là-bas pendant un certain temps. Est-ce que quelqu'un sait ce qui se passe ici?
Impossible de résoudre le jeton, ce qui signifie qu'il ne peut pas trouver de métadonnées. Je ne peux pas vous donner plus d'informations cependant, je débogue un problème similaire moi-même. –
Je doute fortement qu'il y avait une différence dans le script et ce que vous avez capturé. Vous ne spécifiez pas non plus la version de Visual Studio que vous utilisez, et les moyens de déploiement/publication ont été modifiés plusieurs fois. Donc, pour vraiment comprendre cela, nous aurions besoin de voir le script de déploiement que vous utilisiez qui recevait l'erreur, ainsi que le script qui fonctionnait. Sinon, il n'y a pas assez d'informations ici pour continuer. –
Cette question date de 5 ans et il en va de même pour mes archives techniques! Étant donné le temps qui s'est écoulé, je ne peux pas fournir de renseignements supplémentaires maintenant. – Elliveny