Powershell: Decouple dependency on Microsoft.Management.Infrastructure

Created on 5 Dec 2018  路  8Comments  路  Source: PowerShell/PowerShell

Microsoft.Management.Infrastructure.dll and namespace is for the WMIv2 capabilities which include the CIM cmdlets, DSC dependency, as well as integration with the engine to handle CIM types as first class citizens.

MMI.dll is not Open Source (and no plans to be OSS). We should see about breaking this dependency so that MMI is a separate module. This will likely be a big breaking change for anyone using CIM.

Area-Cmdlets-Management Area-DSC Area-Maintainers-Build Breaking-Change Issue-Code Cleanup WG-Engine

Most helpful comment

Will the module still be delivered as part of the install on Windows. If so then I don't see a problem as the functionality is still available and usable. if the module has to be downloaded and installed separately then that will cause problems.

CIM is incredibly useful on Windows, in practice it doesn't exist on other platforms, so anything that made it harder to use would have a big impact on Windows administrators. From the dashboard the majority of PowerShell usage is Linux based - mainly I suspect because Windows PowerShell is still available. if you want PowerShell to be viewed as a viable alternative to Windows PowerShell the CIM functionality must be easily accessible and usable

All 8 comments

Will the module still be delivered as part of the install on Windows. If so then I don't see a problem as the functionality is still available and usable. if the module has to be downloaded and installed separately then that will cause problems.

CIM is incredibly useful on Windows, in practice it doesn't exist on other platforms, so anything that made it harder to use would have a big impact on Windows administrators. From the dashboard the majority of PowerShell usage is Linux based - mainly I suspect because Windows PowerShell is still available. if you want PowerShell to be viewed as a viable alternative to Windows PowerShell the CIM functionality must be easily accessible and usable

@RichardSiddaway I think this would be solved by https://github.com/PowerShell/PowerShell/issues/5681

What time is it planned?
Is the breaking change approved by PowerShell Core Committee?

I'm still extremely apprehensive about how this will be received. If the #5681 approach is adopted it should have a LOT of advance publicity to explain what's happening. This needs to be explained to the PowerShell community in great detail and early enough that people know and expect the changes. If this is just sprung on the community PowerShell will take a huge credibility hit

Previously we discussed removing dependency on OMI native client library #8233. Seems MSFT team want to remove all dependencies on native libraries. This intention looks too laborious and perhaps too early.
First, removing dependency on OMI native client library was postponed. Second, we can't get rid of Microsoft.PowerShell.Native until CoreFX team does native marshaling for Unix-s. Finally, getting rid of MMI is too painful and maybe we should wait for EOL of Windows 7.

This is not in scope for 6.2 release. Probably not 6.3 either.

this semi ties in with #1979 tagging that for visibility there too

Could the README be updated to indicate the non-open source licensing?

Was this page helpful?
0 / 5 - 0 ratings