Michael Niethammers Blog

Wenn man in WPF oder Silverlight Daten an ein Control bindet kann man die Daten püber einfach zu erstellende Konverter
Klassen konvertieren bevor sie angezeigt werden bzw. bevor sie zurückgeschrieben werden. Das war bisher so.

Seit dem ServicePack1 von Visual Studio 2008 kan man – zumindest bei den alltäglichen Konvertierungen – eine stark vereinfachte
Syntax verwenden:

<TextBlock>

        <TextBlock.Text>

                <Binding ElementName=”myComboBox” Path=”SelectedItem.Content” StringFormat=”{}{0:C}”/>

        </TextBlock.Text>

</TextBlock>

<GridViewColumn Header=”Price” DisplayMemberBinding=”{Binding Path=Price, StringFormat=C}”/>

<TextBlock>

        <TextBlock.Text>

            <MultiBinding StringFormat=”Item1 cost: {0}, Item2 cost: {1}”>

                <Binding ElementName=”myComboBox” Path=”SelectedItem.Content”/>

                <Binding ElementName=”myComboBox2″ Path=”SelectedItem.Content”/>

            </MultiBinding>

        </TextBlock.Text>

</TextBlock>

Die Angabe des Stringformats gibt uns die Möglichkeit zumindest einfach Konertierungen ohne eigene Klasse vorzunehmen. Hierbei kann
man d für kurze Datumsangaben, D für lange Datumsangaben, c für Währung und P für Prozentangaben.

Alternativ gibt es auch noch das Contentstringformat mit dem man komplexere Konvertierungen vornehmen kann:

<Label ContentStringFormat=”dddd – d - MMMM”>

    <sys:DateTime>2004/3/4 13:6:55</sys:DateTime>

</Label>

<Button ContentStringFormat=”{}{0:MM/dd/yyyy}”>

        <sys:DateTime>2004/3/4 13:6:55</sys:DateTime>

</Button>

<ListBox Name=”lb1″ SelectedIndex=”1″ ItemStringFormat=”F1″>

        <sys:Double>3.14159</sys:Double>

        <sys:Double>2.71828</sys:Double>

</ListBox>

Diese Vereinfachung ist wirklich hilfreich und funktioniert erst ab ServicePack1 aber dieser dürfte ja inzwischen fast überall freigegeben worden
sein.

.

Seit der Version 3.5 SP1 gibt es beim Databinding ein neues Feature, das man z.B. für die Anzeige von Tooltips bequem nutzen kann:

Dies hier wäre wohl der “klassische Ansatz um mehrere Texte als Tooltip anzuzeigen:

<Element>
  <Element.Tooltip>
    <StackPanel Orientation=“Horizontal”>
      <TextBlock Text=“{Binding Path=Feldwert1}”/>
      <TextBlock Text=“% von, “/>
      <TextBlock Text=“{Binding Path=Feldwert2}”/>
      <TextBlock Text=“% bis”/>
    </StackPanel>
  </Element.Tooltip>
</Element>

So gehts inzwischen aber auch:

<TextBox.Text>
    <MultiBinding StringFormat=“{}{1:#0}% von, {2:#0}% bis”>
      <Binding Path=“Feldwert1″ />
      <Binding Path=“Feldwert2″/>
    </MultiBinding>
</TextBox.Text>

Interessanterweise kann man diese Syntax auch in der Datenpflege anwenden. Das führt dazu, dass die Werte der zwei dahinterliegenden Felder in einer
Textbox erscheinen und dort auch gepflegt werden können. Allerdings ist das für den Anwender nicht gerade transparent wo das erste Feld aufhört und
wo das zweite anfängt. Auch das Thema Datenvalidierung wird dadurch sicher schwieriger. Insofern ist dieses neue Feature hier sicher nicht angebracht!

Häufig will man Daten, die einem bestimmten Status entsprechen oder bestimmte Werte überschreiten in einer Liste besonders hervorheben. Dies kann man in WPF recht einfach machen. Hier kann man sogar dynamisch die komplette optische Darstellung eines Elementes zur Laufzeit über einen Trigger austauschen.

Untenstehend habe ich einmal ein einfaches Beispiel aus einer WPF-Maske rauskopiert:

1. Verwendet wird ein ListView-Steuerlement (erweiterte Listbox)
2. der Trigger bzw. das Template ist der Einfachheit halber im XAML-Code direkt enthalten – im produktiven Einsatz sollte man diese in eine Ressource extrahieren damit man auch mehrere Spalten einfach daran binden kann
3. Das Listview-Control ist an eine Collection gebunden, die über ein LINQ-Statement selektiert wird. Der Trigger schaltet die Farben abhängig vom Feldinhalt des Feldes Emplstatus (character) um:

<ListView x:Name=”lstPlanEmployees” IsSynchronizedWithCurrentItem=”True” ToolTip=”durch auswählen Personendaten anzeigen”  SelectionChanged=”lstPlanEmployees_SelectionChanged” FontSize=”12″ItemContainerStyle=”{DynamicResource ItemContStyle}” >
<ListView.View>
<GridView>
<GridViewColumn Width=”60″ >
<GridViewColumn.CellTemplate>
<DataTemplate>
<TextBox x:Name=”txtStatusCol” Text=”{Binding Path=Emplstatus}” />
<DataTemplate.Triggers>
<DataTrigger Binding=”{Binding Path=Emplstatus}” Value=”aktiv”>
<Setter Property=”Foreground” TargetName=”txtStatusCol” Value=”Green” />
</DataTrigger>
<DataTrigger Binding=”{Binding Path=Emplstatus}” Value=”inaktiv” >
<Setter Property=”Foreground” TargetName=”txtStatusCol” Value=”Yellow” />
</DataTrigger>
</DataTemplate.Triggers>
</DataTemplate>
</GridViewColumn.CellTemplate>
</GridViewColumn>
<GridViewColumn DisplayMemberBinding=”{Binding Path=Jobtext}” Header=”Jobtext” Width=”150″ />
<GridViewColumn DisplayMemberBinding=”{Binding Path=Name}” Width=”180″ Header=”Name” />
</GridView>
</ListView.View>
</ListView>

Jeder hat das Problem, dass eingegebene Daten validiert werden müssen, bevor sie in der Datenbank abgelegt werden. Der Anwender soll bereits bei der Eingabe entsprechende Hinweise zu seinen Eingaben erhalten. Unten habe ich mal eine kleine Einführung für eine der vielen möglichen Varianten der Datenvalidierung aufgeführt. Der Text ist etwas rudimentär ich hoffe es hilft trotzdem bei der Entwicklung:

Im Beispiel wurde eine ganz normale WPF-Anwendung erstellt. In das Projekt wurde eine LINQ to SQL- oder Linq to Entities-Klasse aufgenommen um einen Datacontext für den Zugriff auf die Datenbank zu haben.

Textbox-Control im XAML:

• Databinding ganz normal  an ein Object mit InotifyPropertyChanged-Events z.b. direkt Objekte aus dem DataContext
• Nach der Prüfung wird bei einem Fehler die Fehlermessage als Tooltip angezeigt
• Optional könnte man den Style im Fehlerfall noch anpassen – default ist ein roter Rand

<TextBox Margin=”5,5,5,5″ Grid.Column=”1″ TextWrapping=”Wrap” Text=”{ Binding NoDEPC,ValidatesOnExceptions=True, NotifyOnValidationError=true }” Validation.Error=”TextBox_Error”>
</TextBox>
Eventhandler für Fehler in der Datenvalidierung im Codebehind oder im Template….

private
void TextBox_Error(object sender,
ValidationErrorEventArgs e)
{
if (e.Action == ValidationErrorEventAction.Added)
            {
            ((Control)sender).ToolTip = e.Error.Exception.InnerException.Message.ToString();
            }
  else
      {
           ((Control)sender).ToolTip = “”;
     }
}

Das gebundene Object z.B. aus dem Datacontext muss erweitert werden:
Hier: gebundenes Feld NoDEPC

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Business;
using System.Collections;

namespace Business
    {
// die EntityKlasse, die vom LINQ-Designer generiert
// wurde, wird hier noch erweitert

public partial class Profit_Center 
   {
   public void SetDefaultValues()
             {
             ID_ProfitCenter = Guid.NewGuid();
             NoDesoursys = “99″;
             NoDeco_Area = “XXXXX”;
             PNSourSys = “33″;
            PNCo_Area = “05″;
             IsActive = true;
             IsTemplate = false;
             }
// überschriebene erweiterte Methode aus der Klasse
partial void OnNoDEPCChanged()
   {
   // sobald das property geändert wird
   //z.B. durchs Verlassen der Textbox
   // läuft die Regelprüfung
   CheckNodePC(this.NoDEPC);
   }

//eigentliche Regelprüfung in der klasse
public string CheckNodePC(string Nodename)
   {
   string msg = “”;

        if(Nodename== null || Nodename== “”)
                 msg = “Profitcenternamen dürfen nicht leer sein “;        if(Nodename.Contains(” “)== true)
                 msg += “Profitcenternamen dürfen keine Leerstellen enthalten”;

       if (msg !=“”)
           {
       // exception auslösen damit die message auch
       //an die GUI kommt
            throw new ArgumentOutOfRangeException(msg);
             return msg;
           }
         }
    }

Bei komplexen Silverlight Anwendungen ist es manchmal schwierig genau zu erkennen, wo die Ladezeiten bzw. Fehler bei komplexen XAML-Dateien herkommen. Folgendes Tool hilft dabei: http://silverlightspy.com/

Nachdem unser WPF-Workshop nun schon einige Tage zurückliegt, bin ich derzeit an unserem Silverlight 2 - Projekt dran. Ein ziemlich nerviges Thema ist wieder einmal das Thema Security.
Hierzu habe ich ein ziemlich gutes Dokument mit entsprechenden Hinweisen gefunden:

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=7cef15a8-8ae6-48eb-9621-ee35c2547773

Viele kennen Resharper als Refactoring Tool seit langem. Von DevExpress gibt es ein deutlich eingeschränktes Tool mit ähnlicher Funktionalität - dafür ist es Freeware: 

http://www.devexpress.com/Products/Visual_Studio_Add-in/CodeRushX/

von Universalthread.com:

From SSWare: “VS Explorer adds a Windows Explorer-Like file and folder browsing window to Visual Studio. It provides complete access to file andfolder context menus (including 3rd party extensions such as TortoiseSVN) and drag-drop functionality which allows directly adding files/folders to your projects. It can quickly browse to the current solution folder, project folder
or the selected item. It can add selected dll/exe files as references and open command prompt window on selected folder. VS Explorer eliminates switching back and forth between Visual Studio  and Windows Explorer and other external programs and allows you to focus on your work slow and preserve concentration, save time, reduce stress and work efficiently.”

http://www.ssware.com/vsexplorer/vsexplorer.htm

In Visual Studio 2010 Team-System kommen wieder etliche neue Features und Verbesserungen hinzu. Insbesondere die Templates und die zugehörigen Planungstools werden erweitert. Ein guter Artikel zu dn kommenden Dingen findet man hier:

http://msdn.microsoft.com/en-us/magazine/2009.01.vsts.aspx

Mein Assembly bekommt einen starken Namen - Erstellen und Signieren einer Assembly mit strong name
Was ist ein ?Strong Name??

Ein Assembly, das mit dem Anwendungsverzeichnis ausgeliefert wird, benötigt in der Regel keinen besonderen Namen. Ein Assembly aber, das von mehreren Anwendungen gleichzeitig benutzt werden soll, braucht einen absolut eindeutigen Namen ? den sogenannten ?strong name? (starken Namen).
Dieser strong name ist ein einfacher Textstring, der sich aus dem Namen der Assembly, einem öffentlichen Schlüssel und einer digitalen Signatur zusammensetzt.
Ein strong name erfüllt folgende Anforderungen:
? Namenseindeutigkeit durch die Verwendung eindeutiger Schlüsselpaare
? Schutz der Versionsherkunft ? nur der Entwickler des Codes kann eine Folge-Version des Assemblies erstellen
? garantiert Integrität der Assembly
? Installation im Global Assembly Cache (GAC) möglich

Um die Vorteile eines Assemblies mit starkem Namen zu behalten und Dll-Konflikte zu vermeiden, können Assemblies mit strong name nur auf Assemblies mit strong name verweisen.

Wie erstelle ich eine Assembly mit einem starken Namen?
Um ein Assembly mit einem starken Namen zu erstellen, muß man zuerst ein Schlüsselpaar aus einem öffentlichen und einem privaten Schlüssel generieren.
Dafür gibt es das Kommandozeilen-Tool sn.exe im Verzeichnis %FrameworkSDK%\bin.
In der Eingabe aufforderung geben Sie folgenden Befehl ein:
Sn -k meinKey.snk
Es wird dabei ein Schlüsselpaar in der Datei meinKey.snk angelegt.
Dieses Schlüsselpaar muß dann der Assembly zugewiesen, d.h. signiert werden. Dafür haben Sie zwei verschiedene Möglichkeiten.

1. Signieren über Attribute unter Verwendung der Datei AssemblyInfo.vb bzw .cs:
[C#]
[assembly: AssemblyKeyFileAttribute(@”..\..\meinKey.snk”)]

Falls Sie eine IDE, z. B. Visual Studio .NET, verwenden, müssen Sie wissen, wo diese nach der Schlüsseldatei sucht. Visual Basic .NET sucht die Schlüsseldatei beispielsweise in dem Verzeichnis, in dem die Visual Studio-Projektmappe enthalten ist, wohingegen der C#-Compiler die Schlüsseldatei in dem Verzeichnis sucht, in dem die Binärdatei enthalten ist.

2. Signieren über die Nutzung des Kommandozeilen-Tools Assembly-Linker al.exe:
al /out:meinAssembly.dll meinModul.netmodule /keyfile:meinKey.snk

Bei beiden Möglichkeiten wird der öffentliche Schlüssel als sogenannter Token im Manifest der Assembly abgelegt. Ein Token ist ein Teilabschnitt des vollständigen öffentlichen Schlüssels und wird aus Platzgründen oft an Stelle des eigentlichen Schlüssels verwendet. Zusätzlich wird die Assembly mit dem privaten Schlüssel signiert. Diese Signatur ist wiederum Teil des Manifests.

Durch die Umkehrung der Signatur mit Hilfe des öffentlichen Schlüssels kann man nun sicher feststellen, ob eine Assembly auf dem Weg vom Autor zum Empfänger verändert wurde.
Somit kann kein Unbefugter den Code ändern, wenn er nicht im Besitz des vollständigen Schlüsselpaares ist.

Es ist zu empfehlen, ein Schlüsselpaar nur einmal für eine Firma bzw. für ein Projekt zu generieren und diese Datei, vor allem den privaten Schlüssel, gut unter Verschluß zu halten.

Da Sie eine Assembly nach dem Erstellen nicht mehr mit einem strong name signieren können, stellt sich die Frage, was ich als Entwickler tun kann, wenn ich gerade nur über den öffentlichen, nicht aber den privaten Schlüssel verfüge. Darauf gibt es eine einfache Antwort: das verzögerte Signieren.

Wie funktioniert das verzögerte Signieren?
Beim verzögerten Signieren (delayed signing) wird die Assembly vorerst nur teilweise signiert. Dabei wird nur der öffentliche Schlüssel verwendet. Für den privaten Schlüssel und die vollständige Signierung wir Platz reserviert.

Zuerst müssen Sie über den öffentlichen Schlüssel verfügen.

Sollten Sie über das vollständige Schlüsselpaar verfügen und das verzögerte Signieren aus einem anderen Grund anwenden wollen, können Sie den öffentlichen Schlüssel so aus der Schlüssel-Datei herausfiltern:
Sn -p meinKey.snk meinPublicKey.snk
meinPublicKey.snk enthält nun nur den öffentlichen Schlüssel der Datei meinKey.snk.

Nun fügen Sie der AssemblyInfo-Datei zwei benutzerdefinierte Attribute aus dem System.Reflection Namespace hinzu:

[C#]
[assembly:AssemblyKeyFileAttribute(”meinPublicKey.snk”)]
[assembly:AssemblyDelaySignAttribute(true)]

Dabei wird der Name der Datei mit dem öffentlichen Schlüssel angegeben und das verzögerte Signieren durch den Wert ?true? aktiviert.
Wird das Assembly dann kompiliert, ist es zwar nur teilweise signiert, besitzt aber einen starken Namen und kann im GAC installiert und dort verwendet werden.
Zuvor muß allerdings noch die Überprüfung der Signatur deaktiviert werden, da die Assembly ja über keine gültige starke Namenssignatur verfügt. Diese Deaktivierung können Sie wieder mit dem Strong Name-Tool vornehmen:

Sn -Vr meinAssembly.dll

Zu einem späteren Zeitpunkt, üblicherweise unmittelbar vor der Weitergabe, signieren Sie dann die Assembly mit dem kompletten Schlüsselpaar:

Sn -R meinAssembly.dll

Danach schalten Sie die Verifizierung für die Assembly wieder ein:

Sn -Vu meinAssembly.dll

Hinweis: Bei allen Optionen für Sn.exe wird die Groß- und Kleinschreibung beachtet. Eine vollständige Liste aller Optionen finden Sie in der .NET Framework SDK-Dokumentation unter dem Stichwort ’sn.exe’.