Hello,

You may have at least 2 problems when you are writing a SMO application :

1- between 2 SMO versions , you can discover that classes may change of namespaces ( the 1st well-known example is the Backup class which has changed its namespace )

2- another problem which is annoying when you are using a SMO application built on a former version of SMO ( for example 2005 ) against a latter version of SQL Server ( 2008 R2 or 2012 ) is appearing with the use of enumerations of which the number of values has changed ( mainly increasing for the latter version , but it seems it was the contrary for at least 1 enumeration in the Smo.Wmi namespace )

In theory , an application written with SMO 2012 is working in 99% of cases against any version of SQL Server ( at least >= 2000 ). But the payload may be heavy as you have for each SMO namespace to set the value of Copy local to true in your Visual Studio with the consequence that the executable will be huger than for the classical way : the referenced assembly is copied in the output directory. Advantage : you are not depending of the assemblies existing on the computer on which the application is running.

In practice , you have to maintain your application only for the last version of SQL Server and when a new SQL Server version is released , you have to recompile after having verified whether some classes have not migrated from a namespace to another one.

You have to be prepared that a property existing in the latest version doesn't exist in a former one. The best way is to test whether the property is existing in the current SQL Server and to decide what to do in case of absence of the property.

It is what I am doing in my SMO applications and since 2006 ( SQL Server 2005 SP2 ) , I think I met only 2 problems that I bypassed easily.

Have a nice day