SQL Server 2012 smo - smo

Question

About SQL Server 2012 SMO
1. What types / methods / properties are added to v11.0.0.0 (2012) compared to v10.0.0.0 (2008)?
2. Should I use app.config to set assembly binding redirection to allow users without SQL Server 2008 while maintaining compatibility with 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

I answer the actual question below. But first, I see a potentially unrealized issue between your stated goal and your proposed solution. Namely, binding re-directs are not conditional. So if it cannot find version 11.0.0.0 it will crash rather than falling back on 10.0.0.0. So you would need to only modify the app.config when SMO 2012 is installed. If this is what you were intending, ignore the rest of this paragraph. A potentially simpler solution would be to simply install the version of SMO you decide to make your application dependent on. It is available as a separate install from SQL Server and you can have both 10.0.0.0 and 11.0.0.0 installed. Download Pages: 2012, 2008 R2, 2008. You will need SQLSysClrTypes.msi and SharedManagementObjects.msi
Now as to the actual question:
The only thing official 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 appears relatively unchanged since the SQL2008 version.
According to that
SMO applications that were written using previous versions of SQL Server can be recompiled by using SMO in SQL Server 2012.
UPDATE: After posting I decided to try this with another project that previously had not been used in this way. It has issues because it also references SmoExtended. At least one type DeviceType in this case was moved between the Smo and the SmoExtended assemblies. However, the type remains in the same namespace. This is an example of a breaking change where only recompilation is necessary to use the new version. In short you are more likely to have success with redirecting assemblies if you do not use any of the Smo*Extended assemblies.
If all it takes is a re-compile. Then, yes, then assembly redirect a good chance of working (In that the application will run, that does not say anything about breaking change in behavior). The main time when I can think of where this would not be the case is when a type is moved between assemblies. Particularly if the same namespace is defined in both assemblies.
Since there does not seem to be a more detailed change list from Microsoft, you could use reflection to iterate over the members of the assemblies of you are really curious about the exact differences. You could also flip through versions of the documentation on msdn to see of you spot new classes/methods. But reflection would be better at telling you all the differences. Since MS did increment the version are some breaking change somewhere and/or the addition of new classes/methods. Thus you will need to test both ways to see if it actually works at runtime.
If you do try redirection note you will need to redirect all SMO assemblies that you reference, not just the main one. That means at least:
<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 not had issue. Though YMMV. Currently we develop linking SMO 2012 on our machines, but create our build machine links SMO 2008, which means our build machine will throw a fit if we ever use something new to 2012 (has not happened yet). A bit risky because we could test locally and get different results than the release build would have (but thankfully we have a QA division what works with the release build, but also here we have never had issue.) In actuality it is more often I use the inverse of the above. I will compile an assembly on my machine and want to deploy it to clients that do not support SMO 2012.
In short there is a good chance you will have success, though you do so at your own risk.