I know you mean well. At one stage I was really excited about SMO, and RMO (the replication management objects library). However, we got so bitten by it.

For starters, the coverage is very hit and miss depending on versions. You get no errors, but some classes methods etc just don't work properly depending on the SQL version (particularly 2000). You call them and no exception or errors, but the data returned is rubbish or more or less empty.

Secondly, using SMO for something that is widely deployed adds some pretty hideous installation requirements. It isn't just a matter of bundling libraries. You need to run a stack of OS and CPU dependent Microsoft SQL artefacts installers, if the target machine either doesn't have SLQ installed at all, or has an earlier version of SQL than the libraries. And with these installers, it isn't as much as install SMO version 2008 or whatever, it means get the x86, i64, etc version of this, then install the correct version of depending on the OS and CPU, then this. It was a deployment nightmare.

Thirdly, The RMO libraries were abandoned back in SQL 2008 (R1). Microsoft say they are deprecated as of 2012, but that isn't the case. They don't actually work in 2012. They didnt' say they were deprecated in 2008R2 either, but they never issued a version for R2. It did work with R2 however.

I had written a SQL version agnostic replication setup and management tool using SMO and RMO. It made production deployments easier, but the prerequisites were just messy. Then of course as soon as 2012 arrived it didn't work. So I rewrote it removing all SMO and RMO. The installation is so much cleaner, all those damned SMO and RMO references removed from the project, the error management so much cleaner, and the code so much cleaner.