How should the SMO nuget packages be structured? #46
Replies: 3 comments
-
Though choice! Personally, I like Alternatively, we could go We need more people to comment here! :) |
Beta Was this translation helpful? Give feedback.
-
Understanding libraries is one of my weak points. I know how to use it but I don't know how it works. I generally need packaging as simple as possible and I may be an exception in this area, I'd go for "as is" because I can scrape by with my experience. Any others, and I'd need to consult with someone to tell me how to combine everything into something that works for dbatools. And it especially hurts because Option 2 seems the worst for me because it's hard for me to resolve anything that's dynamic. I had this problem with Go and had to do something static and eventually gave up. I like how it is now even with the size because I know it works. But I'm open to others so long as there's some way to make it work like it does now. I also do love smaller. Perhaps @FriedrichWeinmann has some insight as to which one would be most helpful for us. He's our C# guy. |
Beta Was this translation helpful? Give feedback.
-
Well, I'd go for Option 4:
This solves both scenarios, does not break anything for anybody and forces you to be clear with your dependency management and keeping your code sane. |
Beta Was this translation helpful? Give feedback.
-
Historically, the "SQL Management Objects" label has been an umbrella term for a collection of DLLs that is always installed as an intact set. For years we distributed it via an MSI.
Now that SMO is available through nuget and the nuget package managers for VS2019+ are powerful, we have more options available for structuring these packages.
I am looking for community feedback on the current and future structure of the SMO nuget package to help prioritize any investment in this area over the coming year.
Current structure
Today, we have a single SMO package that doubles as both the compilation reference and the binary distribution package to be consumed by applications such as the SQL Tools Service. We optimized the structure for time-to-market when we moved the SMO build to a VS2019 retail msbuild system and we didn't want to spend time creating any fine grained packages.
The first question I have is whether SMO application developers are even concerned about this or if the current monolithic package is satisfying everyone's needs already. If you are happy with the status quo, please let us know that! If you feel like the current package structure hinders your ability to create applications, please consider the alternatives outline below and provide feedback.
thx
Options for future packages
Option 1- Keep it "as is",
Pros:
Cons:
Option 2 - Put each DLL in its own package and change Microsoft.SqlServer.SqlManagementObjects to simply pull in all the DLL packages as a dependency.
We can rely on "dotnet pack" to create a nupkg for each DLL which will automatically include compile-time dependencies as dependencies in the nuspec for each generated package.
Pros:
Cons:
Option 3 - Break the package up into a handful of smaller packages, partitioned by functionality.
There are several possible groupings of SMO DLLs. For example, we could have a Microsoft.SqlServer.SqlManagementObjects.Core package which only includes these DLLs:
These DLLs provide the functionality for scripting most SQL objects and the vast majority of the overall object model. We could put the DLLs for XEvents/WMI/Collector in a "Miscellaneous" package, SqlScriptPublish and Notebook in one, SmoExtended and SmoMetadataProvider in their own, etc.
Pros:
Cons:
Beta Was this translation helpful? Give feedback.
All reactions