Powershell

Windows PowerShell in Action

Sascha — Wed, 13 Jun 2007 09:27:54 GMT

Von Manning Publications ist im Februar das Buch Windows PowerShell in Action von Bruce Payette erschienen, das ich durchaus lesenswert fand.

Unter [1] gibt es jetzt Probekapitel zum kostenfreien Download. Kapitel 1 gibt einen Einstieg in Windows Powershell. Anhang C erklärt die anfänglich etwas gewöhnungsbedürftige Grammatik von Powershell.

[1] Windows PowerShell in Action, http://www.manning.com/payette/

Powershell 03 - Das erste Cmdlet erstellen

Sascha — Fri, 02 Mar 2007 14:21:04 GMT

Die wichtigsten Namespaces im Überblick:

System.Management.Automation - This is the root namespace for Windows PowerShell. It contains the classes, enumerations, and interfaces required to implement custom cmdlets. In particular, the Cmdlet class is the base class from which all custom cmdlet classes must be derived from.
System.Management.Automation.Provider - This namespace contains the classes, enumerations, and interfaces required to implement a Windows PowerShell provider. In particular, the CmdletProvider class is the base class from which all Windows PowerShell provider classes must be derived.
Microsoft.PowerShell.Commands: This namespace contains the cmdlets implemented by Windows PowerShell. In a similar fashion, it is recommended that you create a [YourName].Commands namespace for those cmdlets that you implement.
System.Management.Automation.Host: This namespace contains the classes, enumerations, and interfaces that the cmdlet uses to interact with the Host application user.
System.Management.Automation.Internal: This namespace contains the base classes used by other namespace classes. For example, the CmdletMetadataAttribute class is the base class for the CmdletAttribute class.
System.Management.Automation.Runspaces: This namespace contains the classes, enumerations, and interfaces used to create an Windows PowerShell Runspace. In this context, the Windows PowerShell Runspace is the context in which one or more Windows PowerShell pipelines invoke cmdlets. That is, cmdlets do their work within the context of an Windows PowerShell Runspace.

Die Cmdlets in diesem und den nächsten Beispielen bieten Zugriff auf die ID3Tag-Informationen von MP3-Dateien. Ist nicht wirklich aufregend und ich bin mir sicher, dass ich nicht der erste bin, der auf diese Idee kommt. Um die verschiedenen Facetten der Cmdlet-Entwicklung zu betrachten, sollte das aber ausreichen.

Zum Auslesen der ID3Tags verwende ich die ID3Sharp Library von Chris Woods, die man auf sourceforge.net finden kann.

In einem Klassenbibliothek-Projekt müssen zunächst zwei Verweise hinzugefügt werden:

System.Management.Automation - siehe oben, wird immer gebraucht, wenn ein Cmdlet erstellt werden soll. Im Verweis hinzufügen-Dialog auf den Tab Durchsuchen wechseln und die Dll C:\Program Files\Reference Assemblies\Microsoft\WindowsPowerShell\v1.0\System.Management.Automation.dll auswählen
System.Configuration.Install.dll - wird für das Snap-in benötigt, das unser Cmdlet später in der Powershell registriert. Näheres später. Zu finden im Verweis hinzufügen-Dialog auf dem Tab .Net

Ein Cmdlet muss immer die Basisklasse System.Management.Automation.Cmdlet erweitern. In Powershell setzt sich der Name von Cmdlets aus einem Verb-Substantiv-Paar zusammen, so z.B. Get-Service, Move-Item, etc... Die Namensgebung ist durchgängig und dabei recht einfach zu durchschauen. Die gängigsten Verben finden sich, nach Kategorien gruppiert, in einigen Enumerationen im System.Management.Automation-Namensraum, z.B. VerbsCommon, VerbsSecurity. Diese sollte man nach Möglichkeit auch in eigenen Cmdlets verwenden, um Konsistenz in der Powershell-Benutzung für den Anwender zu wahren.

[Cmdlet(VerbsCommon.Get, "Mp3FileInfo")]
public class GetMp3FileInfoCommand : Cmdlet
{
    protected override void ProcessRecord()
    {
        // Ausgabeobjekte in die Pipeline geben
        WriteObject("Das Mp3FileInfo Cmdlet steht zur Verfügung");
    }
}

Um den Namen für das Cmdlet zu definieren, wird die öffentliche Klasse mit dem Cmdlet-Attribut versehen, dem Verb und Substantiv mitgegeben werden. Der Klassenname selbst ist unerheblich für die Verwendung in Powershell. Die einzige Methode, die überschrieben werden muss, is ProcessRecord(). In dieser Methode führt das Cmdlet seine Funktionen aus. Die Rückgabeobjekte werden dann mit Hilfe der WriteObject-Methode der Basisklasse in die Powershell-Pipeline geschrieben.

Das war's auch schon. Ziemlich unspektakulär.

Was zum ersten Test noch fehlt, ist ein Snap-in. Snap-ins registrieren benutzerdefinierte Cmdlets und Provider in der Powershell, damit diese von der Kommandozeile aus aufrufbar werden.

Zwei Sorten von Snap-ins stehen zur Auswahl. Ich wähle hier die einfache Variante, die die Klasse PSSnapIn erweitert. Diese Art von Snap-in registriert alle verfügbaren Cmdlets und Provider innerhalb der eigenen Assembly. Die Luxusvariante erweitert CustomPSSnapIn. Mit einem CustomPSSnapIn ist es möglich, nur bestimmte Cmdlets und/oder Provider innerhalb der eigenen, oder einer anderen Assembly zu registrieren.

Für das Snap-in wird eine neue Klasse zum Projekt hinzugefügt.

[RunInstaller(true)]
public class Mp3FileInfoSnapIn : PSSnapIn
{
    public Mp3FileInfoSnapIn()
        : base()
    {
    }

    /// <summary>
    /// Specify the name of the PowerShell snap-in.
    /// </summary>
    public override string Name
    {
        get
        {
            return "Mp3FileInfoSnapIn";
        }
    }

    /// <summary>
    /// Specify the vendor for the PowerShell snap-in.
    /// </summary>
    public override string Vendor
    {
        get
        {
            return "ESCde";
        }
    }

    /// <summary>
    /// Specify the localization resource information for the vendor. 
    /// Use the format: resourceBaseName,VendorName. 
    /// </summary>
    public override string VendorResource
    {
        get
        {
            return "Mp3FileInfoSnapIn,ESCde";
        }
    }

    /// <summary>
    /// Specify a description of the PowerShell snap-in.
    /// </summary>
    public override string Description
    {
        get
        {
            return "Registers all Mp3FileInfo Cmdlets.";
        }
    }

    /// <summary>
    /// Specify the localization resource information for the description. 
    /// Use the format: resourceBaseName,Description. 
    /// </summary>
    public override string DescriptionResource
    {
        get
        {
            return "Mp3FileInfoSnapIn,Registers all Mp3FileInfo Cmdlets.";
        }
    }
}

Sieht nach viel aus, ist es aber nicht. Das einzige, was der Entwickler hier zu tun hat, ist das Überschreiben von fünf String-Eigenschaften zur Beschreibung des Snap-ins. Der Rest wird von der Basisklasse geregelt. Wichtig ist, dass die Snap-in-Klasse von dem RunInstaller(true)-Attribut dekoriert wird. Das Attribut ist im System.ComponentModel Namespace definiert. Das RunInstaller-Attribut dient dem Installutil Tool bei der Installation der Assembly als Hinweis. Installutil.exe überprüft die angegebene Assembly mittels Reflexion und sucht alle Installer-Typen, bei denen für das RunInstaller-Attribut true festgelegt wurde. Anschließend führt das Tool für jede Instanz des Installer-Typs entweder die Install-Methode oder die Uninstall-Methode aus. PSSnapin ist indirekt von solch einem Installer abgeleitet, der in der referenzierten Assembly System.Configuration.Install.dll definiert ist.

Jetzt kann das Projekt kompiliert werden.

Custom Generic Collections oder: Filtern und Sortieren Teil 2

Sascha — Thu, 01 Mar 2007 17:58:23 GMT

Im letzten Post hatte ich eine List<T> mit Hilfe von IComparer<T> und Predicate<T> sortiert bzw. gefiltert. Das hatte so weit auch funktioniert. Das einzige, was mir an dieser Lösung noch nicht gefällt: Wenn ich mich dafür entscheiden sollte, meine MP3-Dateien jetzt nach einem Artist statt nach einem Titel zu filtern, muss ich zuerst eine entsprechende Funktion dazu erstellen, dann das Prädikat erzeugen, was auf diese Funktion zeigt, und dieses dann beim Aufruf der FindAll-Methode verwenden. Das gleiche beim Sortieren. Der vorhandene Mp3Comparer sortiert nur nach Artist. Neue Sortierung, neuer Comparer. Das muss doch einfacher gehen...

Die Lösung bietet Reflection. Zumindest in meinem Fall. Reflection ist Gift für die Performance, so dass man bei großen Listen evtl. ein Problem mit den Laufzeiten der Sort-Methode bekommt, wenn bei der Erstellung der Sortierordnung jedes Listenelement mehrfach mittels Reflection untersucht werden muss.

An den Comparer wird der Name der Eigenschaft übergeben, in der Compare-Methode wird die Eigenschaft und deren Werte per Reflection aus den zu vergleichenden Elementen ermittelt und das Ergebnis des Vergleichs zurückgeliefert.

Der bisherige MP3Comparer ist speziell auf den Vergleich von Instanzen des Typs ID3Tag ausgelegt, da er auf die Eigenschaften Titel und Artist angewiesen ist. Daher war er auch vom Typ IComparer<ID3Tag>. Der neue Comparer, den ich ReflectionComparer getauft habe, ist hingegen für alle Typen geeignet, daher vom Typ IComparer<T>. Der Comparer funktioniert aber nur, wenn der Typ der Eigenschaften, deren Werte verglichen werden sollen, selbst das IComparable Interface implementiert. Für die Standarddatentypen wie String, Int32, etc. ist dies erfüllt.

Der komplette Code für den neuen Comparer sieht nun folgendermaßen aus:

public class ReflectionComparer<T> : IComparer<T>
{
    SortType sortType;
    string sortPropertyName;

    public ReflectionComparer(string sortPropertyName)
    {
        this.sortPropertyName = sortPropertyName;
        this.sortType = SortType.Ascending;
    }

    public ReflectionComparer(string sortPropertyName,
        SortType sortType)
    {
        this.sortPropertyName = sortPropertyName;
        this.sortType = sortType;
    }

    #region IComparer<T> Members
    public int Compare(T x, T y)
    {
        // Mittels Reflection die Werte 
        //der Eigenschaften aus x und y bestimmen
        object valueX = x.GetType().GetProperty(
            sortPropertyName).GetValue(x, null);
        object valueY = y.GetType().GetProperty(
            sortPropertyName).GetValue(y, null);
        
        // Der Typ der Eigenschaft muss IComparable implementieren
        IComparable comparable = (IComparable)valueX;
        // Wert x mit Wert y vergleichen
        return (int)sortType * comparable.CompareTo(valueY);
    }
    #endregion
}

Auf sämtliche Fehlerbehandlung wurde in diesen Beispielen verzichtet. Gerade bei Reflection ist das aber wichtig, weil der Kompiler keinen Fehler meldet, wenn wir nach einem Feld sortieren wollen, das es gar nicht gibt. In der Form kann ich den IComparer wie gehabt an die Sort-Methode von List<T> anhängen. Ich möchte den Aufruf jedoch etwas intuitiver kapseln, so dass ich die Liste mit

id3Tags.Sort("Artist", SortType.Ascending);
id3Tags.Sort("Album", SortType.Descending);

entsprechend sortieren kann. Das heißt, ich muss eine eigene Generic Collection erzeugen. Es wäre jetzt naheliegend, diese CustomGenericCollection von System.Collections.Generic.List abzuleiten. Dies sollte man nach den Empfehlungen von Microsoft jedoch nicht tun, da List<T> eine große Anzahl von öffentlichen Methoden und Eigenschaften besitzt, die in den meisten Szenarien nicht relevant sind. Das heißt nicht, dass man nicht von List<T> erben könnte. Wenn man z.B. nur eine weitere Methode hinzufügen möchte, dann kann es schon Gründe geben, es auf diesem Weg machen. Es ist aber nicht möglich, sich in die Eventkette der Liste einzuklinken. Muss z.B. beim Löschen eines Elements aus der Liste ein Logeintrag erstellt werden, ist List<T> als Basisklasse nicht zu verwenden. Überhaupt bietet List<T> keine überschreibbaren Member, was auch ein Zeichen dafür ist, dass diese Klasse nicht zum vererben gemacht wurde. Auch sollten keine List<T> Objekte als Eigenschaften von Klassen nach außen gegeben werden.

FXCop meldet einen DoNotExposeGenericLists Fehler mit dem Hinweis: "System.Collections.Generic.List<T> is a generic collection designed for
performance not inheritance and, therefore, does not contain any virtual members. The following generic collections are designed for inheritance and
should be exposed instead of System.Collections.Generic.List<T>.
* System.Collections.ObjectModel.Collection<T>
* System.Collections.ObjectModel.ReadOnlyCollection<T>
* System.Collections.ObjectModel.KeyedCollection<TKey, TItem>"

Krzysztof Cwalina (Program Manager .Net Framework team at MS) hat in einem Blogpost "System.Collections vs. System.Collection.Generic and System.Collections.ObjectModel" die verschiedenen Collection-Klassen und -Interfaces in den verschiedenen Namespaces in einer Übersicht zusammengestellt. Auch sehr hilfreich war ein Auszug des Wrox Buches "Professional C# 2005"

Anders die Klasse Collection<T>, die in der MSDN als "base class for a generic collection" beschrieben wird. Diese gehört aber nicht zum Namensraum System.Collections.Generic, sondern findet sich in System.Collections.ObjectModel. Grund dafür ist eine gleichnamige, nichtgenerische Collection Klasse aus dem Microsoft.VisualBasic Namensraum, der bei Visual Basic Klassen, ebenso wie System.Collections.Generic, standardmäßig importiert wird und es dadurch zu Namenskonflikten kommen kann.
Nach aussen sind bei der Collection<T> Klasse nur die nötigsten Eigenschaften und Methoden verfügbar und intern kann die innere Liste über die Items-Eigenschaft abgegriffen werden. Zudem bietet Collection<T> überschreibbare Methoden zur Benachrichtigung bei Änderungen an der Liste, d.h. bei Hinzufügen, Aktualisieren und Löschen von Elementen. Das hört sich doch gut an, eine CustomGenericCollection ist dann schnell erstellt.

public class CustomGenericCollection<T> : System.Collections.ObjectModel.Collection<T>
    {
        protected override void InsertItem(int index, T item)
        {
            // Aktion, wenn Item hinzugefügt wird
            base.InsertItem(index, item);
        }
        
        public T[] ToArray()
        {
            return ((List<T>)base.Items).ToArray();
        }

        public void Sort(string sortPropertyName)
        {
            Sort(sortPropertyName, SortType.Ascending);
        }
        
        public void Sort(string sortPropertyName, SortType sortType)
        {
            ReflectionComparer<T> comparison = 
                new ReflectionComparer<T>(sortPropertyName, sortType);
            ((List<T>)base.Items).Sort(comparison);
        }
    }

Neben den zwei Sort-Methoden, die die innere Liste mit dem ReflectionComparer von oben aufrufen, wird zusätzlich noch die ToArray-Methode der inneren Liste nach außen geführt, die in Collection<T> der Schlankheit zuliebe eingespart wurde. In der Insert-Methode könnte man das Hinzufügen eines neuen Elements zur Liste protokollieren oder auch unterbinden.

Die Filterung sollte auch noch etwas einfacher vonstatten gehen. Das Vorgehen ist wieder ähnlich. Die bisherige Filtermethode, die mittels Prädikat an die FindAll-Methode der List<T> übergeben wurde, wollte ein Objekt vom Typ ID3Tag übergeben bekommen. Da der neue GenericFilter ebenfalls mit Reflection arbeitet, ist der Typ der generischen Filtermethode egal. Wenn eine Instanz von GenericFilter erzeugt wird, muss ihr im Konstruktor der Name der zu filternden Eigenschaft, der Vergleichswert sowie optional ein Operator mitgegeben werden. Der Code der Klasse GenericFilter sieht dann so aus:

internal class GenericFilter
{
    string filterPropertyName = "";
    string filterValue = "";
    FilterOperator filterOperator;

    public GenericFilter(string filterPropertyName, string filterValue)
    {
        this.filterPropertyName = filterPropertyName;
        this.filterValue = filterValue;
        this.filterOperator = FilterOperator.Contains;
    }

    public GenericFilter(string filterPropertyName, string filterValue, 
        FilterOperator filterOperator)
    {
        this.filterPropertyName = filterPropertyName;
        this.filterValue = filterValue;
        this.filterOperator = filterOperator;
    }

    public bool Filter<T>(T x)
    {
        // Mittels Reflection die Werte 
        // der Eigenschaften aus x und y bestimmen
        object valueX = x.GetType().GetProperty(
            filterPropertyName).GetValue(x, null);

        switch (filterOperator)
        {
            case FilterOperator.Contains:
                if (Convert.ToString(valueX).Contains(filterValue))
                    return true;
                break;
            case FilterOperator.Equals:
                if (Convert.ToString(valueX).Equals(filterValue))
                    return true;
                break;
            case FilterOperator.GreaterThan:
                if (Convert.ToInt32(valueX).CompareTo(Convert.ToInt32(filterValue)) > 0)
                    return true;
                break;
            case FilterOperator.LessThan:
                if (Convert.ToInt32(valueX).CompareTo(Convert.ToInt32(filterValue)) > 0)
                    return true;
                break;
            default:
                return false;
        }
        return false;
    }
}

Der Filter kann für Texteigenschaften die Operatoren Contains und Equals anwenden und für ganzzahlige Eigenschaften einen GreaterThan oder LessThan Vergleich anstellen. Auch hier wieder eine ziemlich laxe Fehlerbehandlung ;-)

Wie dem auch sei, jetzt muss nur noch die FindAll-Methode meiner CustomGenericCollection das Prädikat mit dem Verweis auf die neue Filter-Funktion erstellen und das dann an die FindAll-Methode der inneren Liste weiterreichen. Als Ergebnis wird ein Array vom Typ T nach außen gegeben.

public T[] FindAll(string filterPropertyName, string filterValue, FilterOperator filterOperator)
{
    GenericFilter genericFilter = new GenericFilter(filterPropertyName, filterValue, filterOperator);

    // Prädikat vorbereiten
    Predicate<T> filterGeneric = new Predicate<T>(genericFilter.Filter<T>);
    // Filtern und als Array zurückgeben
    return ((List<T>)base.Items).FindAll(filterGeneric).ToArray();
}

public T[] FindAll(string filterPropertyName, string filterValue)
{
    return FindAll(filterPropertyName, filterValue, FilterOperator.Contains);
}

Die Liste von ID3Tags muss noch auf den neuen Typ CustomGenericCollection umgestellt werden.

//List<ID3Tag> id3Tags = new List<ID3Tag>();
CustomGenericCollection<ID3Tag> id3Tags = new CustomGenericCollection<ID3Tag>();

Nun lässt sie sich anständig filtern:

ID3Tag[] filteredItemsArray;
filteredItemsArray = 
    id3Tags.FindAll("Year", "1990", FilterOperator.GreaterThan);
filteredItemsArray =
    id3Tags.FindAll("Title", "Love", FilterOperator.Contains);

Ich hätte die neuen Filter- und Sortiermethoden nicht unbedingt generisch halten müssen. Nimmt man den geringen Mehraufwand in Kauf, wird man mit hoher Wiederverwendbarkeit belohnt, wie der folgende und letzte Codefetzen zeigt. Was er tut, erahnen Sie sicherlich.

public class Person
{
    string nachname;
    string vorname;

    public Person(string nachname, string vorname)
    {
        this.nachname = nachname;
        this.vorname = vorname;
    }

    public string Nachname
    {
        get { return nachname; }
    }
    public string Vorname
    {
        get { return vorname; }
    }

    public override string ToString()
    {
        return String.Format("{0}, {1}", nachname, vorname);
    }
}

...

CustomGenericCollection<Person> persColl = 
    new CustomGenericCollection<Person>();
persColl.Add(new Person("Frietsch", "Sascha"));
persColl.Add(new Person("Schimmel", "Jochen"));
persColl.Add(new Person("Janczik", "Sebastian"));

persColl.Sort("Nachname", SortType.Descending);
Person[] persArray = persColl.ToArray();

persArray = persColl.FindAll("Vorname", "Sascha", FilterOperator.Equals);

Filtern von generischen Listen mit Hilfe von Prädikaten

Sascha — Thu, 01 Mar 2007 11:21:16 GMT

Nachdem ich meine Liste von ID3Tags jetzt sortieren kann, fehlt noch das Filtern einer generischen Liste.

Die Typen System.Collections.Generic.List und System.Array stellen eine Reihe von Methoden zur Verfügung, die einen einzigen Parameter vom Typ Predicate<T> erwarten.

Exists
Find
FindAll
FindIndex
FindLast
FindLastIndex
ForEach
RemoveAll
TrueForAll

Für meinen Filter will ich die FindAll Methode verwenden, die als Ergebnis eine List<T> liefert, welche nur die Elemente der Ursprungsliste enthält, die das übergebene Prädikat erfüllen.

Prädikate sind eines der neuen generischen Features, die seit Version 2.0 des .Net Frameworks zur Verfügung stehen. Der Delegat System.Predicate wird wie folgt definiert:

Public Delegate Function Predicate(Of T)(obj As T) As Boolean

Eine Funktion, die als Prädikat fungieren soll, muss also einen einzigen Parameter akzeptieren, der vom gleichen Typ sein muss, wie die Elemente der Liste, die mit Hilfe dieses Prädikats bearbeitet werden soll. Der Rückgabewert ist ein Booleanwert, der angibt, ob das untersuchte Element in die Ergebnismenge übernommen werden soll.

Um alle Instanzen von ID3Tags zu bekommen, deren Titel das Wort "Happy" enthält, könnte man einen Code in dieser Form verwenden:

string compareValue = "Happy";
List<ID3Tag> titleFilteredList = new List<ID3Tag>(); 
foreach (ID3Tag id3Tag in id3Tags)
{
    if (id3Tag.Title.Contains(compareValue))
    {
        titleFilteredList.Add(id3Tag);
    }
}

Alle Elemente der Ausgangsliste werden durchlaufen; wenn der Titel den gesuchten Wert enthält, wird das Element der Ergebnismenge angefügt. Achtung: in diesem Beispiel wird nur eine Referenz auf das Element in die Ergebnisliste angefügt, keine Kopie!

Die FindAll-Methode funktioniert vom Prinizip her genauso wie die Schleife im obigen Code. Das übergebene Prädikat entspricht der Überprüfung innerhalb der Schleife. Es bestimmt, was beim einzelnen Element geprüft werden soll. Zunächst muss also eine Funktion definiert werden, die ein Element vom Typ ID3Tag entgegennimmt und nach der Überprüfung des Elements einen booleschen Wert zurückgibt. Der Vergleichswert wird schon im Konstruktor der SearchFilter-Klasse übergeben.

internal class SearchFilter
    {
        // Vergleichswert
        private string compareValue = "";

        public SearchFilter(string compareValue)
        {
            this.compareValue = compareValue;
        }

        // Suche nach Teil von Titel
        public bool TitleContains(ID3Tag id3Tag)
        {
            return id3Tag.Title.Contains(compareValue);
        }
    }

Jetzt kann das Prädikat erzeugt und der FindAll()-Methode übergeben werden. Das Prädikat ist - als Delegat - lediglich die Adresse einer aufrufbaren Methode.

//Vergleichswert für Suche nach Titel im Konstruktor übergeben
SearchFilter titleSearchFilter = new SearchFilter("Happy");
// Prädikat vorbereiten
Predicate<ID3Tag> filterByTitle =
    new Predicate<ID3Tag>(titleSearchFilter.TitleContains);
// Liste mit gefiltertem Ergebnis
List<ID3Tag> titleFilteredList = id3Tags.FindAll(filterByTitle);

Die anderen Methoden, die ich oben erwähnt hatte und die ebenfalls ein Pedicate<T> als Parameter erwarten, funktionieren ähnlich. So iteriert Exists ebenfalls durch alle Elemente und gibt true zurück, wenn das Prädikat das erste mal für ein Element true zurückgibt. FindLastIndex durchläuft die Liste von hinten nach vorne und gibt den Index des Elements aus, bei dem das Prädikat das erste mal true zurückgibt, usw. Interessant sind auch die ForEach()- und RemoveAll()-Methoden.

Mit Prädikaten spart man sich den Code, um durch Elemente einer Liste zu iterieren. OK, vielleicht nicht so triftig, dieser Grund. Aber bezüglich Wiederverwendbarkeit und Austauschbarkeit zur Laufzeit haben Prädikate ihren Charme.

Sortieren von generischen Listen

Sascha — Wed, 28 Feb 2007 18:08:01 GMT

Ich war auf der Suche nach einem einigermaßen sinnvollen Beispiel für die Programmierung von Powershell Cmdlets. Das erste Cmdlet soll Informationen aus ID3Tags von MP3-Dateien auslesen. Man muss das Rad nicht jedesmal neu erfinden, daher verwende ich die Bibliothek ID3Sharp von Chris Woodbury, die man auf sourceforge.net finden kann.

Die MP3-Dateien aus einem Verzeichnis werden nacheinander eingelesen. Für jede Datei werden die Informationen aus dem ID3-Tag in einer Instanz vom Typ ID3Tag zurückgegeben. Diese besitzt lediglich einige öffentliche Eigenschaften für die gängigen Informationen wie Artist, Title, Album, etc. Diese einzelnen Instanzen von ID3Tags werden in einer generischen Liste gesammelt.

List<ID3Tag> id3Tags = new List<ID3Tag>();

Es wäre schön, auf diese Liste nun Filter und Sortierungen anzuwenden. Geht natürlich auch ;-)

Fangen wir mit dem Sortieren an. Die generische Klasse List<T> bietet von Haus aus eine Sort() Methode in drei möglichen Überladungen.

List<T>.Sort () ohne weitere Argumente verwendet den default comparer. Das bedeutet, dass der Typ T das IComparable- oder das generische IComparable-Interface implementieren muss. Da dies bei ID3Tag nicht der Fall ist, würde sich die Liste bei einem Sort()-Aufruf mit einer InvalidOperationException bedanken.

Für die beiden anderen Überladungen wird eine Vergleichsmethode benötigt, die als Parameter zwei Variablen vom Typ T verarbeiten muss, in unserem Falle also zwei Objekte vom Typ ID3Tag. Der Rückgabewert der Methode ist -1, 0 oder 1, je nachdem, ob x kleiner, gleich, oder größer y ist. Ich überlasse hier die Berechnung des Rückgabewertes der String.CompareTo()-Methode der Artist- bzw. Title-Eigenschaft.

Für die Sortierung List<T>.Sort (Generic Comparison) muss die Vergleichsmethode in einer statischen Methode mit den oben erwähnten Parameter definiert werden:

public static int CompareID3TagsByArtist(ID3Tag x, ID3Tag y)
{
    if (x.Artist == y.Artist)
        return x.Title.CompareTo(y.Title);
    else
        return x.Artist.CompareTo(y.Artist);
}

Diese Methode habe ich in einer Klasse SearchFilter erstellt. Der Aufruf zum Sortieren der Liste lautet daher:

id3Tags.Sort(SearchFilter.CompareID3TagsByArtist);

Die letzte Möglichkeit, List<T>.Sort(Generic IComparer), verstaut die Vergleichsmethode in einer eigenen Klasse, die das generische IComparer<T>-Interface implementiert. Um das Interface zu implementieren, muss exakt eine Methode erstellt werden - die Vergleichsmethode. Die ganze Klasse sieht dann so aus:

internal class Mp3Comparer : IComparer<ID3Tag>
{
    #region IComparer<ID3Tag> Members

    public int Compare(ID3Tag x, ID3Tag y)
    {
        if (x.Artist == y.Artist)
            return x.Title.CompareTo(y.Title);
        else
            return x.Artist.CompareTo(y.Artist);
    }
    #endregion
}

Für den Sortieraufruf muss dann ein Objekt vom Type Mp3Comparer erzeugt werden, welches an die Sortmethode übergeben wird.

Mp3Comparer mc = new Mp3Comparer();
id3Tags.Sort(mc);

Als letztes Schmankerl fehlt noch ein aufsteigendes oder absteigendes Sortieren. Dafür lässt sich der Code für die Mp3Comparer Klasse zum Beispiel wie folgt ändern:

#region IComparer<ID3Tag> Members

public int Compare(ID3Tag x, ID3Tag y)
{
    if (x.Artist == y.Artist)
        return (int)sortType * x.Title.CompareTo(y.Title);
    else
        return (int)sortType * x.Artist.CompareTo(y.Artist);
}

#endregion

public Mp3Comparer()
{
    this.sortType = SortType.Ascending;
}

public Mp3Comparer(SortType sortType)
{
    this.sortType = sortType;
}

private SortType sortType;
public enum SortType {Descending = -1, Ascending = 1}

Es ist ein neuer Konstruktor hinzugekommen, der eine Sortierrichtung als Parameter akzeptiert. Ist ein Nicht-Standardkonstruktor definiert, muss auch der Standardkonstruktor explizit angegeben werden. Die bisherige Sortierrichtung war aufsteigend. Dies soll auch der Standardwert sein, wenn keine Richtung angegeben wurde. Soll absteigend sortiert werden, wird der Rückgabewert von Compare gerade mit -1 multipliziert.

Um die Liste nun absteigend zu sortieren, wird folgender Aufruf verwendet:

Mp3Comparer mc = new Mp3Comparer(Mp3Comparer.SortType.Descending);
id3Tags.Sort(mc);

Powershell 02 - Powershell per Gruppenrichtlinie verteilen

Sascha — Wed, 28 Feb 2007 15:52:45 GMT

[Update 08.03.2007]
Verteilung der finalen Powershell Version per Software Installation Package ist nicht mehr möglich!

Hintergrund: Microsoft sieht Powershell als Teil des Betriebssystems. Momentan noch optional, man kann aber davon ausgehen, dass in zukünftigen Windows-Versionen oder Service Packs Powershell fester Bestandteil des Betriebssystems werden wird. Daher werden Teile der finalen Version von Powershell in das System32-Verzeichnis kopiert. Dies bedeutet gleichzeitig das Aus für die Verwendung von msi-Dateien, denen dies nicht erlaubt ist. Bis zur RC1-Version (wenn nicht sogar RC2) installierte sich Powershell noch unterhalb des Programme-Ordners, was mit einer msi Installation bewerkstelligt werden konnte (siehe How-To unten). Da sieht man mal wieder, dass RC noch nicht final ist…

Laut einem Technical Account Manager von Microsoft ist sich Microsoft dem Problem bewusst und arbeitet an einer Lösung für die Verteilung von Powershell mittels AD oder SMS. Um Powershell zur Zeit per Gruppenrichtlinie zu verteilen, bleibt nur die Installation via Startup-/ Logonscript, die funktionieren sollte, da die Installationsdatei mit einem /quiet Parameter aufgerufen werden kann.

[Ende Update]

Das Microsoft Powershell Setup kommt als msi-Paket ins Haus und bietet daher die Windows Installer-üblichen Features. Unter anderem lässt sich ein msi-Paket per Gruppenrichtlinie verteilen und installieren. Das folgende How-To soll einfach nur zeigen, wie schnell so etwas erledigt ist.

Schritt 1: Ordnerfreigabe erstellen, in der das/ die zu verteilenden msi-Pakete liegen.

Schritt 2: In der Group Policy Management Konsole ein neues Gruppenrichtlinienobjekt (GPO) erstellen.

Schritt 3: Das erstellte Gruppenrichtlinienobjekt editieren.

Unter Computer Configuration, Software Settings, Software installation wird hierzu ein neues Package erstellt. Dabei wird die Powershell_Setup-i386.msi über die soeben erstellte Freigabe ausgewählt.

Schritt 4: Eine OU im Active Directory mit dem Gruppenrichtlinienobjekt von Schritt 2 verlinken.

Im Beispiel hier wird die OU "member servers" mit dem GPO "Install Powershell" verlinkt.

Schritt 5: Die Installation überprüfen

Auf einem der Memberserver wird die Powershell danach in der Systemsteuerung unter Software angezeigt. Dass die Powershell wirklich per Gruppenrichtlinie installiert wurde, sieht man auch im Anwendungs-Eventlog: dort findet sich nach einer erfolgreichen Installation der folgende Eintrag:

Powershell 01 - Hilfe, bitte!

Sascha — Fri, 23 Feb 2007 14:11:42 GMT

Dies ist der erste Teil einer kleinen Erkundung von Windows Powershell und ihren Möglichkeiten für Entwickler. Wie kann ich mein eigenes Cmdlet erstellen und wie kann ich die Powershellfunktionalität in eigenen Anwendungen verwenden? Bevor das erste eigene Cmdlet erstellt wird, sollte man sich zuerst einmal einen Überblick verschaffen, was Powershell an Funktionalität schon mitbringt.

Powershell gibt sich sehr hilfsbereit. Eine Übersicht aller zur Verfügung stehender Commandlets gibt es mit dem Befehl Get-Command.

Die wichtigsten Informationen zu einem Commandlet ruft man über Get-Command -name <Commandlet-Name> ab.

Eigentlich benutze ich diesen Befehl nur, um Informationen zur Befehlssyntax zu bekommen, aber ausgerechnet von der sieht man in der Standardausgabe fast nichts. Wenn man den Switch -usage setzt, sieht das schon besser aus.

Ausfürhliche Hilfe zu einem Commandlet mit Beschreibung der einzelnen Parameter und Beispielen zur Verwendung gibt es mit dem Befehl Get-Help -name <Commandlet-Name>

Oft gibt es gleich so viel Information, dass der Anfang des Hilfetextes schon wieder aus dem Bildschirmpuffer der Konsole gescrollt ist, und auch die Bedienung ist nicht wirklich komfortabel. Zum Glück hat Leon the SecretGeek eine schicke kleine Anwendung geschrieben: einen Powershell-Hilfebrowser, der mit einer Kombination dieser zwei gezeigten Commandlets funktioniert. Die Liste im linken Bereich wird durch Get-Command gefüllt. Bei Auswahl eines Commandlets wird dann ein entsprechendes Get-Help ausgeführt und im rechten Bildschirmbereich dargestellt.

Diese Anwendung ist auch ein schönes Beispiel für einen Custom Application Host - also das Verwenden der Powershell(-funktionalität) in einer eigenen Anwendung. Dazu komme ich in einem späteren Post.