cela a fonctionné pour moi:

EXEC sp_changedbowner 'sa'
ALTER DATABASE [dbase] SET trustworthy ON

et j'ai aussi fait ceci:

sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO

sp_configure 'clr enabled', 1;
GO
RECONFIGURE;
GO

sp_configure 'show advanced options', 0;
GO
RECONFIGURE;
GO

s'il vous Plaît pas set TRUSTWORTHY ON sauf si c'est absolument nécessaire! Et cela ne devrait être "nécessaire" que lors du chargement d'un assemblage que vous n'avez pas construit et que vous ne pouvez pas résigner. Et cela se produit surtout lors du chargement de bibliothèques .net Framework qui ne sont pas "supportées" et donc pas déjà dans L'hôte CLR de SQL Server. En dehors de ces circonstances, vous ne devriez pas configurer la base de données à TRUSTWORTHY ON car elle ouvre un trou de sécurité.

à la place, il est beaucoup mieux de faire ce qui suit:

USE [master];

CREATE ASYMMETRIC KEY [SomeKey]
  AUTHORIZATION [dbo]
  FROM EXECUTABLE FILE = 'C:\path\to\Some.dll';

CREATE LOGIN [SomeLogin]
  FROM ASYMMETRIC KEY [SomeKey];

GRANT EXTERNAL ACCESS ASSEMBLY TO [SomeLogin]; -- or "UNSAFE" instead of "EXTERNAL ACCESS"

ce qui précède ne doit être fait qu'une fois par Instance, par clé. Ainsi, si vous utilisez le même fichier snk / pfx pour tous vos assemblages, alors les étapes indiquées ci-dessus ne doivent être effectuées qu'une fois par Instance SQL Server; le nombre d'assemblages et de bases de données contenant ces assemblages n'a pas d'importance.

cette approche vous permet de garder une meilleure sécurité sur la base de données (en gardant TRUSTWORTHY mis à OFF ) et permet une commande plus granulaire de quels assemblages sont même autorisés à être réglé à EXTERNAL_ACCESS et / ou UNSAFE (puisque vous pouvez séparer en utilisant différentes clés pour la signature et Logins basés sur ces différentes clés).

cependant, si vous doit utiliser la méthode TRUSTWORTHY ON , alors le propriétaire de la base de données n'a pas besoin d'être sa . L'exigence est simplement que la Connexion enregistrée dans la base de données le propriétaire a obtenu soit EXTERNAL ACCESS ASSEMBLY ou UNSAFE ASSEMBLY (les deux mêmes permissions indiquées ci-dessus pour la connexion asymétrique basée sur la clé).

pour une visite plus détaillée des options de sécurité, s'il vous plaît voir l'article suivant que j'ai écrit sur SQL Server Central: escalier à SQLCLR Niveau 4: Sécurité (externe et assemblages dangereux) (inscription gratuite est requise).

visite de la façon d'automatiser cela via Visual Studio / SSDT, s'il vous plaît voir les 3 articles suivants( une série de 3 parties), également sur SQL Server Central:

• Stairway to SQLCLR Level 6: Development Tools Intro
• Stairway to SQLCLR Niveau 7: le Développement et la Sécurité
• Stairway to SQLCLR Level 8: Using Visual Studio to work around SSDT

de plus, depuis que j'ai écrit ces 3 articles, j'ai trouvé une méthode plus facile en utilisant des modèles T4, mais je n'ai pas encore eu le temps de l'écrire. Quand je le ferai, je mettrai à jour cette réponse avec un lien vers cet article.

UPDATE

SQL Server 2017 a introduit une nouvelle complication sous la forme d'une option de configuration au niveau du serveur nommée "CLR strict security". Il est activé par défaut et nécessite que tous Les assemblages, même ceux marqués comme SAFE , être signé avec un certificat ou clé asymétrique, ont le Login associé, et que le Login a la UNSAFE ASSEMBLY permission accordée (pas assez bon pour accorder EXTERNAL ACCESS ASSEMBLY ). Voir ma réponse à la question suivante pour plus de détails sur cette nouvelle "caractéristique":

CLR Strict Security on SQL Server 2017

code suivant travaillé pour moi pour la sécurité intégrée:

ALTER DATABASE dtabasename SET TRUSTWORTHY ON;
GO

ALTER AUTHORIZATION ON DATABASE::dtabasename TO [DOMAIN\UserName]
GO

C'est ainsi que j'ai réussi à le faire fonctionner:

ALTER DATABASE databasename SET trustworthy ON

sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO

sp_configure 'clr enabled', 1;
GO
RECONFIGURE;
GO

sp_configure 'show advanced options', 0;
GO
RECONFIGURE;
GO

/
DROP ASSEMBLY assemblyname

GO


CREATE ASSEMBLY assemblyname
FROM 0x4D5A9000.....
WITH PERMISSION_SET = EXTERNAL_ACCESS

Cela fonctionne pour:

• Visual Studio 2015 Update 2.
• Visual Studio 2017.

dans les paramètres de votre projet, sélectionnez "Accès externe":

sur publish, le message d'erreur dit qu'il ne peut pas accepter "EXTERNAL_ACCESS" à moins que l'assemblée soit réglée à "Trustworthy".

ainsi, dans les paramètres du projet, placer l'assemblée à" digne de confiance":

cela signifiait que j'étais capable d'exécuter une fonction définie par l'utilisateur qui énumérait des fichiers sur le disque dur local .

si la garantie est encore trop restrictive, ajoutez l'attribut DataAccess = DataAccessKind.Read à votre UDF, par exemple:

[Microsoft.SqlServer.Server.SqlFunction(FillRowMethodName = "FindFiles", DataAccess = DataAccessKind.Read, TableDefinition = "FileName nvarchar(500), FileSize bigint, CreationTime datetime")]

mise à jour 2017-07-02

sur SQL Server 2016 + Visual Studio 2015 , vous pourriez aussi avoir à faire ce qui suit:

• use master;grant unsafe assembly to [Domain\Username];
• exécute n'importe quel programme (tel que Visual Studio ou n'importe quel utilitaire C#) en mode Administrator pour leur donner des permissions suffisantes pour publier des assemblages UNSAFE .

si rien ne fonctionne, essayez de vous connecter en utilisant le nom d'utilisateur sa et votre mot de passe administrateur. Ce fonctionne toujours, que Visual Studio soit exécuté en mode Administrator ou non.

cette seule ligne résout le problème pour moi

use master;
grant external access assembly to [domain\username]