Ответ 1

Вы должны установить эти параметры в файле проекта! Когда вы щелкните правой кнопкой мыши на своем проекте, нажмите "Параметры базы данных" в конфигурации проекта и выберите вкладку "Разное". Вы должны увидеть нечто похожее на то, что у меня есть:

Это тот же вопрос, что и: Ошибка при запуске CLR Stored Proc

Ответ 2

Это сработало для меня:

EXEC sp_changedbowner 'sa'
ALTER DATABASE [dbase] 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

Ответ 3

Не устанавливайте TRUSTWORTHY ON, если это абсолютно необходимо! И это должно быть "необходимо" при загрузке сборки, которую вы не строили, и не можете повторно подписывать. И это происходит в основном при загрузке библиотек .NET Framework, которые не поддерживаются и, следовательно, еще не находятся в узле CLR SQL Server. Вне этих обстоятельств вы не должны устанавливать базу данных на TRUSTWORTHY ON, поскольку она открывает отверстие для безопасности.

Вместо этого гораздо лучше сделать следующее:

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"

Вышеизложенное нужно выполнить только один раз за экземпляр, за ключ. Поэтому, если вы используете один и тот же файл snk/pfx для всех своих сборок, то приведенные выше шаги должны выполняться только один раз на экземпляр SQL Server; количество Ассамблей и баз данных, содержащих эти сборки, не имеет значения.

Этот подход позволяет сохранять лучшую безопасность в базе данных (сохраняя TRUSTWORTHY на OFF) и позволяя более детально контролировать, какие сборки даже разрешено устанавливать на EXTERNAL_ACCESS и/или UNSAFE (поскольку вы можете разделить с помощью разных ключей для подписания и входа на основе этих разных ключей).

Однако, если вы должны использовать метод TRUSTWORTHY ON, то владельцу базы данных не нужно быть sa. Требование состоит лишь в том, что Login, зарегистрированный как владелец базы данных, был предоставлен либо EXTERNAL ACCESS ASSEMBLY, либо UNSAFE ASSEMBLY (те же два разрешения, которые были указаны выше для входа в асимметричный ключ).

Для более подробного ознакомления с параметрами безопасности см. следующую статью, которую я написал в SQL Server Central: Stairway to SQLCLR Level 4: Безопасность (ВНЕШНИЕ И НЕСОВЕРШЕННЫЕ АСПЕКТЫ) (требуется бесплатная регистрация).

Подробную информацию о том, как автоматизировать это с помощью Visual Studio/SSDT, можно найти в следующих трех статьях (серия из трех частей), а также в SQL Server Central:

• Лестница в SQLCLR Уровень 6: Средства разработки Intro
• Лестница в SQLCLR Уровень 7: Разработка и безопасность
• Лестница в SQLCLR Уровень 8: Использование Visual Studio для работы с SSDT

Кроме того, начиная с написания этих трех статей, я придумал более простой метод с использованием шаблонов T4, но еще не успел написать это. Когда я это сделаю, я обновлю этот ответ ссылкой на эту статью.

UPDATE

В SQL Server 2017 появилось новое осложнение в виде опции конфигурации на уровне сервера с надписью "CLR strict security". Он включен по умолчанию и требует, чтобы ВСЕ АССИСТИКИ, даже те, что помечены как SAFE, были подписаны с сертификатом или асимметричным ключом, имели связанный Логин и что у входа есть разрешение UNSAFE ASSEMBLY (недостаточно для предоставления EXTERNAL ACCESS ASSEMBLY). Пожалуйста, см. Мой ответ на следующий S.O. вопрос для получения дополнительной информации об этой новой "функции":

CLR Strict Security на SQL Server 2017

Ответ 4

Следующий код работал у меня для интегрированной безопасности:

ALTER DATABASE dtabasename SET TRUSTWORTHY ON;
GO

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

Ответ 5

Вот как мне удалось заставить его работать:

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

Ответ 6

Это работает для обновления Visual Studio 2015 Update 2.

В настройках вашего проекта выберите "Внешний доступ":

При публикации сообщения об ошибке сообщают, что он не может принять "EXTERNAL_ACCESS", если сборка не установлена ​​на "Trustworthy".

Итак, в настройках проекта установите для сборки значение "Trustworthy":

Это означало, что я смог запустить образцовую пользовательскую функцию, которая перечисляла файлы на локальном жестком диске.

Если защита по-прежнему слишком ограничительна, добавьте атрибут DataAccess = DataAccessKind.Read в ваш UDF, например:

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

Обновление 2017-07-02

В SQL Server 2016 + Visual Studio 2015 вам также может потребоваться следующее:

• use master;grant unsafe assembly to [Domain\Username];
• Запустите любые программы (например, Visual Studio или любые утилиты С#) в режиме Administrator, чтобы предоставить им достаточные разрешения для публикации ассемблеров UNSAFE.

Если ничего не работает, попробуйте подключиться с помощью имени пользователя sa и пароля администратора. Это всегда будет работать независимо от того, выполняется ли Visual Studio в режиме Administrator или нет.

Ответ 7

эта единственная строка решает проблему для меня

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