Pourquoi SQL Server n'inscrit-il pas mon assembly en tant que SAFE?

Sur SQL Server 2008, j'essaie d'enregistrer un assembly qui semble référencer uniquement le supported libraries. Voici le code T-SQL que j'utilise pour enregistrer l'assemblée:Pourquoi SQL Server n'inscrit-il pas mon assembly en tant que SAFE?

create assembly MySpatial from 'c:\Spatial.dll'

Il en résulte l'erreur suivante:

Msg 6509, Level 16, State 31, Line 1 An error occurred while gathering metadata from assembly 'Spatial' with HRESULT 0x80004005.

Cependant, si j'ajoute with permission_set=unsafe, puis SQL exécutera la commande avec succès. Comment puis-je savoir pourquoi l'erreur s'est produite ou pourquoi mon assembly doit être enregistré comme non sécurisé?

Source

2009-10-29 Holistic Developer

J'ai le même problème avec mon assemblage. Il n'y a pas de champs/propriétés statiques non-'readonly' et il ne fait référence qu'aux safe mscorlib.dll et' System.dll', tous deux v2. J'ai essayé de copier une partie limitée des classes dans un fichier séparé et de compiler, ce qui fonctionne, donc il y a quelque chose de spécifique qui empêche d'être accepté comme sûr. –

J'ai trouvé le problème avec mon assembly, il a quelques expressions lambda dans une méthode 'GetEnumerator()', donc je les ai convertis en méthodes régulières + 'new Func <>' (les convertir en méthodes anonymes n'a pas aidé) . Cela m'a permis d'ajouter l'assembly à SQL Server sans obtenir l'erreur. Je ne sais toujours pas exactement pourquoi ces expressions lambda ont causé cela (ils pourraient compiler et fonctionner correctement en dehors de SQL Server). –

Lorsque l'ensemble de persistance est dangereux, SQL ne vérifie pas les métadonnées de votre assembly. Essayez d'appliquer le correctif à partir de KB 941256 ou d'appliquer CU4 for SP2.

Altough est un HRESULT différent que le E_FAIL que vous obtenez, peut-être que le correctif résout le problème.

Source

2009-10-29 22:43:30

Bien sûr, je comprends que lorsque les autorisations sont définies sur non sécurisées que SQL va simplement laisser passer. Cependant, j'essaie de savoir ce qui est à propos de mon assemblage qui n'est pas considéré comme sûr? En outre, les liens que vous avez fournis s'appliquent uniquement à SQL Server 2005, pas 2008. –

Je suis tombé sur la même chose, et après quelques recherches, je pense que c'est à cause de l'optimisation que le compilateur fait sur les expressions lambda. Il y a une surcharge dans la création d'un délégué d'une expression lambda. Je pense qu'il faut paresseux initialiser un champ statique caché contenant le délégué la première fois que le lambda est accédé afin qu'il puisse réutiliser le délégué déjà construit dans les futurs appels.

La raison pour laquelle je pense que c'est parce que si le lambda capture des variables, cela ne cause pas le problème de SAFE. Il serait logique que si vous capturez des variables, vous devrez créer un délégué différent à chaque fois que vous l'appelez, mais si le lambda est complètement autonome, il pourrait le mettre en cache à des fins d'efficacité. Microsoft a corrigé le problème dans SQL 2008, mais ne le corrigera pas dans SQL 2005, donc s'il est nécessaire de prendre en charge les installations SQL 2005 existantes, tout ce dont il a besoin est d'éliminer les lambda "statiquement optimisables". lambdas dans l'ensemble.

Source

2013-06-18 15:55:01

Pourquoi SQL Server n'inscrit-il pas mon assembly en tant que SAFE?

Répondre

Questions connexes