Проект базы данных SQL: создание разных сценариев в зависимости от конфигурации сборки

Question

Проблема, которую я хочу решить, заключается в создании разных сценариев в зависимости от конфигурации сборки.

Скажет, у нас есть два экземпляра SQL Server: версии

• Enterprise с подключенных Linked серверами
• LocalDB версии для форума разработки и модульных тестов

Enterprise версия имеет представление для связанных серверов, когда LocalDB заменяет эти представления локальными таблицами.

Эти привязанные виды серверов и локальные таблицы имеют одинаковые имена и множество полей. Поэтому они не включены в сборку по умолчанию (Build Action = None). Вместо этого они включены в сборку в BeforeBuild Target файла проекта.

<Target Name="BeforeBuild"> 

    <ItemGroup Condition=" '$(Configuration)' == 'LocalDb'"> 
     <Build Include="Local_Tables\*.sql" /> 
    </ItemGroup> 

    <ItemGroup Condition=" '$(Configuration)' != 'LocalDb' "> 
     <Build Include="Linked_Server_Views\*.sql" /> 
    </ItemGroup> 

</Target> 

Но проблема заключается в том, что Visual Studio кэширует модель DB и если мы сначала построить проект LocalDB, а затем попытаться построить проект для конфигурации Enterprise - ошибки Visual Studio выходы:

Ошибка: SQL71508: В модель уже имеет элемент с таким же именем

Если закрыть и открыть решение или выгрузить проект и перезагрузить проект, Visual Studio воссоздает файлы dbmdl, а конфигурация Enterprise будет строиться без ошибок.

Итак, мое предположение, если я обновляю кеш dbmdl, я получу гладкую сборку без ошибок.

---

При открытии или перезагрузки проекта базы данных SQL Server в Visual Studio 2012, он создает файл с расширением dbmdl, который является десериализации и кэшируются модель БД, как описано here.

В момент dbmdl файла отдыха Visual Studio выводит следующее:

Deserializing the project state for project 'MyProject.sqlproj'... 
Detecting file changes for project 'MyProject.sqlproj'... 
Deserialization has been completed for project 'MyProject.sqlproj'. 

Как заставить Visual Studio, чтобы обновить кэш dbmdl без проекта перезагрузки и без изменения XML-файла проекта?

Есть ли способ обновить кеш dbmdl, помещая команду в объекты BeforeBuild или AfterBuild проекта xml-файла?

Или весь подход к проблеме неверен, и существует другой способ создания разных сценариев в зависимости от конфигурации сборки?

Answer 1

Возможно, у вас может быть другой возможный вариант использования составных проектов. Джейми Томпсон рассказал о них здесь: http://sqlblog.com/blogs/jamie_thomson/archive/2013/03/10/deployment-of-client-specific-database-code-using-ssdt.aspx

Это позволит вам построить основной проект и связать дополнительные проекты с кодом, специфичным для окружающей среды. Вы можете развернуть соответствующий, выполнив некоторые проверки в сценариях выпуска.

Answer 2

Я думал об этом и наилучшим образом справился с этим с помощью SSDT. Я, вероятно, не имею «лучший» путь, но если вы можете определить правильную версию, перед публикацией изменений, я считаю, что это:

1. Создание профиля публикации для каждого издания - с и без связанных серверов.
2. Создайте переменные для хранения имен связанных серверов, возможно, включая базу данных, а также нечто вроде «[Сервер].[База данных]. »
3. Создайте сценарий после развертывания для ваших связанных видов сервера. Они должны включать разрешения, переменные для имен связанных серверов и т. Д.
4. В сценарии Post-Deploy запросите свой" редакция ".Если он будет использовать связанные серверы, отбросьте/воссоздайте собственные незанятые виды серверов в проекте, чтобы использовать их на связанных серверах. Альтернативно, установите переменную в пустую строку для локального представления и сервера/DB для связанного сервера, и вы, вероятно, можете просто использовать один набор кода.

Это имеет недостаток, заключающийся в том, что вы не можете проверять код на свои взгляды, но предоставили бы вам одно место для хранения связанных ссылок на сервер и один plac е, из которых их развернуть. Вам нужно будет освободить с помощью Drop/Create вместо того, чтобы позволить SSDT обрабатывать изменения, что означает, что они будут воссозданы при каждом действии публикации. Я думаю, что это может дать вам решение, которое вы ищете.