VSCode .net installer extension requires user to disable powershell scripting excetion policy in advance

[jacdavis]

Describe the bug.

Powershell disables script execution by default. The .net installer vscode extension is implemented as a powershell extension. That means it cannot work unless the user manually disables ps execution policy in advance. For users without powershell experience, this isn't a great experience.

REQUEST: execute the script with execution policy by-passed. (powershell -ExcecutionPolicy Bypass squid.ps1). Admin is still required to install, but this will get rid of the confusing error message unless powershell is disabled by group policy

[baronfel]

Some reference docs for us.

Based on my reading, the main difference between bypass and unrestricted is that

If you run an unsigned script that was downloaded from the internet, you're prompted for permission before it runs.

That doesn't seem like a huge change, but will this still verify the signature of the script that we've downloaded - it's been pre-signed and it might feel like a security take-back if we lose that.

[jacdavis]

I think there is an option to only allow signed scripts too. The issue is it prompting for user input and the user not realizing it. Is the script execution even tied to a console where they can give input?

[nagilson]

There are language modes, which constrain powershell language features, and then execution policies, which constrain running scripts in general. I have had to set flags to enable running scripts by default from a powershell terminal, but there is no documentation indicating anything but that the language mode default is full language, or unrestricted. I also tried a sandbox and it was Full by default.

'FullLanguage is the default language mode for default sessions on all versions of Windows.'
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_language_modes?view=powershell-7.4&viewFallbackFrom=powershell-7.3#:~:text=The%20FullLanguage%20mode%20permits%20all%20language%20elements%20in%20the%20session.%20FullLanguage%20is%20the%20default%20language%20mode%20for%20default%20sessions%20on%20all%20versions%20of%20Windows.

What causes our error to trigger is not Get-ExecutionPolicy but ExecutionContext.SessionState.LanguageMode.

We should try to set the execution policy to bypass instead of restricted in our code as it prompts a dialogue for permission by default on unrestricted which could be the cause of unknown failures/timeouts, which is an awesome insight from @jacdavis. Even if the script is signed.
Sadly this option does not seem to exist to bypass language mode like how you can for 1 script via execution policy.

The error that spawned this issue triggers by checking the language mode:

Your machine policy ConstrainedLanguage disables PowerShell language features that may be needed to install .NET. Read more at: https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_language_modes?view=powershell-7.3. If you cannot safely and confidently change the execution policy, try setting a custom existingDotnetPath following our instructions here: https://github.com/dotnet/vscode-dotnet-runtime/blob/main/Documentation/troubleshooting-runtime.md.

There is code I wrote that just fails it if ExecutionContext.SessionState.LanguageMode is set to ConstrainedLanguage or NoLanguage.

vscode-dotnet-runtime/vscode-dotnet-runtime-library/src/Acquisition/AcquisitionInvoker.ts

Line 195 in ef5299b

if(languageMode === 'ConstrainedLanguage' || languageMode === 'NoLanguage')

I dont think those 2 to 4 daily people you see with that error are going to go away. The code is failing on them because it sees their language mode is restricted which is not by default and is set by a SysAdmin. If the install script team knows if we can run the script in a way with a constrained language mode, then we could do that, but that sounds impossible.