我正在尝试在我们的一个存储过程中配置变量(令牌),该存储过程是 DACPAC 项目的一部分。我试图以与配置文件相同的方式执行此操作。IE
使用 ext 令牌创建一个重复文件。将要替换的项目替换为TOKEN_NAME。在 RM 中为组件创建一个变量。但是,这似乎不适用于 DACPAC 解决方案,并且变量不会被替换。
这可能与 DACPAC 项目有关吗?如果不是,我可以采取什么方法在存储过程中添加可配置项?
如果这是可能的,我哪里错了?
我正在尝试在我们的一个存储过程中配置变量(令牌),该存储过程是 DACPAC 项目的一部分。我试图以与配置文件相同的方式执行此操作。IE
使用 ext 令牌创建一个重复文件。将要替换的项目替换为TOKEN_NAME。在 RM 中为组件创建一个变量。但是,这似乎不适用于 DACPAC 解决方案,并且变量不会被替换。
这可能与 DACPAC 项目有关吗?如果不是,我可以采取什么方法在存储过程中添加可配置项?
如果这是可能的,我哪里错了?
这不是一个发布管理问题,而是一个 SSDT 问题。您想做的事情通常是一个非常糟糕的主意:让您的数据库因环境而异。持续交付就是关于一致性。如果您不能相信每次将软件发布到较低环境时都在“练习”生产部署,那么当生产部署由于环境差异而失败时,您将面临一个非常糟糕的时期。
也就是说:您可以做几件事,按优先顺序列出:
sqlpackage.exe
以便在发布时提供 SQLCmd 变量。这仍然是一个非常糟糕的主意,但它应该对你有用。在发布 DACPAC 时,我看不到任何使用令牌文件的方法,因为 RM 无法干扰 sqlpackage.exe 正在执行的操作,即使它可能会导致架构停止编译。
您也许可以编写一个组件来解压缩 DACPAC 文件,进行令牌替换,然后将其重新压缩,但这听起来很辛苦。
我的建议是在 DACPAC 使用标记化 SQL 脚本运行后应用环境特定要求。我在这里的一篇博文中对此进行了描述。