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
Single Thread Apartment required for Enable-WSManCredSSP and Disable-WSManCredSSP #3353
When given -Role Client, these cmdlets attempt to make use of the IGroupPolicyObject COM interface. IGroupPolicyObject requires that it be called from a Single Thread Apartment. STA is not supported in CoreCLR, so these cmdlets will fail when using the Client role.
Ilya (@iSazonov) what is exactly the expectation for .NET Standard 2.0? Are there any missing APIs? Or just missing capability of the runtime? -- in that case it would be more about .NET Core 2.0 than .NET Standard 2.0.
Either way, I am not sure if we can make that happen in .NET Core 2.0 timeframe -- let's have that discussion in the new CoreFX issue. Is it something blocking PowerShell Core release? Is it something that PowerShell team (or community) is interested in contributing to CoreFX repo?
I didn't open a new issue in CoreFx repo on this topic. Currently we call ShellExecuteEx directly in MTA thread, it would have problems for some shell extensions that require COM, but it's fine for common uses, such as opening file exploere or a file based on its extension.
However, this issue seems indicating that it's blocking our remoting scenario, Hemant Mahawar (@HemantMahawar) and Joey Aiello (@joeyaiello), can you please weigh in and see if this will block PowerShell Core 6.0 RTM release?
In General, Windows still widely uses the COM as well as Forms that require STA. If .Net Core does not provide access to these subsystems, PowerShell will lose a lot of functionality. I would like to have Get-WmiObject.
I do not dare to open the CoreFX Issue because I do not know these APIs deeply.
Activity
iSazonov commentedon Mar 17, 2017
Related #2969
iSazonov commentedon Mar 18, 2017
CoreFX issue https://github.com/dotnet/corefx/issues/522 milestone is 1.0.0-rtm so I set "Waiting - NetStandard20"
karelz commentedon Mar 31, 2017
Ilya (@iSazonov) what is exactly the expectation for .NET Standard 2.0? Are there any missing APIs? Or just missing capability of the runtime? -- in that case it would be more about .NET Core 2.0 than .NET Standard 2.0.
Either way, I am not sure if we can make that happen in .NET Core 2.0 timeframe -- let's have that discussion in the new CoreFX issue. Is it something blocking PowerShell Core release? Is it something that PowerShell team (or community) is interested in contributing to CoreFX repo?
iSazonov commentedon Mar 31, 2017
Karel Zikmund (@karelz) We have some Issues here about this (2 or even more).
I believe Dongbo Wang (@daxian-dbw) can comment in depth. It seems Dongbo Wang (@daxian-dbw) already open such Issue in CoreFX repo.
daxian-dbw commentedon Mar 31, 2017
I didn't open a new issue in CoreFx repo on this topic. Currently we call
ShellExecuteExdirectly in MTA thread, it would have problems for some shell extensions that require COM, but it's fine for common uses, such as opening file exploere or a file based on its extension.However, this issue seems indicating that it's blocking our remoting scenario, Hemant Mahawar (@HemantMahawar) and Joey Aiello (@joeyaiello), can you please weigh in and see if this will block PowerShell Core 6.0 RTM release?
iSazonov commentedon Apr 2, 2017
In General, Windows still widely uses the COM as well as Forms that require STA. If .Net Core does not provide access to these subsystems, PowerShell will lose a lot of functionality. I would like to have Get-WmiObject.
I do not dare to open the CoreFX Issue because I do not know these APIs deeply.
alexandair commentedon Apr 2, 2017
Ilya (@iSazonov) Why do you need Get-WmiObject? What about using Get-CimInstance instead?
iSazonov commentedon Apr 2, 2017
Aleksandar Nikolić (@alexandair) In this discussion, it is important that both cmdlets use COM.