Wie kann ich PowerShell mit der .NET 4-Laufzeit ausführen?

Ich aktualisiere ein PowerShell-Skript, das einige .NET-Assemblys verwaltet. Das Skript wurde für Assemblys geschrieben, die für .NET 2 erstellt wurden (dieselbe Version des Frameworks, mit dem PowerShell ausgeführt wird), muss jetzt jedoch sowohl mit .NET 4-Assemblys als auch mit .NET 2-Assemblys arbeiten.

Da .NET 4 das Ausführen von Anwendungen unterstützt, die für ältere Versionen des Frameworks erstellt wurden, scheint es die einfachste Lösung zu sein, PowerShell mit der .NET 4-Laufzeit zu starten, wenn ich es für .NET 4-Assemblys ausführen muss.

Wie kann ich PowerShell mit der .NET 4-Laufzeit ausführen?

PowerShell (die Engine) läuft unter .NET 4.0 einwandfrei. PowerShell (der Konsolenhost und die ISE ) tun dies nicht, nur weil sie gegen ältere Versionen von .NET kompiliert wurden. Es gibt eine Registrierungseinstellung, die das systemweit geladene .NET Framework ändert , wodurch PowerShell wiederum .NET 4.0-Klassen verwenden kann:

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

Um nur die ISE für die Verwendung von .NET 4.0 zu aktualisieren, können Sie die Konfigurationsdatei ($ psHome \ Powershell_ise.exe.config) so ändern, dass sie einen Block wie den folgenden enthält:

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

Sie können .NET 4.0-Anwendungen, die PowerShell aufrufen, mithilfe der PowerShell-API (System.Management.Automation.PowerShell) erstellen. Diese Schritte helfen jedoch dabei, die sofort einsatzbereiten PowerShell-Hosts unter .NET 4.0 zum Laufen zu bringen.

Entfernen Sie die Registrierungsschlüssel, wenn Sie sie nicht mehr benötigen. Dies sind maschinenweite Schlüssel, die ALLE Anwendungen zwangsweise auf .NET 4.0 migrieren, auch Anwendungen, die .net 2 und .net 3.5 verwenden

Die beste Lösung, die ich gefunden habe, ist im Blogbeitrag Verwenden neuerer Versionen von .NET mit PowerShell . Dadurch kann Powershell.exe mit .NET 4-Assemblys ausgeführt werden.

Ändern Sie einfach (oder erstellen Sie es) $pshome\powershell.exe.configso, dass es Folgendes enthält:

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

Zusätzliche, schnelle Einrichtungshinweise:

Speicherorte und Dateien sind etwas plattformabhängig. Sie erhalten jedoch einen Überblick darüber, wie die Lösung für Sie funktioniert.

• Sie können den Speicherort von PowerShell auf Ihrem Computer finden, indem Sie ihn cd $pshome im Powershell-Fenster ausführen (funktioniert nicht über die DOS-Eingabeaufforderung).
  • Pfad wird so etwas wie (Beispiel) sein C:\Windows\System32\WindowsPowerShell\v1.0\
• Der Dateiname, in den die Konfiguration eingefügt werden soll, lautet: powershell.exe.configWenn Ihr PowerShell.exeausgeführt wird (erstellen Sie gegebenenfalls die Konfigurationsdatei).
  • Wenn ausgeführt PowerShellISE.Exewird, müssen Sie die zugehörige Konfigurationsdatei als erstellenPowerShellISE.Exe.config

Bitte seien Sie SEHR vorsichtig bei der Verwendung des Registrierungsschlüssel-Ansatzes. Dies sind maschinenweite Schlüssel, mit denen ALLE Anwendungen zwangsweise auf .NET 4.0 migriert werden .

Viele Produkte funktionieren nicht, wenn sie zwangsweise migriert werden. Dies ist eine Testhilfe und kein Mechanismus für die Produktionsqualität. Visual Studio 2008 und 2010, MSBuild , Turbotax und eine Vielzahl von Websites, SharePoint usw. sollten nicht automatisch migriert werden.

Wenn Sie PowerShell mit 4.0 verwenden müssen, sollte dies auf Anwendungsbasis mit einer Konfigurationsdatei erfolgen. Erkundigen Sie sich beim PowerShell-Team nach der genauen Empfehlung. Dadurch werden wahrscheinlich einige vorhandene PowerShell-Befehle beschädigt.

Wenn Sie in .NET 4 nur einen einzigen Befehl, Skriptblock oder eine einzelne Skriptdatei ausführen müssen, versuchen Sie, mithilfe von Aktivierungskonfigurationsdateien aus .NET 4 nur eine einzelne Instanz von PowerShell mit Version 4 der CLR zu starten.

Alle Einzelheiten:

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

Ein Beispiel für ein PowerShell-Modul:

https://gist.github.com/882528

Wenn Sie immer noch an PowerShell v1.0 oder v2.0 festhalten, finden Sie hier meine Variation der hervorragenden Antwort von Jason Stangroome.

Erstellen Sie eine Stelle powershell4.cmdauf Ihrem Pfad mit den folgenden Inhalten:

@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=

Auf diese Weise können Sie eine Instanz der Powershell-Konsole starten, die unter .NET 4.0 ausgeführt wird.

Sie können den Unterschied auf meinem System mit PowerShell 2.0 erkennen, indem Sie die Ausgabe der folgenden zwei Befehle untersuchen, die von cmd ausgeführt werden.

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

Hier ist der Inhalt der Konfigurationsdatei, mit der ich sowohl .NET 2.0- als auch .NET 4-Assemblys unterstützt habe:

<?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>

Außerdem ist hier eine vereinfachte Version des PowerShell 1.0-kompatiblen Codes, mit dem ich unsere Skripte aus den übergebenen Befehlszeilenargumenten ausgeführt habe:

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;
    }
  }
}

Zusätzlich zu der oben gezeigten grundlegenden Fehlerbehandlung fügen wir eine trapAnweisung in das Skript ein, um zusätzliche Diagnoseinformationen anzuzeigen (ähnlich der Resolve-Error- Funktion von Jeffrey Snover ).

Die anderen Antworten stammen aus der Zeit vor 2012 und konzentrieren sich darauf, PowerShell 1.0 oder PowerShell 2.0 zu "hacken", um auf neuere Versionen von .NET Framework und Common Language Runtime (CLR) abzuzielen.

Wie bereits in vielen Kommentaren erwähnt, besteht eine viel bessere Lösung seit 2012 (als PowerShell 3.0 auf den Markt kam) darin, die neueste Version von PowerShell zu installieren . Es wird automatisch auf CLR abzielen v4.0.30319. Dies bedeutet .NET 4.0, 4.5, 4.5.1, 4.5.2 oder 4.6 (voraussichtlich 2015), da alle diese Versionen direkt voneinander ersetzt werden. Verwenden $PSVersionTableSie den Thread Installierte PowerShell-Version ermitteln oder lesen Sie ihn, wenn Sie sich über Ihre PowerShell-Version nicht sicher sind.

Zum Zeitpunkt des Schreibens ist die neueste Version von PowerShell 4.0 und kann mit dem Windows Management Framework (Google-Suchlink) heruntergeladen werden .

Tatsächlich können Sie PowerShell mit .NET 4 ausführen, ohne andere .NET-Anwendungen zu beeinträchtigen. Ich musste dies tun, um die neue HttpWebRequest "Host" -Eigenschaft zu verwenden, aber das Ändern der "OnlyUseLatestCLR" brach Fiddler, da dies unter .NET 4 nicht verwendet werden konnte.

Die Entwickler von PowerShell haben dies offensichtlich vorausgesehen und einen Registrierungsschlüssel hinzugefügt, um anzugeben, welche Version des Frameworks verwendet werden soll. Ein kleines Problem ist, dass Sie den Registrierungsschlüssel in Besitz nehmen müssen, bevor Sie ihn ändern können, da selbst Administratoren keinen Zugriff haben.

• HKLM: \ Software \ Microsoft \ Powershell \ 1 \ PowerShellEngine \ RuntimeVersion (64 Bit und 32 Bit)
• HKLM: \ Software \ Wow6432Node \ Microsoft \ Powershell \ 1 \ PowerShellEngine \ RuntimeVersion (32-Bit auf 64-Bit-Computer)

Ändern Sie den Wert dieses Schlüssels in die erforderliche Version. Beachten Sie jedoch, dass einige Snapins möglicherweise nicht mehr geladen werden, es sei denn, sie sind .NET 4-kompatibel (WASP ist das einzige, mit dem ich Probleme hatte, aber ich verwende es trotzdem nicht wirklich). VMWare , SQL Server 2008 , PSCX, Active Directory (Microsoft und Quest Software ) und SCOM funktionieren einwandfrei.

Wenn Sie die Registrierungs- oder app.config-Dateien nicht ändern möchten, können Sie alternativ eine einfache .NET 4-Konsolen-App erstellen, die die Funktionen von PowerShell.exe nachahmt und die PowerShell ConsoleShell hostet.

Siehe Option 2 - Hosten von Windows PowerShell selbst

Fügen Sie zunächst einen Verweis auf die Assemblys System.Management.Automation und Microsoft.PowerShell.ConsoleHost hinzu, die sich unter % programfiles% \ Reference Assemblies \ Microsoft \ WindowsPowerShell \ v1.0 befinden

Verwenden Sie dann den folgenden Code:

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
            );
        }
    }
}

Genau wie eine andere Option enthält die neueste PoshConsole- Version Binärdateien für .NET 4 RC (die gegen die RTM-Version problemlos funktionieren) ohne Konfiguration.

Führen Sie einfach Powershell.exe mit der COMPLUS_versionUmgebungsvariablen auf aus v4.0.30319. Zum Beispiel aus cmd.exe oder .bat-Datei:

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