我回答下面的问题实际。但首先，我看到您的既定目标与您提出的解决方案之间可能未实现的问题。也就是说，绑定重定向不是有条件的。所以如果它找不到版本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的早期版本编写的，可以通过重新编译在SQL Server中使用SMO 2012
UPDATE SMO应用：张贴我决定后，试试这个以前没有以这种方式使用过的另一个项目。它有问题，因为它也引用SmoExtended.在这种情况下至少有一个类型DeviceType已在Smo和SmoExtended组件之间移动。但是，该类型仍保留在相同的名称空间中。这是一个突破变化的例子，其中只有重新编译才能使用新版本。总之，如果不使用任何Smo*Extended组件，则更有可能在重定向装配体方面取得成功。
如果只需要重新编译。然后，是的，然后程序集重定向一个很好的工作机会（在应用程序将运行，这并没有说任何关于改变行为的变化）。当我能想到这种情况不是这种情况时，主要的时间是类型在程序集之间移动。特别是如果在两个程序集中都定义了相同的名称空间。
由于似乎没有微软提供的更详细的更改列表，因此您可以使用反射来遍历程序集的成员，您对真正的差异感到非常好奇。您也可以翻阅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年的新产品（尚未发生），我们的构建机器将会适应。有点冒险，因为我们可以在本地进行测试并获得与发布版本不同的结果（但是幸好我们有一个质量保证部门可以与发布版本配合使用，但是在这里我们从来没有遇到过问题。）实际上，更常见的是我使用上面的逆。我将编译我的机器上的组件，并希望将其部署到不支持SMO 2012
总之有一个很好的机会，你将有成功，尽管你自己承担风险的客户。