search

microsoft / sqlmanagementobjects

Sql Management Objects, an API for scripting and managing SQL Server and Azure SQL Database
Other
124 stars 20 forks source link

Using SMO from Powershell #68

Open tcartwright opened 2 years ago

tcartwright commented 2 years ago

Can we go back to using an installer as well as providing the Nuget? Consuming the SMO Nuget package from PowerShell is quite beastly.

aguzev commented 1 year ago

Wonder, what is the most practical coding pattern for loading the SMO library after installation with the installer?

Due to stunning laziness, I use Microsoft SqlServer or dbatools modules to get SMO installed and instantiate SMO.Server or SMO.Database.

johlju commented 1 year ago

The problem occurs when trying to use SMO.Server and pass them between module SqlServer and dbatools, or another module like SQLPS because there is a chance that all these use different versions of SMO since the SMO version is packaged in the module (expect SQLPS that uses the SMO from GAC). If there are different version it is a big chance that the type cannot be converted between the different SMO versions (same type name, but different SMO version = so not the same).

Would like to see an easy way to get an "SMOModule" from gallery with an Import-Smo command that all these other modules can use as dependency. Team that works on OSS dbatools has the module dbatools.library that is the closests yet, but unsure how easy it is to use right now. Not sure we can use it in other project than dbotools either.

wsmelton commented 1 year ago

I can tell you dbatools wouldn't change to using your proposal. Any module author has to have control over version of a given library and what they are coding against. You have dependents around .NET version and then changes to the objects returned that authors may be expecting or not dealing with in their own module.

This is no different than just saying SMO should live in GAC and everyone depend on that. However there is no GAC in Linux and there authors are in the same issue I've already mentioned.

wsmelton commented 1 year ago

The library we are working on for dbatools also would not be one I'd expect other authors to depend on necessarily. It has ton of stuff that is not SMO related and only pertains to the dbatools module. There are dlls also for 3rd party products that authors would have to accept risk and licensing for. We received approval from SQL Server team for some DLLs to be used in the module.

aguzev commented 1 year ago

Would like to see an easy way to get an "SMOModule" from gallery with an Import-Smo command that all these other modules can use as dependency.

That would be an adapter for NuGet. Does such an adapter solve the problem? .NET is not dynamic enough.

If SMO had a separate DLL containing 'frozen' definitions of Server, Database, and other entities, then life could be a little bit easier… And ISqlServer, ISqlServer2, ISqlServer3, ISqlServer14 would emerge like our beloved COM interfaces :)