Я использую EF.6 code-first, и моя задача - загрузить внешнюю библиотеку для SQL Server (Assembly). Сборка предоставляется в виде SQL-скрипта с двоичным кодом, например:
CREATE ASSEMBLY [assembyName]
FROM
0x4D5A90000300000004000000FFFF0000B800000000000000400000000000000000000000000000000000000000000000000000000000000000000000800000000E1FBA0E00B409CD21B8014CCD21546869732070726F6772616D2063616E6E6F742062652072756E20696E20444F53206D6F64652E0D0D0A2400000000000000504500004C010300675910540000000000000000E00002210B010B000028000000060000000000005E46000000200000006000000000001000200000000200000400000000000000040000000000000000A0000000020000000000000300408500001000001000000000100000100000000000001000000000000000000000000C4600004F000000006000002003000000000000000000000000000000000000008000000C000000D44400001C000000000000000000000000000000000000....
И сборка создается правильно, если я выполняю сценарий из Management Studio.
Итак, мой вопрос ... Есть ли способ сделать это в качестве хорошей практики или мне следует прочитать файл и использовать Database.SqlQuery<string>
, которого я хочу избежать? Надеюсь, есть еще одна хорошая практика.
Очень необычно использовать SQL CLR в рабочем процессе, ориентированном на код. Вы действительно хотите управлять этой схемой базы данных посредством миграций? Вы можете использовать SSMS или SSDT для управления схемой базы данных и по-прежнему использовать классы и сопоставления с первым кодом в EF.
Если вы сделал действительно хотите сделать это в своих миграциях, сохранение файлов сценария TSQL и их чтение при применении миграции кажется разумным подходом. Почему вы хотите этого избежать?
Другой способ справиться с этим - добавить в проект сборку SQLCLR, а затем при миграции сериализовать файл сборки в шестнадцатеричную строку или загрузить биты в параметр varbinary (max).
Хорошо, я только что экспортировал сборку в файл сценария .sql create и включил его в свой проект .NET. Это помогает использовать метод SqlFile (filePath) в миграциях EF для создания сборки. Спасибо Дэвиду Брауну за ответ.
Что ж, я действительно хочу избежать этого, если есть более разумный способ сделать это с помощью EF. Но, похоже, я продолжу в этом направлении. Дело в том, что мы используем ручные миграции, и я хочу, чтобы эта сборка была частью рабочего процесса, ориентированного на код, чтобы избежать обслуживания базы данных вручную и необходимости установки сборки. Я полностью понимаю, что использование SQL CLR с рабочим процессом, ориентированным на код это плохая идея, и я объяснил это владельцу проекта, но это было окончательным решением. Спасибо за быстрый ответ.