>Sorry burt that did not work. It copied the dlls, but that was about it. I got one dll registration error. i think it was the SQLDISTXLib.dll
>
>i think i go with your other approach.
>
>thanks!

Well, it was worth a try! <g> Thanks for letting us know that it doesn't work.

The utilities I've written to deal with creating/updating databases have always been intended to be run on the server, so getting access to those SMO DLLs was never a problem. The fact that you can use that other approach I showed utilizing .NET classes to at least find all the servers on the network should at least make most of your installation fairly painless.

~~Bonnie



>
>>I see no problem with that approach.
>>
>>But, rather than require the user to run the app on the existing server machine, here's another thing you can do rather than install SMO:
>>
>>- Change the "Copy Local" for the SMO references. IOW, in the references of your app, right-click on the Microsoft.SqlServer.Smo and choose Properties. Then change "Copy Local" to true (do this with the other Microsoft.SqlServer.* DLLs). The DLLs get included in your bin\debug folder. So, you're actually going to distribute the DLLs with your app. That's probably ok to do, I'm guessing.
>>
>>... and it seems to work ok, I just tested it. Although, to be honest, I didn't actually test it on a machine that doesn't already have SMO installed, so you may want to play with it a bit more.
>>
>>~~Bonnie