У меня есть решение с двумя проектами. Первый — это проект базовой библиотеки классов, содержащий определение классов, совместно используемых несколькими конечными точками службы (DataContract.dll). Второй — это проект SQL CLR, в котором будут использоваться классы, определенные в общей сборке. На моей локальной машине я могу зарегистрировать эту сборку в локальном экземпляре SQL Server, добавить ссылку на сборку и скомпилировать. Однако, когда я фиксирую этот код на нашей сборочной машине, сборка не регистрируется на сервере. Я мог бы вручную зарегистрировать сборку на сервере сборки, но это не поможет новым разработчикам, которые присоединяются к проекту и имеют неработающую сборку при первой проверке. Кроме того, наш сервер сборки выбирает случайное имя для временного каталога, в котором он создается, поэтому ссылка на экземпляр базы данных сервера сборки может быть устаревшей или отсутствовать. Есть ли способ сослаться на проект общей библиотеки из моего проекта SQL CLR, чтобы сервер сборки и новые разработчики всегда имели хорошую сборку?
Как сослаться на проект CLR, отличный от SQL, из моего проекта SQL CLR?
comment
Возможно, моя установка отличается от вашей, но в моем проекте SQLCLR единственные ссылки, которые я могу добавить, исходят из базы данных, предназначенной для развертывания. Мне кажется, сервер сборки должен быть настроен таким же образом. Если это невозможно, кажется, что единственным вариантом является регистрация сборки класса в GAC машины сборки.
- person David W schedule 08.08.2012
comment
Да, это ограничение, которое я пытаюсь обойти (общая сборка должна быть зарегистрирована в базе данных, доступной как для моей машины разработки, так и для машины сборки, или сборка должна находиться в GAC машины, выполняющей компиляцию). Машина сборки очищает предыдущую сборку (и, таким образом, делает недействительной текущую регистрацию GAC/DB), а затем перестраивает в новом месте. Это приводит к отсутствию ссылки.
- person JadeMason schedule 08.08.2012
Ответы (1)
У меня была такая же проблема раньше, хотя это не обязательно было просто SQLCLR. Я обнаружил, что лучший способ сделать это — создать собственный сервер NuGet< /а>. Если это кажется сложным или у вас нет ресурсов, я бы предложил иметь общий ресурс unc для общих библиотек. Вы можете создать сценарий пост-сборки, который копирует двоичные файлы в путь unc после их успешной локальной компиляции.
person
ewahner
schedule
13.10.2015
