В проекте SQL Server Data Tools (SSDT) в Visual Studio у нас есть «базовый» набор объектов SQL, которые включены в каждый проект SQL, который мы делаем, — что-то вроде библиотеки классов. Мы храним эти «основные» объекты SQL в отдельном репозитории Git, а затем включаем их в другие проекты как подмодуль Git.
Как только «основной» подмодуль связан с основным проектом, мы включаем файлы подмодуля в наш файл .SQLPROJ следующим образом:
<Content Include="..\CoreSubmodule\ProjectFolder\Scripts\**\*.*">
<Link>Scripts\%(RecursiveDir)%(FileName)%(Extension)</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
Это отлично работает для обычных файлов .sql в проекте - они отображаются со специальным значком в Visual Studio, указывающим, что это файл, на который ссылаются, и механизм сборки может прекрасно разрешать ссылки/зависимости. Однако мы сталкиваемся с проблемой с нашими сценариями до и после развертывания.
У нас есть ряд «основных» мастер-скриптов до и после развертывания, которые являются общими для проектов, которые мы только что представили в нашем «основном» подмодуле. Вот как структура каталогов выглядит на высоком уровне:
/Scripts/
/PostDeploy/
_PostDeployMaster.sql
/ReferenceData/
ReferenceDataScript1.sql
В приведенной выше структуре:
- _PostDeploymentMaster.sql — это локальный файл в проекте, для которого задано значение Build Action = "PostDeploy". Он содержит ссылку на файл *ReferenceDataScript1.sql.
- ReferenceDataScript1.sql is a reference to a file that physically
exists in the submodule directory (one level up from our project),
and is set to Build Action = "None"
- Note that Visual Studio displays it in the /ReferenceData/ folder as a linked file
Скрипт _PostDeploymentMaster ссылается на другие субскрипты через ссылку SQLCMD:
:r .\ReferenceData\ReferenceDataScript1.sql
go
Попытка построить проект таким образом приводит к ошибке SQL72001 в Visual Studio ("Включенный файл не существует"). Очевидно, что если мы физически поместим файл ReferenceDataScript1.sql в каталог (без ссылки), он будет прекрасно построен.
Варианты, которые мы исследовали, включают в себя наличие «буферного» сценария без сборки между мастером PostDeploy и базовыми индексами (та же ошибка), а также наличие действий до и после сборки, настроенных на физическое копирование файлов туда и обратно из подмодуля в проект, чтобы удовлетворить движок сборки (слишком хакерский на наш вкус).
Кто-нибудь сталкивался с этой проблемой или у него есть исправный обходной путь?
