runtime: MissingMethodException raised from System.Management.WmiNetUtilsHelper during wmi call (.NET6 self-contained)

Description

SQL IaaS team and are now working on project migration to .NET6, here is an issue we identified with System.Management.WmiNetUtilsHelper during testing which seems to be a known issue, want to seek insights to see how we can resolve it:

Issue: Win32_Service WMI call failed with MissingMethodException  exception raised from 'System.Management.WmiNetUtilsHelper'

Reproduction Steps

Code example:

var mgmtScope = new ManagementScope(ReportingHelpers.StorageWmiCimNamespace);
mgmtScope.Connect();
ObjectQuery query = new ObjectQuery("SELECT * FROM Win32_Volume where DriveType = 3");
using (ManagementObjectSearcher searcher = new ManagementObjectSearcher(mgmtScope, query))
[Warning] ServerConfigurationsManagementStorageReportErrored: System.Exception: Error occurred when attempting to query SQL Server storage report
---> System.MissingMethodException: Cannot dynamically create an instance of type 'System.Management.WbemDefPath'. Reason: No parameterless constructor defined.
   at System.RuntimeType.ActivatorCache..ctor(RuntimeType )
   at System.RuntimeType.CreateInstanceDefaultCtor(Boolean , Boolean )
   at System.Activator.CreateInstance(Type type)
   at System.Management.MTAHelper.CreateInMTA(Type )
   at System.Management.ManagementPath.CreateWbemPath(String )
   at Microsoft.SqlServer.Management.ServerConfigurationsManagement.Common.StorageHelper.GetVolumes()
   at Microsoft.SqlServer.Management.ServerConfigurationsManagement.Queries.SqlQueries.QueryStorageReport(String sqlInstanceName, DrivesStatusMonitor drivesStatusMonitor)
   --- End of inner exception stack trace ---

Expected behavior

WMI call should works

Actual behavior

instead, raising exception

Regression?

No response

Known Workarounds

No response

Configuration

.NET6, windows server 2019, x64

Other information

No response

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 17 (10 by maintainers)

Most upvoted comments

so in this case if we want to keep trimming, we need to implement COM Wrappers by our own instead of applying existing COM ?

An even better approach would be to contribute the COM Wrapper changes to https://github.com/dotnet/runtime/tree/main/src/libraries/System.Management to make that library trim-compatible for everyone.

I believe it is possible to make your app work with BuiltInComInteropSupport=True and keeps trimming by manually preserving IL using DynamicDependencyAttributes or a ILLink.Descriptors.xml file. However, that approach is super fragile and not supported. If you took that approach, you would be responsible for keeping it working and bugs that you hit might not be fixed.