SQL Server 2012 smo

Question

关于Server 2012 SMO 1.与v10.0.0.0 ( 2008 )相比，在v11.0.0.0 (2012)中添加了哪些类型/方法/属性? 2.我是否应该使用app.config设置程序集绑定重定向，以允许用户在没有Server 2008的情况下同时保持与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>

​

Answer 1

我回答下面的实际问题。但首先，我看到在你的既定目标和你提出的解决方案之间有一个潜在的未实现的问题。也就是说，绑定重定向是没有条件的.因此，如果它找不到11.0.0.0版本，它将崩溃，而不是回到10.0.0.0上。因此，您只需要在安装SMO 2012时修改app.config。如果这是你想要的，那就忽略这一段的其余部分。一个可能更简单的解决方案是简单地安装您决定让您的应用程序依赖的SMO版本。它可以作为Server的独立安装使用，您可以同时安装10.0.0.0和11.0.0.0。下载网页：2012年，2008年R2，2008年。你需要SQLSysClrTypes.msi和SharedManagementObjects.msi

至于实际问题：

我唯一能找到的官员是SMO中的后向兼容性。它看起来很适合您正在讨论的内容，直到您开始查看文档的早期版本。也就是说，自SQL2008版本以来，它看起来相对没有变化。

根据这一点

使用以前版本的Server编写的SMO应用程序可以在Server 2012中使用SMO重新编译。

更新:在发布后，我决定尝试使用以前没有以这种方式使用的另一个项目。它有问题，因为它还引用了SmoExtended. --在这种情况下，至少有一种类型的DeviceType被移动到Smo和SmoExtended程序集之间。但是，类型保持在相同的命名空间中。这是一个彻底改变的例子，只有重新编译才能使用新版本。简而言之，如果不使用任何Smo*Extended程序集，则更有可能成功地重定向程序集。

如果只需要重新编译。然后，是的，然后程序集重定向一个很好的工作机会(因为应用程序将运行，这并不意味着破坏行为的改变)。当类型在程序集之间移动时，我可以想到哪里不是这种情况。特别是如果在两个程序集中定义了相同的命名空间。

由于似乎没有来自Microsoft的更详细的更改列表，所以您可以使用反射来迭代您的程序集的成员，这些成员对确切的差异非常好奇。您还可以翻阅msdn上的文档版本，查看新的类/方法。但是反思会更好地告诉你所有的差异。由于MS确实增加了版本，所以在某个地方和/或添加了新的类/方法。因此，您需要测试这两种方法，以确定它是否在运行时实际工作。

如果确实尝试重定向，则需要重定向所引用的所有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。目前，我们在我们的机器上开发linking SMO 2012，但是创建我们的构建机器链接SMO 2008，这意味着如果我们使用2012年的新东西(还没有发生)，我们的构建机器就会大发雷霆。这有点冒险，因为我们可以在本地进行测试，得到与发行版构建不同的结果(但谢天谢地，我们有一个QA部门，它适用于发行版构建，但在这里我们也从未遇到过问题)。在现实中，我更多的是使用上面的反义词。我将在我的机器上编译一个程序集，并希望将它部署到不支持SMO 2012的客户端。

总之，尽管你冒着自己的风险去做，你还是有很大的机会获得成功。