none
C# CmdLet oder Script Code RRS feed

  • Frage

  • Hallo zusammen,

    eine Frage: Wo liegen die Vorteile ein CmdLet in C# zu entwickeln und einzubinden, im Gegensatz zu einer Funktion mit cmdLetBinding direkt in einer psm1 datei?

    Dienstag, 29. Oktober 2013 16:13

Antworten

  • Richtig, ein Vorteil ist die Geschwindigkeit, aber in der Praxis war das nicht der Grund, warum bei diverse Projekten C# cmdlets den Scripts cmdlets vorgezogen wurden.

    Eine „richtige“ Programmiersprache bietet viel mehr Möglichkeiten, Code zu organisieren und wieder zu benutzen.

    • In C# entwickelte Cmdlets sind Klassen. Wenn einige oder alle cmdlets eines bestimmten Modules ähnliche Parameter haben oder Basisfunktionen implementiert bekommen sollen, kann man das in der Basisklasse definieren. Das kann die Pflege wesentlich vereinfachen.
    • XML Serialisierung eigener Klassen ist in PowerShell nur schwer nachzubilden
    • LINQ kann Code stark vereinfachen
    • Man hat eine richtige IDE und nicht nur einen Script Editor
    • Letzter Punkt macht Debuggen und Testen (Unit Test) viel einfacher oder erst möglich

    Somit ist es in den meisten Fällen die zu erwartende Komplexität des Projekts, die über C# oder Script cmdlets entscheidet.


    -Raimund


    Montag, 4. November 2013 18:11
  • Kurz gesagt Geschwindigkeit und ein paar wenige zusätzliche Möglichkeiten in C#.

    C# Cmdlets sind Compiliert und werden schneller in den Speicher geladen , als Cmdlets die man in PowerShell Programmiert.

    Ein Cmdlet das man in der PowerShell Script Sprache erstellt, muss beim ersten Aufruf von seiner Textform in eine Binärform Compiliert werden.
    Dies führt dazu, dass beim ersten verwenden eines solchen Script-Cmdlet die Performance schlecht ist.
    Wenn das Script-Cmdlet mehrfach oder oft verwendet wird, sollte das keinen unterschied mehr machen, da PowerShell dieses Script-Cmdlet dann schon im Speicher hat.

    PowerShell Script Code kann z.B. nicht auf die Windows API zugreifen. Dies ist manchmal nötig um tief in das Betriebssystem zu greifen, um an Funktionen heran zu kommen die das .NET Framework nicht abdeckt.
    Hier muss im PowerShell Script Code C# Code (oder andere .NET Code) eingebettet (verschachtelt) werden, der dann wiederum beim ersten Aufruf zusätzlich im Hintergrund compiliert wird.

    Mit dieser Technik des eingebetteten C# Code kann man genauso alles erreichen wie mit C# selbst.
    Es ist aber langsamer.
    Und wenn man sowieso C# einbetten muss warum dann nicht alles in C# schreiben? ;-)

    PowerShell Provider für PSDrives oder WMI müssen in C# geschrieben werden da Sie als DLL geladen werden. Aber das sind Provider und keine Cmdlets.


    Meine PowerShell Artikel, Buchtipps und kostenlose PowerShell Tutorials + E-Books
    Mein deutscher PowerShell Blog
    Mein 21 Teiliger PowerShell Video Grundlehrgang
    Deutsche PowerShell Videos auf Youtube
    Folge mir auf:
    Twitter | Facebook | Google+ | Deutsches PowerShell Forum (TechNet)

    • Bearbeitet Peter Kriegel Freitag, 1. November 2013 07:53
    • Als Antwort vorgeschlagen Peter Kriegel Mittwoch, 6. November 2013 06:11
    • Als Antwort markiert Alex Pitulice Mittwoch, 6. November 2013 11:59
    Freitag, 1. November 2013 07:51

Alle Antworten

  • Kurz gesagt Geschwindigkeit und ein paar wenige zusätzliche Möglichkeiten in C#.

    C# Cmdlets sind Compiliert und werden schneller in den Speicher geladen , als Cmdlets die man in PowerShell Programmiert.

    Ein Cmdlet das man in der PowerShell Script Sprache erstellt, muss beim ersten Aufruf von seiner Textform in eine Binärform Compiliert werden.
    Dies führt dazu, dass beim ersten verwenden eines solchen Script-Cmdlet die Performance schlecht ist.
    Wenn das Script-Cmdlet mehrfach oder oft verwendet wird, sollte das keinen unterschied mehr machen, da PowerShell dieses Script-Cmdlet dann schon im Speicher hat.

    PowerShell Script Code kann z.B. nicht auf die Windows API zugreifen. Dies ist manchmal nötig um tief in das Betriebssystem zu greifen, um an Funktionen heran zu kommen die das .NET Framework nicht abdeckt.
    Hier muss im PowerShell Script Code C# Code (oder andere .NET Code) eingebettet (verschachtelt) werden, der dann wiederum beim ersten Aufruf zusätzlich im Hintergrund compiliert wird.

    Mit dieser Technik des eingebetteten C# Code kann man genauso alles erreichen wie mit C# selbst.
    Es ist aber langsamer.
    Und wenn man sowieso C# einbetten muss warum dann nicht alles in C# schreiben? ;-)

    PowerShell Provider für PSDrives oder WMI müssen in C# geschrieben werden da Sie als DLL geladen werden. Aber das sind Provider und keine Cmdlets.


    Meine PowerShell Artikel, Buchtipps und kostenlose PowerShell Tutorials + E-Books
    Mein deutscher PowerShell Blog
    Mein 21 Teiliger PowerShell Video Grundlehrgang
    Deutsche PowerShell Videos auf Youtube
    Folge mir auf:
    Twitter | Facebook | Google+ | Deutsches PowerShell Forum (TechNet)

    • Bearbeitet Peter Kriegel Freitag, 1. November 2013 07:53
    • Als Antwort vorgeschlagen Peter Kriegel Mittwoch, 6. November 2013 06:11
    • Als Antwort markiert Alex Pitulice Mittwoch, 6. November 2013 11:59
    Freitag, 1. November 2013 07:51
  • Richtig, ein Vorteil ist die Geschwindigkeit, aber in der Praxis war das nicht der Grund, warum bei diverse Projekten C# cmdlets den Scripts cmdlets vorgezogen wurden.

    Eine „richtige“ Programmiersprache bietet viel mehr Möglichkeiten, Code zu organisieren und wieder zu benutzen.

    • In C# entwickelte Cmdlets sind Klassen. Wenn einige oder alle cmdlets eines bestimmten Modules ähnliche Parameter haben oder Basisfunktionen implementiert bekommen sollen, kann man das in der Basisklasse definieren. Das kann die Pflege wesentlich vereinfachen.
    • XML Serialisierung eigener Klassen ist in PowerShell nur schwer nachzubilden
    • LINQ kann Code stark vereinfachen
    • Man hat eine richtige IDE und nicht nur einen Script Editor
    • Letzter Punkt macht Debuggen und Testen (Unit Test) viel einfacher oder erst möglich

    Somit ist es in den meisten Fällen die zu erwartende Komplexität des Projekts, die über C# oder Script cmdlets entscheidet.


    -Raimund


    Montag, 4. November 2013 18:11