-
Notifications
You must be signed in to change notification settings - Fork 7.6k
Discussion: Defaults for Thread.ApartmentState #6908
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@bergmeister Please see very usefull discussion in #4772 PowerShell Committee Conclusion #4953 |
PowerShell V1 was MTA because that was the .NET default. We didn't really think about it much and just decided to go with the default. It turned out that STA was preferred for WinForms and absolutely required for XAML. (In practice, it seem 8000 s that a fair number of people do build GUIs in PowerShell. Sapien even has a WinForms designer for PowerShell.) Since the ISE is a XAML application, it had to be STA. For consistency in experience we decided to also change the console host to be STA. But there might have been some things that required MTA so we gave you the option to start the console host with either MTA or STA. Likewise in the API, if you use the default behaviour of creating a new thread for each command, you can run individual commands either STA or MTA. |
And now that XAML for .NET Core 3 has been announced, we should make sure that we at least have the option to run STA (and preferably make it the default.) |
Thanks for the detailed explanation. Would it make sense to switch to STA as a default already before |
Is this answered? Can I close it? |
@TravisEz13 For me it is sufficiently answered but you might want to consider opening an issue to re-implement |
#7216 created |
This is to discuss and potentially document current behaviour (that is inconsistent with Windows PowerShell). Maybe some porting work was forgotten since the APIs were initially not available in .Net Core 1.
When creating a new PowerShell instance using
[Management.Automation.PowerShell]::Create()
(or when creating a new runspace using[runspacefactory]::CreateRunspace()
), then PowerShell Core and Windows PowerShell are both inMTA
mode. This seems to be reasonable.When being in the shell of
PowerShell Core
, the default ApartmentState is alsoMTA
, which seems OK as well at first.However, Windows PowerShell is in
STA
mode by default andpowershell.exe
even has anMTA
andSTA
switch, which PowerShell Core does not have.My questions:
STA
chosen to be the default when being in a shell or ConsoleHost of Windows PowerShell? If there was a reason, we should reconsider it for PowerShell Core. I should add though that this inconsistency could lead to a situation that is difficult to debug (we had a case where execution in the shell was fine but when using our PowerShell runner that uses the PowerShell APIs, we were experiencing threading issues and scratching our heads for some time what the reason could be until we found out about the inconsistency in Windows PowerShell)pwsh
need anSTA
command line option? In our case we can workaround it by setting it ourselves by setting it in theInitialSessionState
that we then pass toPowerShell.Create()
The text was updated successfully, but these errors were encountered: