Description
ManagementClass.GetStronglyTypedClassCode(...) generates strongly typed WMI wrapper classes via WMIGenerator.cs.
The generated nested collection class wraps ManagementObjectCollection, and the generated nested enumerator wraps ManagementObjectCollection.ManagementObjectEnumerator.
However, the generated collection implements only ICollection, and the generated enumerator implements only IEnumerator. Neither generated type implements IDisposable, even though both wrapped runtime types are disposable and release COM/WMI resources.
Current source
Current generator:
src/libraries/System.Management/src/System/Management/WMIGenerator.cs
GenerateCollectionClass() emits a collection with:
BaseTypes.Add("System.Object")
BaseTypes.Add("ICollection")
- field:
ManagementObjectCollection privColObj
GenerateEnumeratorClass() emits an enumerator with:
BaseTypes.Add("System.Object")
BaseTypes.Add("System.Collections.IEnumerator")
- field:
ManagementObjectCollection.ManagementObjectEnumerator privObjEnum
Wrapped runtime types:
src/libraries/System.Management/src/System/Management/ManagementObjectCollection.cs
ManagementObjectCollection : ICollection, IEnumerable, IDisposable
ManagementObjectCollection.ManagementObjectEnumerator : IEnumerator, IDisposable
- enumerator
Dispose() calls Marshal.ReleaseComObject(enumWbem)
Problem
The generated wrapper erases the disposable ownership contract.
Typical generated-code usage looks like normal managed collection enumeration, but under the covers it is wrapping WMI COM enumerators. Because the generated collection/enumerator do not implement IDisposable, consumer code has no obvious deterministic way to release the underlying ManagementObjectCollection / ManagementObjectEnumerator.
In long-running WMI monitoring or inventory services, this can delay COM release until GC/finalization and may contribute to:
- finalizer queue growth
- delayed
IEnumWbemClassObject release
- WMI provider pressure
WmiPrvSE.exe memory/resource growth
- RPC/DCOM resource exhaustion
- intermittent WMI query failures/timeouts
- retry storms that amplify resource pressure
This is a resource-lifetime correctness issue, not a feature request.
Expected behavior
Generated strongly typed WMI wrappers should preserve the disposable ownership contract of the wrapped System.Management types.
Possible fix:
- Generated collection should implement
IDisposable and dispose privColObj.
- Generated enumerator should implement
IDisposable and dispose privObjEnum.
- Tests should verify generated
CodeTypeDeclaration includes IDisposable for collection/enumerator and emits disposal of the wrapped fields.
Compatibility note
This is additive in generated source. It may affect consumers that diff exact generated output, but it exposes an ownership contract that already exists on the underlying runtime types and enables deterministic cleanup of COM-backed WMI resources.
Description
ManagementClass.GetStronglyTypedClassCode(...)generates strongly typed WMI wrapper classes viaWMIGenerator.cs.The generated nested collection class wraps
ManagementObjectCollection, and the generated nested enumerator wrapsManagementObjectCollection.ManagementObjectEnumerator.However, the generated collection implements only
ICollection, and the generated enumerator implements onlyIEnumerator. Neither generated type implementsIDisposable, even though both wrapped runtime types are disposable and release COM/WMI resources.Current source
Current generator:
src/libraries/System.Management/src/System/Management/WMIGenerator.csGenerateCollectionClass()emits a collection with:BaseTypes.Add("System.Object")BaseTypes.Add("ICollection")ManagementObjectCollection privColObjGenerateEnumeratorClass()emits an enumerator with:BaseTypes.Add("System.Object")BaseTypes.Add("System.Collections.IEnumerator")ManagementObjectCollection.ManagementObjectEnumerator privObjEnumWrapped runtime types:
src/libraries/System.Management/src/System/Management/ManagementObjectCollection.csManagementObjectCollection : ICollection, IEnumerable, IDisposableManagementObjectCollection.ManagementObjectEnumerator : IEnumerator, IDisposableDispose()callsMarshal.ReleaseComObject(enumWbem)Problem
The generated wrapper erases the disposable ownership contract.
Typical generated-code usage looks like normal managed collection enumeration, but under the covers it is wrapping WMI COM enumerators. Because the generated collection/enumerator do not implement
IDisposable, consumer code has no obvious deterministic way to release the underlyingManagementObjectCollection/ManagementObjectEnumerator.In long-running WMI monitoring or inventory services, this can delay COM release until GC/finalization and may contribute to:
IEnumWbemClassObjectreleaseWmiPrvSE.exememory/resource growthThis is a resource-lifetime correctness issue, not a feature request.
Expected behavior
Generated strongly typed WMI wrappers should preserve the disposable ownership contract of the wrapped
System.Managementtypes.Possible fix:
IDisposableand disposeprivColObj.IDisposableand disposeprivObjEnum.CodeTypeDeclarationincludesIDisposablefor collection/enumerator and emits disposal of the wrapped fields.Compatibility note
This is additive in generated source. It may affect consumers that diff exact generated output, but it exposes an ownership contract that already exists on the underlying runtime types and enables deterministic cleanup of COM-backed WMI resources.