You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Decouple dependency on Microsoft.Management.Infrastructure #8397
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.
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
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 issue has not had any activity in 6 months, if there is no further activity in 7 days, the issue will be closed automatically.
Activity in this case refers only to comments on the issue. If the issue is closed and you are the author, you can re-open the issue using the button below. Please add more information to be considered during retriage. If you are not the author but the issue is impacting you after it has been closed, please submit a new issue with updated details and a link to this issue and the original.
Activity
RichardSiddaway commentedon Dec 5, 2018
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
SteveL-MSFT commentedon Dec 7, 2018
RichardSiddaway I think this would be solved by #5681
iSazonov commentedon Dec 8, 2018
What time is it planned?
Is the breaking change approved by PowerShell Core Committee?
RichardSiddaway commentedon Dec 8, 2018
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
iSazonov commentedon Dec 8, 2018
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.
SteveL-MSFT commentedon Dec 20, 2018
This is not in scope for 6.2 release. Probably not 6.3 either.
kilasuit commentedon Jan 22, 2019
this semi ties in with #1979 tagging that for visibility there too
hyandell commentedon Jan 23, 2019
Could the README be updated to indicate the non-open source licensing?
SteveL-MSFT commentedon Oct 19, 2023
We're working on a solution to this for 7.4
microsoft-github-policy-service commentedon Apr 16, 2024
This issue has not had any activity in 6 months, if there is no further activity in 7 days, the issue will be closed automatically.
Activity in this case refers only to comments on the issue. If the issue is closed and you are the author, you can re-open the issue using the button below. Please add more information to be considered during retriage. If you are not the author but the issue is impacting you after it has been closed, please submit a new issue with updated details and a link to this issue and the original.