Is the PowerShell ConsoleShell on .NET 4.0 approved for production?

Question

After reading several other blog posts and articles (references found below) there appear to be several ways to run PowerShell on .NET 4.0 but few are sufficient for our purposes. Due to how we deploy our software we cannot update the registry or change add an application. This leaves us with two options, create our own shell by using ConsoleShell or override PSHost. We would like to be able to use the first option, ConsoleShell, due to it's simplicity but would like to know what issues we may encounter and whether doing so is recommended.

Reference

Based on other questions I have seen that you can use the following methods to run PowerShell as .NET 4.0. None of these methods appear to be officially sanction by Microsoft but the first shown below is included as a work around in this Microsoft connect issue.

The options to run PowerShell in .NET 4.0 appear to include:

1. Update the app.config to include .NET 4.0 as supported
2. Add a registry setting to switch the version
3. Use ConsoleShell to host your own PowerShell Console
4. Implement your own PowerShell host, PSHost , as done by PoshConsole or Nuget

Answer 1

As far as it is not officially approved (to my knowledge), then nobody can approve it but you. If your scenario works and passes reasonable tests, approve and use it.

I use PowerShell on .NET 4.0 but with the option 4, and used to use the option 1, too (I do not like the option 2, personally). Thus, I approved it, production or not, I use it a lot and it works. I still use PowerShell on .NET 2.0 for two reasons: 1) PowerShell.exe starts faster (especially x64); 2) to be sure that part of my PowerShell development is compatible with .NET 2.

Another thought. If something does not work properly in PowerShell on .NET 2.0 (there are some issues, indeed, see Connect) then the fact "it is approved for production" itself does not help much. One has to overcome existing issues, .NET 2 or .NET 4 does not matter.

P.S. I should have mentioned that I tried the option 3 as well. I did not find use cases suitable for using it in my scenarios. But I did not find any issues in using ConsoleShell either.

P.P.S Yet another option. Make a copy of PowerShell.exe, rename it into MyConsoleShell.exe, use it together with MyConsoleShell.exe.config configured for .NET 4. As far as you are going to use a separate application anyway, then why not to consider this?

Answer 2

I'm a bit of a powershell N00b, but I threw this together as a way of forcing an arbitrary script to use .NET 4.0 in my script:

# Place this at the top of your script, and it will run as a .NET 4 ps script.
# #############################################################################
if ($PSVersionTable.CLRVersion.Major -lt 4) { try {
    $cfgPath = $Env:TEMP | Join-Path -ChildPath ([Guid]::NewGuid())
    mkdir $cfgPath | Out-Null
    "<configuration><startup useLegacyV2RuntimeActivationPolicy='true'><supportedRuntime version='v4.0'/></startup></configuration>" | Set-Content -Path $cfgPath\powershell.exe.activation_config -Encoding UTF8
    $darkMagic = 'COMPLUS_ApplicationMigrationRuntimeActivationConfigPath'
    $old = [Environment]::GetEnvironmentVariable($darkMagic)
    [Environment]::SetEnvironmentVariable($darkMagic, $cfgPath)
    & powershell.exe $MyInvocation.MyCommand.Definition $args
} finally {
    [Environment]::SetEnvironmentVariable($darkMagic, $old)
    $cfgPath | Remove-Item -Recurse
    return
}}
# ##############################################################################

# My script starts here:
echo "Your arguments are: $args "
echo "The CLR Major Version is : $($PSVersionTable.CLRVersion.Major)"

It places a check in the beginning of the script, and if it's not .NET 4.0 it creates a configuration file, sets an environment variable and re-runs the powershell script so that it runs under .NET 4.0.

it does incur a bit of a startup time penalty of about a second or so on my pc, but at least it works :)