Merged PR 780953: Workaround for WMI issue caused by SQL Setup not fully uninstalling the SQL W...

Workaround for WMI issue caused by SQL Setup not fully uninstalling the SQL WMI Provider (SQL 2019 and earlier)

The issue is described on [Github](#83), but basically it's like this:
- SQL Setup does not uninstall completely the SQL WMI Provider
- SMO has logic (heuristic) to figure out the proper WMI Namespace to connect to
- The left-over namespace (of the uninstalled SQL) is still there, but not functional
- The current heuristic would just use it
- However, when WMI queries happen things fall apart because there is no code to backup that namespace

The experience, at least when the WMI object is used from PowerShell is just a bunch of empty fields, which are super confusing.

The fix is just about using a slightly different (and hopefully equally lightweight and reliable) WMI query: if that works, odds are that we hit the right/valid namespace.

Out of scope:
- Trying to make the whole probing logic (currently on 8 namespaces) parallel (the code in the WMI classes is not very thread-safe from what I see, so the change to do stuff in parallel would require a little more work... and also a bit of profiling to confirm it's really needed)

Author: Matteo-T

ChangeLog.md

@@ -3,6 +3,8 @@
 Update this document for internal and externally visible changes. The public change log is on github. Put most recent changes first.
 Once we push a new version to nuget.org add a double hash header for that version.
 
+- Fixed heuristic in [Wmi.ManagedComputer](https://github.com/microsoft/sqlmanagementobjects/issues/83) to determine the correct WMI namespace to connect to,
+  to workaround a bug where SQL Setup setup does not fully uninstall the SQL WMI Provider.
 - Update `ConnectionManager.InternalConnect` to retry connection in response to error 42109 (serverless instance is waking up)
 
 ## 161.47008.0

src/Microsoft/SqlServer/Management/Smo.Wmi/ManagedComputer.cs

@@ -287,8 +287,16 @@ Exception TryConnectUsingPath(ManagementPath path, out bool unrecoverableExcepti
             {
                 m_ManagementScope.Path = path;
                 m_ManagementScope.Connect();
-                // Double-check that provider exists.
-                new ManagementObject(m_ManagementScope, new ManagementPath("Win32Provider.Name=\"MSSQL_ManagementProvider\""), new ObjectGetOptions());
+
+                // Runs a dummy query (and ideally quick!) to check whether the SQL WMI Provider exists or not
+                //
+                // Note: we do this because a simple check like
+                //   new ManagementObject(m_ManagementScope, new ManagementPath("Win32Provider.Name=\"MSSQL_ManagementProvider\""), new ObjectGetOptions());
+                // may be be inconclusive due to a bug in SQL Setup (2019 and earlier), where the WMI Provider is not property uninstalled when SQL was installed.
+                using (var mos = new ManagementObjectSearcher(m_ManagementScope, new ObjectQuery("SELECT SQLServiceType FROM SqlService WHERE SQLServiceType = 0")))
+                {
+                    _ = mos.Get().Count;
+                }
             }
             catch (ManagementException managementException)
             {