Двоичный файл сборки хранится в базе данных как большой двоичный объект, поэтому он переносится куда угодно. CLR включается только для экземпляра - для этого нет настроек, специфичных для базы данных.
В любом случае, почему вы пытаетесь это сделать?
(Я не пытаюсь спорить; я просто хочу услышать мотивы, связанные с этим, потому что, возможно, проблему можно решить другим способом, отвечающим вашим потребностям.)
Нет никакого способа сделать это легко, кроме как поместить сборку в общую базу данных.
Тем не менее, я думаю, что было бы выгодно использовать архитектуру, ориентированную на базы данных, если только в конкретной ситуации нет веских причин для централизации. Причина в том, что размещение сборки (или чего-либо в этом роде) вне базы данных создает зависимость в вашей среде. Это как раз противоположный подход, к которому Microsoft прибегает с помощью автономных баз данных, начиная с SQL Server 2012.
Когда вы начинаете нуждаться в использовании таких функций, как репликация или кластеризация, эта зависимость потенциально может значительно усложнить развертывание, а также устранение неполадок и процедуры восстановления после отказа.
Эта архитектура гораздо менее очевидна для людей, незнакомых с системой (т. Е. Она менее самообнаруживаема и менее самодокументирована).
Если вам в конечном итоге потребуется разная защита в разных базах данных или что-то, что связано с вариациями, вы окажетесь в мире боли.
Если эти базы данных будут развернуты для клиентов (звучит так, как будто они не будут, но я скажу это для полноты), это усложнит процедуру развертывания, обслуживания и устранения неполадок.
Поскольку все базы данных будут совместно использовать этот код, если какие-либо ошибки будут введены (или исправлены!), Это может потенциально сломать все приложения, которые полагаются на базы данных. Комплексное модульное тестирование будет абсолютной необходимостью.
Если у вас есть несколько баз данных, которые нуждаются в одной и той же функциональности, есть другие способы уменьшить количество дублирования, которое, как я полагаю, является целью упражнения. Даже довольно сложная сборка CLR не займет много физического пространства хранения по сравнению с данными в самой базе данных (почти всегда), поэтому я не считаю это допустимым аргументом, если у вас нет буквально тысяч крошечных баз данных, которые нуждаются в этом сборка.
Что вы можете сделать, это изменить другие части процедуры развертывания для этих баз данных, чтобы уменьшить дублирование источника. Например, соберите и разверните сборку из общего расположения кода CLR в системе управления версиями. Или создайте сценарий, который развертывает ту же сборку в базах данных. Автоматизируйте эту часть как можно больше, и это не будет иметь большого значения.
Я согласен, что то, что я предлагаю, это компромисс, потому что все еще будет некоторое дублирование, но это должно быть сбалансировано с недостатками, связанными с реализацией архитектуры, которая не следует предписанному стандарту. Только вы можете решить, что подходит для вашей среды.