Install-Package : Dependency loop detected for package 'Microsoft.SqlServer.SqlManagementObjects'

Question

Hi,

I'm having a rough time trying to install SQL SMO to a server. This is my first time trying Nuget. Previously I would use the .msi.

I'm running the following from Admin PowerShell ISE:

Install-Package -Name Microsoft.SqlServer.SqlManagementObjects -ProviderName NuGet -RequiredVersion 170.13.0 -Source https://www.nuget.org/api/v2 -Verbose

I'm receiving the following error:

Install-Package : Dependency loop detected for package 'Microsoft.SqlServer.SqlManagementObjects'.
At line:1 char:1
+ Install-Package -Name Microsoft.SqlServer.SqlManagementObjects -Provi ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : Deadlock detected: (Microsoft.SqlServer.SqlManagementObjects:String) [Install-Package], Exception
    + FullyQualifiedErrorId : DependencyLoopDetected,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage

With the verbose flag enabled, I see the following package is seemingly tried twice (the second time is when the process aborts and the error is thrown): System.Memory.

Any help will be appreciated!

Thanks,
Taarik.

Answer 1

PowerShell's Install-Package seems to work fine if it's a simple installation otherwise it's a hot mess (as I've seen others state). I've had problems with Install-Package with several NuGet packages. Have you tried using dotnet.exe to add the package?

Answer 2

Hey Rich, sorry for calling you Rick. I read your background and we have the same background. I was there migrating Profs/OfficeVision to NT Exchange 5.5, NT Domains to Active Directory 2000 with Perl, and on and on. I was Corporate IT Enterprise and have even worked with the largest AD I believe in the world within the NIPRNET containing over 1.5 million user objects and over 2 million Computer objects across Domains across the world's time zones within one Forest. You were likely on the Microsoft Premiere team and maybe worked with me. I am developing a project I hope to Open Source on GitHub. You are old enough to remember when Microsoft warned everyone not to extend the Active Directory Schema and unfortunately, it stuck with everyone since AD 2000 birth to keep a pristine AD accept Software vendor's Extensions. This was bull and even Microsoft admits this. Active Directory is hands down the most stable product Microsft created and could have solved so many problems like just storing contractors as an Auxillary Class with associated contractor attributes. Or tracking paid software and custom applications across computers. One day I went down the rabbit hole and extended AD with all of Major League Baseball's (MLB) Statistic Attributes (HR, RBI, H, AB, etc.) tying these attributes to an Auxclass: auxMLBClass and linking to the User Object. I thought how cool it would be to take any CSV and dynamically add attributes to AD and this is where I forked off utilizing SQL tools to dynamically auto-predict table Schema and ingest CSVs into SQL to create SQL Schema for me to read and create matching AD Schema Attribute entries. I was blown away by how advanced the SQL tools have grown. I clearly saw this as a pretty cool goal to Automagically define the AD Schema from CSVs. Once these other advanced SQL tools created an SQL Schema from a CSV I began to use Chrissy's Invoke-DbaQuery to create the SQL table and Import-DBACSV to bring the CSV data into SQL. If this was successful I would read the SQL schema to create the AD Schema for new Attributes. So the goal is to take any CSV and derive the Schema thru SQL tools to create SQL and ingest this CSV data per table. Then read the SQL Schema and create new AD Attributes via the New-ADObject to add these new attributes to the Active Directories Schema.

My dream is to get a partner that knows Active Directory well enough, loves PowerShell, and Major League Baseball to help me polish to present to the public on GitHub. I see no reason why this would not work with Azure AD as well. In the end, this new AD Data Science Module will be a training tool to train more people in PowerShell. It is not intended to awaken all Corporations to start extending their Active Directory schema which I feel is sadly too late as this could have been occurring for the last 23 years helping Enterprises manage their customer data. The goal is to entice and spark interest in someone to learn PowerShell and AD. The plan is to allow them to ingest their data which could be a copy of their existing corporate AD or any dataset of their choice to make it interesting for them to learn PowerShell.

AD is in every business across the world, the birth rate is down, and we have a woke messed-up society of new generations to support this planet going forward. We are very likely facing a serious shortage to support Active Directory with the worldwide numbers moving forward, On-prem, Hybrid, and pure Azure as well as this gets interesting when M$ Graph is becoming the new AD toolset. The more trained PowerShell and Active Directory folks the better off we are going to be. I have successfully ingested all the data from Major League Baseball's history as far back as 1870 and with over 21K plus players. Fascinating OU design structures by Country, Province|State, City, crazy Universal Groups based on Awards, Teams played for, Managers, and a ton of combinations make AD fun to work with if you like baseball and PowerShell.

I figured it was a hot mess and your words validated this hence why my OCD kicked in. Why I am not happy working with PowerShell 5.1 is a genetic defect I am born with. Classifying my problem as Sev1, Sev2, Sev3, etc is not even an issue only that I am here to help you solve this problem. I hope you enjoyed reading this. I am trying to prepare to offer this as a presentation in one of the PowerShell Meetup groups like Mike's North Carolina or Doug Finke's New York Group.

The next dataset I started working with was the PSGallery and when I started working with a different Schema I realized the need to automate the definition process of attributes from the source of record a CSV or many CSVs. I see no way at this point how to dynamically figure out if a new AD Attribute should be a multivalue attribute and will rely on being human with these. So as it stands this method now helps me define a Unicode single value string, an Integer, and a decimal value utilizing SQL Tools that rely on SQL SMO, hence my issue. Why it works only with PowerShell 5.1 is not understood at this time. I am mostly hoping this bug is NOT causing Chrissy's DBATools team issues. I have not tried this outside my Windows Server 2022 Domain controller and really don't want to add another rabbit hole trying Windows 11. I am willing to start fresh with a newly built Windows 2019 or 2022 server box if this helps you resolve this.