A year ago in anticipation of publishing a book on SMO (which never came to be) I wrote a number of chapters demonstrating how to manage specific sets of objects, and I provided examples in VB.Net, C# and PowerShell. As should be expected, I thoroughly tested all of the code samples to make sure they worked.
This year I've been part a couple of book projects, one being the MVP Charity book which will come out this spring, and I just completed the chapter called "Scripting with PowerShell" for Paul Nielsen's SQL Server 2008 Bible. Without thinking much about it I included a couple of scripts that I'd written for the SMO book as examples. Unfortunately, I didn't test them again in my SQL Server 2008 environment.
I've already blogged here about the relocation of objects from the SMO.dll to the SMOExtended.dll.
What burned me most recently was a change in how you load a table object. Under SQL 2005 the following code worked fine:
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.SMO") | out-null
$s = new-object ("Microsoft.SqlServer.Management.Smo.Server") "MyServer\MyInstance"
#Reference the AdventureWorks database.
$db = $s.Databases["AdventureWorks"]
#Connect to the HumanResources.Employee table
$tbhremp = $db.Tables["Employee", "HumanResources"]
The script just wouldn't work using the SQL Server 2008 SMO DLLs. Here's what I ended up doing, and this worked.
#Connect to the HumanResources.Employee table
$tbhremp = $db.Tables | where-object {$_.Name -eq 'Employee' -and $_.Schema -eq 'HumanResources'}
I'm not sure why the first construct wouldn't work, but I couldn't even load the ErrorLog table using the first method. (I used that table for testing because it's in the dbo schema, which my login had as its default, so I didn't need to specify the schema name.)
Needless to say, any scripts you use today which rely on the behavior of the SQL 2005 DLLs need to be thoroughly tested with the SQL 2008 DLLs after they've been installed.
Allen