4

SQL Server 2012 SMO について 1. v10.0.0.0 (2008) と比較して v11.0.0.0 (2012) に追加された型、メソッド、プロパティは何ですか? 2. app.config を使用してアセンブリ バインディング リダイレクトを設定し、SQL Server 2008 との互換性を維持しながら、SQL Server 2008 を使用していないユーザーを許可する必要がありますか?

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
     <dependentAssembly>
        <assemblyIdentity name="Microsoft.SqlServer.Smo"
                          publicKeyToken="89845dcd8080cc91"
                          culture="neutral" />
        <bindingRedirect oldVersion="10.0.0.0"
                         newVersion="11.0.0.0"/>
     </dependentAssembly>
  </assemblyBinding>

4

1 に答える 1

4

以下の実際の質問に答えます。しかし、最初に、あなたが述べた目標と提案された解決策の間に潜在的に実現されていない問題があることに気づきました。つまり、バインディング リダイレクトは条件付きではありません。したがって、バージョンが見つからない場合11.0.0.0は、にフォールバックするのではなく、クラッシュし10.0.0.0ます。そのため、SMO 2012 がインストールされている場合にのみ、app.config を変更する必要があります。これが意図したものである場合は、この段落の残りの部分を無視してください。もっと簡単な解決策は、アプリケーションを依存させることにした SMO のバージョンを単純にインストールすることです。SQL Server とは別のインストールとして利用でき、両方10.0.0.0を11.0.0.0インストールできます。ダウンロードページ: 2012 , 2008 R2 , 2008 . あなたが必要SQLSysClrTypes.msiになりますSharedManagementObjects.msi

実際の質問については：

私が公式に見つけた唯一のものは SMO の下位互換性でした。文書の以前のバージョンを見始めるまでは、話し合っている内容に適しているように見えます。つまり、SQL2008 バージョンから比較的変わっていないように見えます。

それによると

以前のバージョンの SQL Server を使用して作成された SMO アプリケーションは、SQL Server 2012 で SMO を使用して再コンパイルできます。

更新:投稿後、以前はこの方法で使用されていなかった別のプロジェクトでこれを試すことにしました。SmoExtended.この場合、少なくとも 1 つの型がとアセンブリDeviceTypeの間で移動されたことも参照しているため、問題があります。ただし、型は同じ名前空間に残ります。これは、新しいバージョンを使用するために再コンパイルのみが必要な破壊的変更の例です。つまり、アセンブリをまったく使用しない場合、アセンブリのリダイレクトに成功する可能性が高くなります。SmoSmoExtendedSmo*Extended

必要なのは再コンパイルだけです。次に、はい、アセンブリ リダイレクトが機能する可能性が高くなります (アプリケーションが実行されるという点で、動作の重大な変更については何も言いません)。これが当てはまらない主なケースとして考えられるのは、アセンブリ間で型が移動するときです。特に、両方のアセンブリで同じ名前空間が定義されている場合。

Microsoft からのより詳細な変更リストはないようですので、リフレクションを使用して、アセンブリのメンバーを反復処理することができます。正確な違いに本当に興味があります。msdnのドキュメントのバージョンをめくって、新しいクラス/メソッドを見つけることもできます。しかし、リフレクションはすべての違いを伝えるのに適しています。MS がバージョンをインクリメントしたため、どこかで重大な変更が行われたり、新しいクラス/メソッドが追加されたりします。したがって、実行時に実際に機能するかどうかを確認するには、両方の方法をテストする必要があります。

リダイレクトを試みる場合は、メインの SMO アセンブリだけでなく、参照するすべての SMO アセンブリをリダイレクトする必要があることに注意してください。つまり、少なくとも次のことを意味します。

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="Microsoft.SqlServer.Smo"
                        publicKeyToken="89845dcd8080cc91"
                        culture="neutral" />
      <bindingRedirect oldVersion="10.0.0.0"
                       newVersion="11.0.0.0" />
    </dependentAssembly>
    <dependentAssembly>
      <assemblyIdentity name="Microsoft.SqlServer.Management.Sdk.Sfc"
                        publicKeyToken="89845dcd8080cc91"
                        culture="neutral" />
      <bindingRedirect oldVersion="10.0.0.0"
                       newVersion="11.0.0.0" />
    </dependentAssembly>
    <dependentAssembly>
      <assemblyIdentity name="Microsoft.SqlServer.ConnectionInfo"
                        publicKeyToken="89845dcd8080cc91"
                        culture="neutral" />
      <bindingRedirect oldVersion="10.0.0.0"
                       newVersion="11.0.0.0" />
    </dependentAssembly>
  </assemblyBinding>
</runtime>

本番環境でそのようなリダイレクトがあり、問題はありませんでした。YMMVだけど。現在、マシン上で SMO 2012 のリンクを開発していますが、ビルド マシンを作成して SMO 2008 にリンクしています。ローカルでテストして、リリース ビルドとは異なる結果が得られるので、少し危険です (しかし、ありがたいことに、リリース ビルドで機能する QA 部門がありますが、ここでも問題が発生したことはありません)。上記の逆を使用します。自分のマシンでアセンブリをコンパイルし、SMO 2012 をサポートしていないクライアントに展開したいと考えています。

要するに、成功する可能性は十分にありますが、自己責任で行ってください。

于 2012-12-05T16:10:57.850 に答える