1

Yeah I did add the 4 dlls, found in:

C:\Program Files\Microsoft SQL Server\100\SDK\Assemblies

Which are these:

Microsoft.SqlServer.ConnectionInfo.dll
Microsoft.SqlServer.Smo.dll
Microsoft.SqlServer.Management.Sdk.Sfc.dll
Microsoft.SqlServer.SqlEnum.dll

And modified app config so it accepted the version the dlls had:

<startup useLegacyV2RuntimeActivationPolicy="true">
</startup>

And imported from VB.NET:

Imports Microsoft.SqlServer.Management.Smo
Imports Microsoft.SqlServer.Management.Common

And the program recognizes every word except Server:

Dim fileInfo As New FileInfo(fi.FullName)
Dim script As String = fileInfo.OpenText().ReadToEnd()
Dim connection As New SqlConnection(sqlConnectionString)
Dim server As New Server(New ServerConnection(connection))
server.ConnectionContext.ExecuteNonQuery(script)

It says:

'Type Server is not defined'

Thus the program fails. Any ideas of what is going on? I'm pretty sure an identical scenario is working on a test project on another computer, I don't know why this isn't working. Thanks.

UPDATE:

I tried bringing the dlls from the computer that has this program working to here, and Smo contained Server, so there were no errors. But when I built the program it's like the dlls changed during runtime or something, because suddenly Server is marked as an error again and Smo doesn't contain it anymore, why is this happening?

user1676874
  • 875
  • 2
  • 24
  • 45

1 Answers1

1

SMO is unfortunately not something that can be deployed by just copying the DLLs. We have this in our app (along with RMO and others), and it is a right pain to deploy to production. It needs the appropriate MS installers run.

You can get them from here: http://www.microsoft.com/en-us/download/details.aspx?id=16978

Or, the 64bit installer: http://go.microsoft.com/fwlink/?LinkID=188439&clcid=0x409

  • Why do you say it's a pain? – user1676874 Dec 18 '13 at 00:53
  • It is a pain for deployment because we can't simply package our installer and include the DLLs. And it isn't even as simple as packaging the Microsoft installers. A lot of the sql components installers depends on the target OS and CPU architecture - the SMO one has three versions, one for x86, one for x64, and one for ia64. Plus the bulk of installers needed. It makes a product deployment messy, and yes, a pain. If I'm not clear enough here, SMO will not work by copying the SMO DLLs that your application uses. You need to run the SQL Management Objects installer. I can't post direct links –  Dec 18 '13 at 01:28
  • Ok so if I wanted to deploy this program, I would have to make sure every user installed the SQL Management Objects as well? It does seem like a problem. I wasn't aware SMO was this troublesome. It was sold to me as the big thing that'd make things easier, guess they was wrong. – user1676874 Dec 18 '13 at 01:48
  • Yes, that is correct. And yes it really is troublesome. And we had to actually restructure our entire solution to try drop dependencies. Eg we were using SMO and RMO in just one application, and as a result the web portal suddenly needed SQL SMO and RMO installers run (just due to common business logic layer project between the SMO/RMO app and the portal). Our support and deployment people had all this extra grief from it. It wasn't much fun. –  Dec 18 '13 at 01:58
  • While all that is somewhat true, this is not an answer to the question. – Mitch Wheat Dec 18 '13 at 05:17
  • 1
    Sorry Mitch but you are incorrect. The posters issue would be resolved if the SMO installers are installed on the machines displaying the issue. –  Dec 18 '13 at 05:21
  • Wait, this application is oriented only for people that already have SQL Server and Management Studio installed, would that mean they would also have SQL Management Objects installed? – user1676874 Dec 18 '13 at 15:47
  • 1
    @user1676874 Not necessarily the version that you want. – RBarryYoung Dec 21 '13 at 16:39
  • Which would explain why it didn't work on my other computer, luckily I've made it work without the need for SMO. – user1676874 Dec 23 '13 at 16:35