Skip to content

Use in-proc winget in PowerShell module when running as SYSTEM - #3129

Merged
JohnMcPMS merged 3 commits into
microsoft:masterfrom
JohnMcPMS:system-ps
Apr 6, 2023
Merged

JohnMcPMS merged 3 commits into
microsoft:masterfrom
JohnMcPMS:system-ps

Conversation

@JohnMcPMS

@JohnMcPMS JohnMcPMS commented Apr 5, 2023 •

Copy link
Copy Markdown
Member

Change

This change uses the in-proc WinRT binaries and activation path when running as SYSTEM in the PowerShell module. It also makes Assert-WinGetPackageManager succeed as long as the OS version is high enough in that case.

There are two known caveats with this that could be addressed in a future change if needed:

  1. These newly added dlls are still dependent on the VC runtime, and thus will not work unless it has been installed. This seems acceptable for development scenarios. For shipping a module without this dependency, we will need to build a statically linked binary, but only on the internal, release pipeline.
  2. The code currently doesn't behave well in an STA thread, meaning that when used from SYSTEM the module requires running PowerShell with the MTA option.

Validation

Ran module in user and SYSTEM contexts using the Initialize-LocalWinGetModules.ps1 script.

Microsoft Reviewers: Open in CodeFlow
Microsoft Reviewers: Open in CodeFlow

@JohnMcPMS
JohnMcPMS requested a review from a team as a code owner April 5, 2023 00:02
@github-actions

This comment has been minimized.

/// <param name="expectedVersion">Expected version.</param>
public static void AssertWinGet(PSCmdlet psCmdlet, string expectedVersion)
{
// In-proc shouldn't have other dependencies and thus should be ok.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// In-proc shouldn't have other dependencies and thus should be ok.

In-proc requires unpackaged vc redistributable. Do we want to or have a good way to check that?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was caveat 1 from my PR summary. We will need to statically link the runtime in to be able to release this in a self-contained form. My hope is that we can do that with some form of property override on the internal release build. If that doesn't work, then a future PR will need to create a new build flavor that only changes to static linkage.

@yao-msft yao-msft left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@JohnMcPMS
JohnMcPMS merged commit bc9cb38 into microsoft:master Apr 6, 2023
@JohnMcPMS
JohnMcPMS deleted the system-ps branch April 6, 2023 18:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants