1

シナリオ：

私の組織では、複数のアプリケーションを個別に開発しています。ただし、最終的には、多くのアプリケーション (およびそのデータベース) が同じ SQL インスタンスにデプロイされるため、同じマスター データベースを共有します。

Visual Studio 2010 データベースとサーバー プロジェクトを使用して、データベースのソース管理を行っています。

いくつかのことを試して標準化するために、次のことを行いたいです。

  1. すべてのサーバー設定、コア ログインなどを含む「コア」サーバー データベース プロジェクトを作成します。SET TRUSTWORTHY ON やサーバー レベルの ANSI 設定などです。
  2. 各アプリケーションの独自の Server.dbproj で、そのアプリケーションに固有のログインやロールなどを指定します。
  3. 各アプリケーション独自の ApplicationDatabase.dbproj が ApplicationX.Server.dbproj を参照するようにする

理論的には、ソース管理の各アプリケーションには、サーバー関連の設定や構成を多くのプロジェクト間で同期させるのではなく、固有のアイテムのみが含まれます。

問題

ただし、実際には、ここまで到達できます。

  1. 終わり。今後の手順で参照する .schema ファイルを生成します
  2. 終わり。Server.dbproj は喜んで Core.dbschema を参照し、独自のログインやロールなどでそれを「拡張」します。
  3. なだ。ApplicationDatabase.dbproj から Server.dbproj への参照を追加すると (サーバーが Core から項目を取得すると仮定して)、実際に Core にあるログインについて不平を言います。

そこで、落ち着いたら、Server と Core の両方を ApplicationDatabase への参照として追加しました。正常にコンパイルされます。

ただし、展開すると、ここで説明されているのと同じ問題が発生します。

Error TSD01234: The source model contains 2 server option elements. 
Only one element can be   contained in a model that can be deployed

問題は、ApplicationDatabase が基本的に 2 つのサーバー プロジェクトを認識しているため、設定が重複していることです。

Microsoft のドキュメントには、サーバー プロジェクトでの部分プロジェクトの使用については言及されていませんが、制限事項として記載されていません。

質問は...

サーバー プロジェクトで部分プロジェクトをうまく使用した人はいますか、それとも同じことを達成する方法はありますか?

正直に言うと、問題を解決するために「サーバー プロジェクトを削除する」だけではありません。問題を改善しようとするまでは、非常にうまく機能していました。

4

0 に答える 0