Bei der Konzeption der Windows PowerShell (WPS) stand folgender Gedanke im Vordergrund: Wie könnte eine Technologie gestaltet sein, die die Mächtigkeit von C# mit der Einfachheit einer Skriptsprache oder Shell verbindet? Die PowerShell ist deshalb architektonisch ein Aufsatz auf Typen, insbesondere denen aus dem .NET Framework. Der .NET-Zugriff war aufgrund der geänderten API von Microsofts Server-Produkten nötig, die Verwendung von Visual Studio und Hochsprachen für administrative Zielsetzungen war jedoch nicht zumutbar. Das Ergebnis war die mehrschichtige Architektur der PowerShell.
Die Befehle bilden dabei die Spitze einer Pyramide – mit einer starken Abhängigkeit zu der darunterliegenden Typbibliothek. Diese Beziehung wird bei der Installationsvoraussetzung für die verschiedenen PowerShell-Versionen deutlich, siehe auch die gleichnamige Tabelle. Die Verzahnung von installierten .NET-Bibliotheken, Systemkomponenten und PowerShell macht eine Verwendung der Windows PowerShell jenseits von Windows eigentlich unmöglich. Der Befehl »get-process
«
etwa basiert auf dem Typ "System.Diagnostics.Process". Wenn diese Klassen aber ausschließlich Windows-Betriebssystemen zur Verfügung stehen, fehlt der Befehlspyramide die Basis. Das ändert sich mit der neuen Konzeption von .NET Core.
Ein Nachteil der klassischen .NET-Architektur war und ist die Verteilung von Apps. Die Entwickler benötigen auf dem Zielsystem eine vorhandene und passende .NET-Framework-Version. Änderungen müssen auf die Ablaufumgebung abgestimmt werden. Im Prinzip bestimmt die Umgebung die Ausprägung der Anwendungen. Zudem ist die Fixierung auf Windows eine weitere Einschränkung.
.NET Core will diese Limitierungen durch einen modularen Aufbau überwinden. Eine Teilmenge des .NET Frameworks und der Common Language Runtime wurde in ein eigenes Paket
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.