I answer the actual question below. But first, I see a potentially unrealized problem between your stated goal and the proposed solution. Namely, redistribution bindings are not conditional. Therefore, if it cannot find version 11.0.0.0 , it will crash, and not be dropped to 10.0.0.0 . Thus, you only need to change app.config when installing SMO 2012. If this is what you intended, ignore the rest of this paragraph. A potentially simpler solution would be to simply install the version of SMO on which you decide to depend on your application. It is available as a standalone installation from SQL Server, and you can install both 10.0.0.0 and 11.0.0.0 . Download Pages: 2012 , 2008 R2 , 2008 . You will need SQLSysClrTypes.msi and SharedManagementObjects.msi
Now, regarding the current issue:
The only thing I could find was Backward Compatibility in SMO . It looks good for what you are discussing, until you start looking at previous versions of the document. Namely, it looks relatively unchanged from SQL2008.
Regarding this
SMO applications written using previous versions of SQL Server can be recompiled using SMO in SQL Server 2012.
UPDATE: After posting, I decided to try this with another project that was not previously used in this way. It has problems since it also refers to SmoExtended. . In this case, at least one DeviceType type DeviceType been moved between the Smo and SmoExtended . However, the type remains in the same namespace. This is an example of a violation in which only recompilation is required to use the new version. In short, you are more likely to succeed when redirecting assemblies if you are not using any Smo*Extended assemblies.
If all that is required is to recompile. Then yes, then the assembly redirects good chances to work (in that the application will work, which does not say anything about breaking changes in behavior). The main time I can think about where this is not is when the type moves between assemblies. In particular, if the same namespace is defined in both assemblies.
Since there seems to be no more detailed list of changes from Microsoft, you can use reflection to iterate over assembly members, you are really interested to know the exact differences. You can also flip through the msdn documentation versions to see how you deal with the new classes / methods. But it would be better to tell you about all the differences. As MS increased the version, some of them change, and / or the addition of new classes / methods. Thus, you will need to check both ways to make sure that it really works at runtime.
If you try to redirect a note, you will need to redirect all the SMO assemblies that you reference, not just the main one. It means that:
<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>
I have such redirects in production and there were no problems. Although YMMV. We are currently developing SMO 2012 bindings on our machines, but we are building our assembly for SMO 2008 machine links, which means our construction machine will be customized if we ever use something new in 2012 (it has not happened yet) ) A bit risky, because we can test locally and get different results than the release would be built (but, fortunately, we have a QA unit that works with the release build, but here we have never encountered a problem.) In fact, most often I use the opposite of the above. I will compile the assembly on my machine and want to deploy it to clients that do not support SMO 2012.
In short, there are good chances of success, although you do so at your own peril and risk.