2011-11-01 4 views
20

J'ai déjà plongé dans la programmation SQL clr. Malheureusement, ma première tentative est troublée. Mon C# code assembleur est tellement:Impossible de CREER UN ASSEMBLAGE dans SQL

enter code here 
public partial class FirstCLRRoutines 
{ 
    public static int GetCLRFrameworkMajorVersion() 
    { 
     return System.Environment.Version.Major; 
    } 
} 

et le code SQL est:

USE master 
GO 
CREATE ASSEMBLY [Chapter2.FirstCLRRoutine] 
FROM 'D:\projeler\SQL_CLR\SQL_CLR\bin\Debug\SQL_CLR.dll' 

Mais je reçois ce message d'erreur de MSSMSE:

Msg 6218, Niveau 16, État 3, ligne 1
CREATE ASSEMBLY pour l'assembly 'SQL_CLR' a échoué car l'assembly 'SQL_CLR' a échoué à la vérification. Vérifiez si les assemblages référencés sont à jour et approuvés (pour external_access ou non sécurisé) pour exécuter la base de données . les messages d'erreur CLR Verifier si quelqu'un ne veut suivre ce message

Répondre

36

Je viens de rencontrer exactement le même problème.

Ceci est une ancienne page, mais d'abord, formost et enfin, la DLL doit être construit avec .NET 2.0. SqlServer 2005 est construit avec .net 2.0, parce que c'est le dernier disponible quand il a été écrit. SqlServer 2008 peut également avoir le même problème.

La DLL et le SqlServer doivent tous les deux faire référence à la même version .NET framekwork. Une fois que j'ai compris cela, j'ai créé un projet séparé sous 2.0 et shazam! travaillé parfait la première fois.

Pour voir quelle version de .net votre serveur SQL utilise:

select * from sys.dm_clr_properties 
+0

J'ai le même problème, mais cette fois, pour System.Xaml. Comment est-ce que j'ai résolu ceci? CREATE ASSEMBLY pour l'assembly 'System.Xaml' a échoué car l'assembly 'System.Xaml' a échoué à la vérification. Vérifiez si les assemblys référencés sont à jour et fiables (pour external_access ou dangereux) à exécuter dans la base de données. Messages d'erreur CLR Verifier, le cas échéant, suivront ce message [: System.Windows.Markup.ValueSerializer :: CanConvertToString] [mdToken = 0x6000002] [offset 0x00000000] La taille du code est zéro. –

+0

pas sûr de celui-là. On dirait que ça pourrait être le même problème. Y at-il un moyen de vérifier la version de .net votre System.Xaml a été construit sous? Si c'est différent, cela pourrait causer le problème. – horace

+1

Bien que cela fonctionne, l'explication n'est pas entièrement correcte. S'il vous plaît voir ma [réponse] (http://stackoverflow.com/a/32334611/577765) pour plus de détails (qui étaient trop pour mettre dans un commentaire). –

4
USE master 
GO 
CREATE ASSEMBLY [Chapter2.FirstCLRRoutine] 
FROM 'D:\projeler\SQL_CLR\SQL_CLR\bin\Debug\SQL_CLR.dll' 
WITH PERMISSION_SET = UNSAFE 

essayer, et laissez-moi savoir si cela fonctionne.

+0

Je l'ai essayé le mode "dangereux", aussi, ne fonctionne pas – Mesut

+0

FirstCLRRoutines de classe partielle publique { statique int GetCLRFrameworkMajorVersion public() { de retour 12; } – Mesut

+0

Cela n'était pas nécessaire pour le problème spécifique de l'OP, mais je devais le faire pour créer un autre assembly pour lequel SQL Server initialement signalé le même type d'erreur lorsque j'ai essayé de le créer avec WITH PERMISSION_SET = EXTERNAL_ACCESS . –

0

La bibliothèque, System.Environment, n'est pas pris en charge pour CLR: http://msdn.microsoft.com/en-us/library/ms403279.aspx

Vous pouvez toujours utiliser, comme indiqué dans la section « Bibliothèques non pris en charge » de l'article ci-dessus, mais gardez à l'esprit que le code n'a pas été testé pour la sécurité et la fiabilité. Cela peut entraîner des résultats imprévisibles dans un environnement de production, pensez donc aux risques et testez soigneusement avant de les déployer. En outre, je crois qu'il doit soit avoir un nom fort ou être déployé dans une base de données marquée comme "Trustworthy" avant qu'il ne s'exécute.

+0

Cela ne fonctionne pas et donne même message d'erreur ainsi: – Mesut

+0

FirstCLRRoutines classe partielle du public { statique int GetCLRFrameworkMajorVersion public() { retour 12; } } – Mesut

+0

Avez-vous essayé de déployer à partir de Visual Studio? – brian

7

La réponse acceptée, tout en semblant résoudre le problème de l'OP, est partiellement correcte et présente une explication trop simpliste du sous-jacent cause, ce qui pourrait conduire d'autres personnes ayant un problème similaire dans la mauvaise direction.

Le problème avec la réponse acceptée est une mauvaise compréhension de l'environnement .NET, et ce même malentendu peut également être vu dans la question elle-même. Au sein de .NET, le CLR et le Framework sont deux choses distinctes, chacune avec leurs propres versions.

Le CLR (Common Language Runtime) est ce qui exécute le code managé. Ce n'est pas mis à jour presque aussi souvent que le cadre. Le .NET Framework est une collection de bibliothèques qui fournissent les moyens d'interaction avec une version particulière du CLR.

Une version unique du CLR comporte généralement plusieurs versions du Framework avec lequel il fonctionne. Une version unique du Framework ne fonctionne cependant qu'avec une version spécifique du CLR. Par exemple, CLR version 2.0 fonctionne avec Framework version 2.0, 3.0 et 3.5, tandis que CLR version 4.0 fonctionne avec toutes les versions 4.x du .NET Framework (par exemple 4.0, 4.5, 4.5.1, 4.5.2, 4.6 , etc). Pour voir le graphique de la version CLR vers les relations de la version Framework, consultez la page MSDN pour .NET Framework Versions and Dependencies.

En ce qui concerne le code SQLCLR, SQL Server ne fonctionne qu'avec une seule version du CLR et la version spécifique dépend de la version de SQL Server. SQL Server 2005, 2008 et 2008 R2 fonctionnent uniquement avec CLR version 2. Puisque CLR version 2 fonctionne uniquement avec .NET Framework versions 2.0, 3.0 et 3.5, cela signifie que SQL Server 2005, 2008 et 2008 R2 fonctionnent uniquement avec. NET Framework versions 2.0, 3.0 et 3.5. Bien sûr, SQL Server 2005 incluait uniquement .NET Framework version 2.0, de sorte qu'il existe quelques bibliothèques plus récentes dans .NET Framework version 3.0 et 3.5 qui ne fonctionnent pas dans SQL Server 2005 sans les importer manuellement (par exemple, System.Core et System.Xml.Linq). Dans le même ordre d'idées, SQL Server 2012, 2014 et 2016 sont liés statiquement à CLR version 4, qui fonctionne avec .NET Framework versions 4.0, 4.5, 4.5.1, 4.5.2, 4.6.

En ce qui concerne les informations retournées à la fois System.Environment.Version (dans la question) et sys.dm_clr_properties.version (dans la réponse acceptée), ils signalent la CLR version pas Framework Version. Veillez donc à ne pas confondre ces deux choses rapportant 2.0 ou 4.0, ce qui signifie que vous ne pouvez utiliser que Framework version 2.0 ou 4.0. Heureusement, grâce à la rétrocompatibilité, le code compilé avec les versions de CLR 2 Framework (2.0, 3.0 et 3.5) fonctionnera sans avoir besoin d'être recompilé dans SQL Server 2012 et plus récent, même s'ils sont sur la version 4 de CLR. Donc, vous ne pouvez généralement pas vous tromper avec l'utilisation d'une version 2.0 de Framework Framework, mais vous pouvez très certainement utiliser les versions de Framework au-delà de 2.0.

Pour une analyse plus approfondie regard sur le développement de code SQLCLR, consultez l'article suivant (et la série en général), que j'ai écrit:

Stairway to SQLCLR Level 5: Development (Using .NET within SQL Server)

0

Réponse courte: ensemble la version Sql Server et .Net Framework version sur la propriété du projet.

Tout d'abord, vous devez cocher définir la propriété de votre projet. Dans la propriété de projet, définissez la version du serveur SQL que vous souhaitez créer CLR pour celui-ci. puis choisissez la version .Net Framework. Par exemple, si vous voulez créer CLR pour SQL Server 2008, vous devez définir .Net Framework à 3.5 et pour 2005 choisir .Net 2.0. J'espère que cette solution vous aidera.

Questions connexes