我回答下面的問題實際。但首先，我看到您的既定目標與您提出的解決方案之間可能未實現的問題。也就是說，綁定重定向不是有條件的。所以如果它找不到版本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
總之有一個很好的機會，你將有成功，儘管你自己承擔風險的客戶。