Compatibility Issues for SQL Server 2005 and SQL Server 2008

I'm trying to execute a schema file on a SQL Server machine. I currently have both SQL Server 2005 and SQL Server 2008 installed. When I try to execute the .sql file (meant to execute on the 2008 version) I get the following error.

Microsoft.SqlServer.Management.Common.ConnectionFailureException: 
Failed to connect to server . --->    
Microsoft.SqlServer.Management.Common.ConnectionFailureException: This SQL Server
version (10.0) is not 开发者_如何学Csupported

Is there a way to specify which version the Microsoft.SqlServer.Management.Smo.dll looks at when you execute the program or some other workaround other than uninstalling the 2005 version?

EDIT

I'm running the .sql file from an ASP.Net application and using the Microsoft.SqlServer.SMO dll

ServerConnection conn = new ServerConnection(new System.Data.SqlClient.SqlConnection(connString),);
Server srv = new Server(conn);

// execute sql file
srv.ConnectionContext.StatementTimeout = 300000;
srv.Databases[conn.DatabaseName].ExecuteNonQuery(schema);

---

Based on the error message you're getting, it sounds very much like you are somehow using/accessing SQL 2005 utilities. "Version 10.0" is SQL 2008 (in engineering speak, as opposed to marketing). Are you sure you're accessing the right dll?

Once upon a time long ago, I hit something perhaps similar. We had SQL 7.0 and 2000 on one box (I said it was long ago) and we were calling some utility via batch file, Command window, something like that, and we could only get the old/incompatible version of the utility to run. Days later, someone [Hi Greg!] thought to look a the DOS environment PATH setting, and lo and behold, because of the order the folders were listed in, the OS would find the old version before the new one. Might something like this be tripping you up now?

---

Never tried to run SMO stuff from an ASP.NET process, but you can probably just load the file, split on "GO" and run it as a series of SQL commands without too much fuss. That should not care about the sql version issues unless there is some SQL statement that is somehow version specific.