Come posso eseguire PowerShell con il runtime .NET 4?

Sto aggiornando uno script PowerShell che gestisce alcuni assembly .NET. Lo script è stato scritto per gli assembly creati su .NET 2 (la stessa versione del framework con cui è in esecuzione PowerShell), ma ora deve funzionare con gli assembly .NET 4 e .NET 2.

Poiché .NET 4 supporta l'esecuzione di applicazioni basate su versioni precedenti del framework, sembra che la soluzione più semplice sia avviare PowerShell con il runtime .NET 4 quando devo eseguirlo su assembly .NET 4.

Come posso eseguire PowerShell con il runtime .NET 4?

PowerShell (il motore) funziona correttamente con .NET 4.0. PowerShell (l'host della console e ISE ) no, semplicemente perché sono stati compilati con versioni precedenti di .NET. C'è un'impostazione del registro che cambierà il framework .NET caricato a livello di sistema , che a sua volta consentirà a PowerShell di utilizzare le classi .NET 4.0:

reg add hklm\software\microsoft\.netframework /v OnlyUseLatestCLR /t REG_DWORD /d 1
reg add hklm\software\wow6432node\microsoft\.netframework /v OnlyUseLatestCLR /t REG_DWORD /d 1

Per aggiornare solo ISE per utilizzare .NET 4.0, è possibile modificare il file di configurazione ($ psHome \ powershell_ise.exe.config) in modo che abbia un blocco come questo:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <startup>
      <supportedRuntime version="v4.0.30319" />
    </startup>
</configuration>

È possibile creare applicazioni .NET 4.0 che chiamano PowerShell usando l'API PowerShell (System.Management.Automation.PowerShell) bene, ma questi passaggi aiuteranno gli host PowerShell integrati a funzionare in .NET 4.0.

Rimuovere le chiavi del Registro di sistema quando non sono più necessarie. Queste sono chiavi a livello di macchina e migrano forzatamente TUTTE le applicazioni su .NET 4.0, anche le applicazioni che utilizzano .net 2 e .net 3.5

La migliore soluzione che ho trovato è nel post sul blog Utilizzo delle versioni più recenti di .NET con PowerShell . Ciò consente l'esecuzione di powershell.exe con assembly .NET 4.

Basta modificare (o creare) in $pshome\powershell.exe.configmodo che contenga quanto segue:

<?xml version="1.0"?> 
<configuration> 
    <startup useLegacyV2RuntimeActivationPolicy="true"> 
        <supportedRuntime version="v4.0.30319"/> 
        <supportedRuntime version="v2.0.50727"/> 
    </startup> 
</configuration> 

Note aggiuntive sulla configurazione rapida:

Posizioni e file dipendono in qualche modo dalla piattaforma; tuttavia ti fornirà un'idea in linea di come far funzionare la soluzione per te.

• È possibile trovare la posizione di PowerShell sul computer eseguendo cd $pshome nella finestra Powershell (non funziona dal prompt di DOS).
  • Path sarà qualcosa di simile (esempio) C:\Windows\System32\WindowsPowerShell\v1.0\
• Il nome del file in cui inserire la configurazione è: powershell.exe.configse il tuo PowerShell.exeè in esecuzione (crea il file di configurazione se necessario).
  • Se PowerShellISE.Exeè in esecuzione, è necessario creare il file di configurazione associato comePowerShellISE.Exe.config

Si prega di essere MOLTO attenti a utilizzare l'approccio con chiave di registro. Queste sono chiavi a livello di macchina e migrano forzatamente TUTTE le applicazioni su .NET 4.0.

Molti prodotti non funzionano se migrati forzatamente e questo è un ausilio per i test e non un meccanismo di qualità della produzione. Visual Studio 2008 e 2010, MSBuild , turbotax e una serie di siti Web, SharePoint e così via non dovrebbero essere automatizzati.

Se è necessario utilizzare PowerShell con 4.0, questo dovrebbe essere fatto in base all'applicazione con un file di configurazione, è necessario verificare con il team di PowerShell il consiglio preciso. È probabile che ciò rompa alcuni comandi di PowerShell esistenti.

Se è necessario eseguire un solo comando, blocco di script o file di script in .NET 4, provare a utilizzare Activation Configuration Files da .NET 4 per avviare solo una singola istanza di PowerShell utilizzando la versione 4 del CLR.

Dettagli completi:

http://blog.codeassassin.com/2011/03/23/executing-individual-powershell-commands-using-net-4/

Un modulo di PowerShell di esempio:

https://gist.github.com/882528

Se sei ancora bloccato su PowerShell v1.0 o v2.0, ecco la mia variazione sulla risposta eccellente di Jason Stangroome.

Crea un punto powershell4.cmdnel tuo percorso con i seguenti contenuti:

@echo off
:: http://stackoverflow.com/questions/7308586/using-batch-echo-with-special-characters
if exist %~dp0powershell.exe.activation_config goto :run
echo.^<?xml version="1.0" encoding="utf-8" ?^>                 > %~dp0powershell.exe.activation_config
echo.^<configuration^>                                        >> %~dp0powershell.exe.activation_config
echo.  ^<startup useLegacyV2RuntimeActivationPolicy="true"^>  >> %~dp0powershell.exe.activation_config
echo.    ^<supportedRuntime version="v4.0"/^>                 >> %~dp0powershell.exe.activation_config
echo.  ^</startup^>                                           >> %~dp0powershell.exe.activation_config
echo.^</configuration^>                                       >> %~dp0powershell.exe.activation_config
:run
:: point COMPLUS_ApplicationMigrationRuntimeActivationConfigPath to the directory that this cmd file lives in
:: and the directory contains a powershell.exe.activation_config file which matches the executable name powershell.exe
set COMPLUS_ApplicationMigrationRuntimeActivationConfigPath=%~dp0
%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe %*
set COMPLUS_ApplicationMigrationRuntimeActivationConfigPath=

Ciò consentirà di avviare un'istanza della console PowerShell in esecuzione in .NET 4.0.

Puoi vedere la differenza sul mio sistema in cui ho PowerShell 2.0 esaminando l'output dei seguenti due comandi eseguiti da cmd.

C:\>powershell -ExecutionPolicy ByPass -Command $PSVersionTable

Name                           Value
----                           -----
CLRVersion                     2.0.50727.5485
BuildVersion                   6.1.7601.17514
PSVersion                      2.0
WSManStackVersion              2.0
PSCompatibleVersions           {1.0, 2.0}
SerializationVersion           1.1.0.1
PSRemotingProtocolVersion      2.1


C:\>powershell4.cmd -ExecutionPolicy ByPass -Command $PSVersionTable

Name                           Value
----                           -----
PSVersion                      2.0
PSCompatibleVersions           {1.0, 2.0}
BuildVersion                   6.1.7601.17514
CLRVersion                     4.0.30319.18408
WSManStackVersion              2.0
PSRemotingProtocolVersion      2.1
SerializationVersion           1.1.0.1

Ecco il contenuto del file di configurazione che ho usato per supportare gli assembly .NET 2.0 e .NET 4:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <!-- http://msdn.microsoft.com/en-us/library/w4atty68.aspx -->
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0" />
    <supportedRuntime version="v2.0.50727" />
  </startup>
</configuration>

Inoltre, ecco una versione semplificata del codice compatibile con PowerShell 1.0 che ho usato per eseguire i nostri script dagli argomenti passati nella riga di comando:

class Program {
  static void Main( string[] args ) {
    Console.WriteLine( ".NET " + Environment.Version );

    string script = "& " + string.Join( " ", args );
    Console.WriteLine( script );
    Console.WriteLine( );

    // Simple host that sends output to System.Console
    PSHost host = new ConsoleHost( this );
    Runspace runspace = RunspaceFactory.CreateRunspace( host );

    Pipeline pipeline = runspace.CreatePipeline( );
    pipeline.Commands.AddScript( script );

    try {
      runspace.Open( );
      IEnumerable<PSObject> output = pipeline.Invoke( );
      runspace.Close( );

      // ...
    }
    catch( RuntimeException ex ) {
      string psLine = ex.ErrorRecord.InvocationInfo.PositionMessage;
      Console.WriteLine( "error : {0}: {1}{2}", ex.GetType( ), ex.Message, psLine );
      ExitCode = -1;
    }
  }
}

Oltre alla gestione degli errori di base mostrata sopra, inseriamo anche trapun'istruzione nello script per visualizzare informazioni diagnostiche aggiuntive (simile alla funzione di risoluzione dell'errore di Jeffrey Snover ).

Le altre risposte risalgono a prima del 2012 e si concentrano sull'hacking di PowerShell 1.0 o PowerShell 2.0 per il targeting delle versioni più recenti di .NET Framework e Common Language Runtime (CLR).

Tuttavia, come è stato scritto in molti commenti, dal 2012 (quando è arrivato PowerShell 3.0) una soluzione molto migliore è installare la versione più recente di PowerShell . Mirerà automaticamente al CLR v4.0.30319. Ciò significa che .NET 4.0, 4.5, 4.5.1, 4.5.2 o 4.6 (previsto nel 2015) poiché tutte queste versioni sono sostituite sul posto l'una dall'altra. Utilizzare $PSVersionTableo consultare il thread Determinare la versione di PowerShell installata se non si è sicuri della propria versione di PowerShell.

Al momento in cui scrivo, la versione più recente di PowerShell è 4.0 e può essere scaricata con Windows Management Framework (link di ricerca di Google) .

In realtà, puoi far funzionare PowerShell usando .NET 4 senza influire su altre applicazioni .NET. Ho dovuto farlo per utilizzare la nuova proprietà "Host" di HttpWebRequest, tuttavia modificando "OnlyUseLatestCLR" si è rotto Fiddler in quanto non poteva essere utilizzato in .NET 4.

Gli sviluppatori di PowerShell hanno ovviamente previsto che ciò accadesse e hanno aggiunto una chiave di registro per specificare quale versione del Framework dovrebbe usare. Un piccolo problema è che è necessario assumere la proprietà della chiave di registro prima di modificarla, poiché anche gli amministratori non hanno accesso.

• HKLM: \ Software \ Microsoft \ Powershell \ 1 \ PowerShellEngine \ RuntimeVersion (64 bit e 32 bit)
• HKLM: \ Software \ Wow6432Node \ Microsoft \ Powershell \ 1 \ PowerShellEngine \ RuntimeVersion (32 bit su computer a 64 bit)

Modificare il valore di quella chiave sulla versione richiesta. Tieni presente, tuttavia, che alcuni snapin potrebbero non caricarsi più a meno che non siano compatibili con .NET 4 (WASP è l'unico con cui ho avuto problemi, ma in realtà non lo uso comunque). VMWare , SQL Server 2008 , PSCX, Active Directory (Microsoft e Quest Software ) e SCOM funzionano tutti bene.

Se non si desidera modificare il file di registro o i file app.config, un modo alternativo è quello di creare una semplice app console .NET 4 che imita ciò che fa PowerShell.exe e ospita PowerShell ConsoleShell.

Vedi l' opzione 2 - Hosting Windows PowerShell da solo

Innanzitutto, aggiungere un riferimento agli assiemi System.Management.Automation e Microsoft.PowerShell.ConsoleHost che si trovano in % programfiles% \ Reference Assembly \ Microsoft \ WindowsPowerShell \ v1.0

Quindi utilizzare il seguente codice:

using System;
using System.Management.Automation.Runspaces;
using Microsoft.PowerShell;

namespace PSHostCLRv4
{
    class Program
    {
        static int Main(string[] args)
        {
            var config = RunspaceConfiguration.Create();
                return ConsoleShell.Start(
                config,
                "Windows PowerShell - Hosted on CLR v4\nCopyright (C) 2010 Microsoft Corporation. All rights reserved.",
                "",
                args
            );
        }
    }
}

Proprio come un'altra opzione, l'ultima versione di PoshConsole include file binari destinati a .NET 4 RC (che funzionano perfettamente con la versione RTM) senza alcuna configurazione.

Esegui powershell.exe con COMPLUS_versionla variabile di ambiente impostata su v4.0.30319. Ad esempio, da cmd.exe o .bat-file:

set COMPLUS_version=v4.0.30319
powershell -file c:\scripts\test.ps1