在Visual Studio的SQL Server数据工具(SSDT)项目中,我们有一个“核心” 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脚本通过SQLCMD引用引用其他子脚本:
:r .\ReferenceData\ReferenceDataScript1.sql
go
尝试以这种方式构建项目在Visual Studio中产生SQL72001错误(“包含的文件不存在”)。显然,如果我们将ReferenceDataScript1.sql文件物理放置在目录中(没有引用),则可以正常构建。
我们探索的选项包括在PostDeploy主文件和核心下标之间使用非构建“缓冲区”脚本(相同的错误),并设置构建前和构建后操作以将文件从子模块来回物理复制到满足构建引擎要求的项目(有点不合我们的口味)。
有人遇到此问题,或者有可解决的方法吗?
答案 0 :(得分:0)
我们通过在原始问题的注释中使用 Peter Schott 的建议解决方法来解决此问题,方法是使用返回磁盘上子模块的相对路径,而不是使用内部的“虚拟”链接。实际的Visual Studio SQL项目。
答案 1 :(得分:0)
我正在搜索如何使用子模块组织SSDT项目并找到您的问题。 我做了一些实现,但是我在实际的Visual Studio SQL项目中使用了“虚拟”链接。这是我的测试项目。
在.sqlproj中,我添加了:
<Build Include="Core\**\*.sql" Exclude="Core\**\*PostDepl*.sql" />
在项目PostDeploy脚本中,我在Core PostDeploy脚本上添加了链接:
:r .\Core\Script.PostDeploymentPopulateData.sql