我回答下面的实际问题。但首先，我发现您的既定目标和您提出的解决方案之间可能存在未实现的问题。也就是说，绑定重定向不是有条件的。因此，如果它找不到版本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
现在关于实际问题：
我能找到的唯一官方信息是Backward Compatibility in SMO。在您开始查看文档的先前版本之前，它看起来很适合您正在讨论的内容。即从 SQL2008 版本开始，它看起来相对没有变化。
据此
可以使用 SQL Server 2012 中的 SMO 重新编译使用以前版本的 SQL Server 编写的 SMO 应用程序。
更新：发布后，我决定在另一个以前没有以这种方式使用过的项目上尝试一下。它存在问题，因为它还引用了SmoExtended. 在这种情况下，至少一种类型DeviceType 在Smo 和SmoExtended 程序集之间移动。但是，该类型仍保留在同一命名空间中。这是一个重大更改的示例，其中只需重新编译即可使用新版本。简而言之，如果您不使用任何 Smo*Extended 程序集，您更有可能成功重定向程序集。
如果只需要重新编译。然后，是的，然后程序集重定向一个很好的工作机会（因为应用程序将运行，这并没有说明任何关于破坏行为的改变）。我能想到不会出现这种情况的主要时间是在程序集之间移动类型时。特别是如果在两个程序集中定义了相同的命名空间。
由于似乎没有来自 Microsoft 的更详细的更改列表，您可以使用反射来迭代程序集的成员，您对确切的差异非常好奇。您还可以在 msdn 上翻阅 documentation 的版本，看看您是否发现了新的类/方法。但是反思会更好地告诉你所有的差异。由于 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。目前我们在我们的机器上开发链接 SMO 2012，但创建我们的构建机器链接 SMO 2008，这意味着如果我们使用 2012 年的新东西（还没有发生），我们的构建机器将会失败。有点冒险，因为我们可以在本地进行测试并获得与发布版本不同的结果（但幸运的是，我们有一个 QA 部门与发布版本一起工作，但在这里我们从未遇到过问题。）实际上，我更经常使用上面的倒数。我将在我的机器上编译一个程序集，并希望将它部署到不支持 SMO 2012 的客户端。
简而言之，您很有可能会取得成功，但风险自负。