Category Archives: WPF

VS2012 Update 1 verfügbar

Ab sofort ist das erste Update für Visual Studio 2012 verfügbar!
Es bringt für VC++ primär die Unterstützung für XP-SP3 mit, was ein großer Fortschritt ist.

Download: Visual Studio 2012 Update 1 – Multi-language
Offline-Installation: How to: Install Visual Studio 2012 Update 1 Offline

Mehr Infos zu VS2012 Update 1:

Nur als kleiner Hinweis: Die Unterstützung für XP-SP3 betrifft nur VC++ 2012, nicht aber .NET-Framework 4.5! Dies ist immer noch auf Vista und höher begrenzt!

Infos über VC2011 (Developer Preview)

Seit kurzem sind die Hilfeseiten für VS2011 online.

Dabei sind auch die Neuigkeiten für VC 2011 aufgeführt.

Der Blick ist wirklich lohnentswert.

Das neue VS kann man sich auch schon zusammen mit Windows 8 runterladen:
http://msdn.microsoft.com/en-us/windows/apps/br229516

Wer es in einer VM installieren möchte muss das neue VMWare 8 nehmen, da es in VMWare 7.1.4 wohl nicht geht (siehe hier ).

XmlSerializer verwenden mit abgeleiteten Klassen ohne “xsi:type” im XML zu verwenden

Lange habe ich gerätselt, wie man verhindern kann, dass der XmlSerializer bei abgeleiteten Klassen immer nur als Element-Name die Basisklasse verwendet und dann im Attribute “xsi:type” den jeweiligen richtigen Typ reinschreibt/ausliest. Das sieht im XML immer sehr unschön aus:

<Liste>
  <BasisKlasse xsi:type="Ableitung01" />
  <BasisKlasse xsi:type="Ableitung02" />
</Liste>

Viel schöner wäre es ja, wenn direkt die abgeleitete Klasse in der Datei stehen würde:

<Liste>
  <Ableitung01 />
  <Ableitung02 />
</Liste>

Bisher hab ich sowas immer gemacht, indem ich das “XmlInclude” Attribut an die Root-Klasse rangehängt habe, um dem XmlSerializer mitzuteilen, welche Klassen er noch berücksichtigen soll. Heute hat mir nun ein Kollege ganz nebenbei eine XML-Datei gezeigt, die genau das hat, was ich schon lange suche… Der Trick ist einfach nur, das “XmlArrayItem” Attribut an dem jeweiligen Property der Liste dranzuhängen… damit werden die Listen-Einträge dann ohne “xsi:type” serialisiert und bekommen den lesbaren Namen 😉

Hier ein kurzes Beispiel wie sowas aussieht:

using System.Collections.Generic;
using System.Xml.Serialization;

namespace ConsoleApplication_VS2010
{
  public abstract class BaseObject {}

  public class Special01 : BaseObject {}
  public class Special02 : BaseObject {}

  public class Root
  {
    readonly List<BaseObject> _Objects = new List<BaseObject>();

    [XmlArrayItem(typeof(Special01))]
    [XmlArrayItem(typeof(Special02))]
    public List<BaseObject> Objects
    { get { return _Objects; } }
  }

  class Program
  {
    static void Main(string[] args)
    {
      var r = new Root();
      r.Objects.Add(new Special01());
      r.Objects.Add(new Special02());
      r.Objects.Add(new Special01());

      using (var sw = new System.IO.StringWriter())
      {
        var ser = new XmlSerializer(typeof (Root));
        ser.Serialize(sw, r);
        System.Console.WriteLine(sw.ToString());
      }

    }
  }
}

Dies ergibt dann:

<?xml version="1.0" encoding="utf-16"?>
<Root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://ww
w.w3.org/2001/XMLSchema">
  <Objects>
    <Special01 />
    <Special02 />
    <Special01 />
  </Objects>
</Root>

VHD mit VS2010 SP1 / TFS und vielen Hand-On-Labs

Wer mal VS2010 SP1 Ultimate kostenlos testen will und dabei auh noch einige Hand-On-Labs machen will (incl. TFS Labs), der kann sich die VHD hier rinterladen:

http://blogs.msdn.com/b/briankel/archive/2010/06/25/now-available-visual-studio-2010-rtm-virtual-machine-with-sample-data-and-hands-on-labs.aspx

Ein kleiner Hinweis noch: Das Windows läuft am 1.November 2011 ab…

Böse Falle mit ??-operator

Heute ab ich längere Zeit nach einem Bug gesucht. Der Folgende Code wollte einfach nicht die korrekte Differenz ausrechenen:

  int? geliefert = 3;
  int? aktuell = 2;

  int diff = geliefert??0 - aktuell??0;

Bis ich endlich draufkam, dass das Minus ja nie ausgewertet wird, da einfach der erste Wert zurückgeliefert wird…

Also gut, wieder was gelernt, wenn man den ??-operator verwendet. Hab das ganze in Klammer gepackt, dann ging es wunderbar…

int diff = (geliefert ?? 0) - (aktuell ?? 0);

VS2010 SP1-beta verfügbar

Die Beta Version des VS2010 SP1 ist nun für alle Verfügbar. Wie immer gilt der Hinweis, dass man dies nicht auf einem Produktivsystem installieren sollte. Wobei diesmal aber auch eine “Go Live” Lizenz dabei ist; d.h. man darf es auch produktiv verteilen!

Das C++ Produkt-Team hat auch noch detailiertere Infos, was sich im C++ Bereich getan hat:
VS2010 SP1 Beta: What’s in It for C++ Developers
Die Hauptneuigkeit dürfte wohl sein, dass es wieder einen lokalen Help-Viewer gibt…

Und wer noch gleich Feedback geben will, kann das hier tun:
Visual Studio 2010 Service Pack 1 Beta Survey

Sprachumschaltung und WPF

Wer mit .NET “aufgewachsen” ist, der kennt das System.Threading.Thread.CurrentThread.CurrentCulture bzw. CurrentUICulture. Damit kann man z.B. in WinForms-Anwendungen die Formatierungen der Ausgaben beeinflussen. Diese Culture wird auch in den meisten Objekten verwendet wenn man “ToString()” aufruft. Bestes Beispiel dafür ist DateTime. Intern wird hier die aktuelle Culture (CurrentCulture) des aktuellen Threads verwendet.

Dieses ganze Konzept ist aber nicht so ganz WPF kompatibel. Dazu gibt es zwei Gründe: Erstens basiert bei WPF (fast) alles auf DependencyProperties, welche Vererbung und auch Änderungsbenachtrichtigungen schon automatisch unterstützen. Auch spielen die Converter eine große Rolle beim Anzeigen von Daten. Dabei wird immer eine Culture mitgegeben in den Konvertierungsmethoden mitgegeben. AUs diesem Grunde spielt die “Thread.CurrentThread.CurrentCulture” in WPF keine Rolle mehr!

Die Sprache wird in WPF also auch über ein DependencyProperty umgeschaltet: FrameworkElement.Language

Das kann man einfach testen indem man z.B. ein DateTime-Property an an TextBlock bindet. Dabei wird die Datum/Uhrzeit immer in en-us angezeigt! Egal welche Sprache nun das Betriebssystem oder den Benutzer hat. Ob dies ein Bug oder Feature ist, sei mal dahingestellt.

Um also beim Starten der Applikation die Sprache auf die aktuelle Sprache zu setzen, muss man für jedes TopLevel-Fenster das Language Property korrekt initialisieren, am besten im Konstruktor:

this.Language = 
  System.Windows.Markup.XmlLanguage.GetLanguage(
    System.Threading.Thread.CurrentThread.CurrentUICulture.Name
  );

Will man eine Sprachumschaltung dynamisch machen, so könnte man auch ein Binding auf dieses Language-Property machen. Dazu muss man aber wissen, dass ja jedes Binding auch eine Culture hat. Da aber die Culture aus dem vererbeten “Language” DependencyProperty kommt beisst sich hier die Katze in den Schwanz… aus diesem Grund scheitert auch ein Binding der Form:

Language={Binding MyCurrentCulture.Name}

mit der Fehlermeldung (InnerException):
Binding for property 'Language' cannot use the target element's Language for conversion; if a culture is required, ConverterCulture must be explicitly specified on the Binding.
Wer diese Meldung genau liest erkennt, dass man für den Converter die Culture explizit vorgeben muss! Damit muss der Bindning Ausdruck z.B. wie folgt aussehen:

Language={Binding MyCurrentCulture.Name,
  ConverterCulture={x:Static glob:CultureInfo.InvariantCulture}}

Dabei ist der Namespace “glob”:

xmlns:glob="clr-namespace:System.Globalization;assembly=mscorlib"

Damit wird nun das Binding möglich.
Und natürlich wird jedes Binding nochmals ausgeführt (bzw. der passende Converter aufgerufen), bei welcher die Language vererbt wurde (was eigentlich überall der Fall ist).
Man sieht also auch: Die Anzeige wird nicht nicht bei Werteänderung aktualisiert, sondern auch bei “Language-Property” Änderung 😉

Anbei mal ein ganz kleines Testprojekt, welches das Umschalten der Language zur Laufzeit anhand dem DateTime aufzeigt:
WpfCulture.zip

SQL Server 2008 R2 Express jetzt mit 10 GB Database limit

Ab sofort gibt es den aktualisierten SQL Server 2008 R2 Express zum konstenlos runterladen.
Eines der wichtigesten neuerung der Express Edition dürfte wohl die erhöhung des Datenabnk-Größe-Limits von 4 GB auf 10 GB sein 😉
Hier der Link zur SQL 2008 R2 Express Startseite
http://www.microsoft.com/express/Database/

Download x86 Edition (235 MB)
Download x64 Edition (247 MB)

Sharepoint Foundation 2010 verfügbar

Ich bin schon länger ein Fan von Sharepoint und verwendet dies auch für mehrere interne Projekte.
Seit einigen Tagen ist jetzt auch der Nachfolger der “Sharepoint Services 3.0” verfügbar (natürlich immer noch kostenlos). Aber natürlich mit einem neuen Namen:
Sharepoint Foundation 2010

Der einzige Nachteil des Nachfolgers ist, dass es nur noch auf einem x64 System installiert werden kann.
Wenn man es auch auf einem Entwicklungsrechner installieren will, so kann man es auf Vista (SP1-x64) oder Win7 (x64) installieren. Produktiv wird dies aber nicht unterstützt.
Hier wird dann schon mehr verlangt:

  • x64 – 4 cores
  • 8 GB RAM
  • 80 GB HD

RemoteFX

Mit Server 2008 R2 Service Pack 1 wird es endlich eine Erweiterung des RDP (Remote Desktop Protocols) geben: 3D!

Es ist also zukünftig möglich via RDP die schöne, neue 3D-Welt zu erfahren.
Dies bedeutet natürlich auch, dass ein Arbeiten mit VS2010, welches ja WPF verwendet, vermutlich flüssig über RDP möglich ist!

Also, ich bin mal gespannt und freue mich schon auf dieses Feature, da ich oft RDP verwende!

RemoteFX!

Edit 2010-03-27:
Hier gibt es auch noch eine ausführlichere Erklärng wie RemoteFX funktioniert:
http://blogs.msdn.com/rds/archive/2010/03/26/microsoft-remotefx-the-problem-we-are-solving.aspx

Source-Indexing (TFS) und Symbol-Store

Wer von Euch kennt das Problem: Der Kunde hat ein Absturz oder einen Hänger Deines Programmes. Das einzige was Du bekommst ist ein Dump-File (z.B. entweder via WER oder durch eigenes schreiben von MiniDumpWriteDump).
Jetzt beginnt für Dich das Problem:

  1. Welche Version hat der Kunde?
  2. Welche Source-Files brauche ich für diese Version?
  3. Wo zum teu.. sind nochmals die passenden PDBs und EXEn für diese Version?

Mit diesem Fragen braucht man sich nicht beschäftigen, wenn man bei seinem Build Prozess noch zusätzlich zwei Dinge einbaut

  1. Source-Indexing
  2. Symbols-Store

Source-Indexing (mit dem TFS)

Source-Indexing sorgt dafür, dass in die Debug-Symole (PDB-Dateien) auch zusätzlich noch ein verweis auf die richtige TFS-Version eingefügt wird. Dadurch kann der Debugger (z.B. VS) man mit der PDB-Datei genau den passenden Source aus dem TFS holen, mit dem die DLL/EXE gebuildet wurde.
Um dies zu machen braucht man zwei Dinge: “Debugging Tools For Windows” und “ActivePerl“). Das Source-Indexing findet sich bei den Debugging Tools im Unterverzeichnis “srcsrv” (also z.B. C:\Program Files\Debugging Tools for Windows\srcsrv). Da die “Skripts” (leider) in Perl geschrieben sind, ist auch noch ActivePerl notwendig. Es reicht aber, wenn man die ZIP-Datei runterlädt und vor dem Aufruf einfach den Pfad auch noch auf das entpackte ActivePerl setzt.

Damit beim Source-Indexing auch der korrekte TFS-Server verwendet wird, muss man in der Datei “srcsrv.ini” die Zeile mit “MYSERVER” auf den richtigen TSF zeigen lassen.
MYSERVER=http://my-tfs-machine:8080

Jetzt muss man nach einen Build nur noch das Source-Indexing aufrufen und angeben, wo denn der Workstore und die PDBs liegen. Ich gebe der Einfachheithalber immer den Root aller Projekte an, welche ich gebuildet habe. Die Natchdatei sieht dann z.B. so aus (es kann auch direkt als eigenes Task in msbuild laufen):

rem Merke mit mal den aktuellen Pfad, was die Root meiner Projekte und Ausgabe ist
set srvOrgDir=%CD%

rem Setze den pfad auch zu dem Perl Zeugs...
path=%path%;"%CD%\Tools\srcsrv\ActivePerl-5.10.1.1006-MSWin32-x86-291086\perl\bin"

rem Wechsle in das Verzeichnis wo die Source-Indexing Tools liegen (liegt bei mir auch im TFS)
cd .\Tools\srcsrv

rem Rufe das Source-Indexing auf
call tfsindex.cmd -ALLROOT="%srvOrgDir%"

rem Setze wieder den ursprünglichen Pfad
cd /D %srvOrgDir%

Alternativ kann man natürlich auch das srcsrv-Verzeichnis im TFS ablegen (so hab ich es gemacht), dann muss man nicht sicherstellen, dass man auf dem Build-Rechner auch die Debugging-Tools installiert hat.

Jetzt sollten nach einem Build alle PDB-Dateien mit der korrekten TFS-Version indiziert worden sein (dies erkennt man daran, dass ziemlich weit hinten in der PDB-Datei Einträge mit “MYSERVER” kommen…; kann man z.B. in Notepad anschauen).

Symbol-Store

Oben haben wir jetzt die PDB-Dateien mit dem passenden Verweis auf den TFS ausgestattet. Jetzt müssen wir nur noch sicherstellen, dass wir zu einem beliebigen späteren Zeitpunkt nicht mehr nach dieser PDB-Datei (und den dazugehörigen EXEn) suchen müssen. Dies geschieht am einfachsten mit dem “symstore” aus den Debugging Tools for Windows. Dies speichert einfach alle PDBs/EXEn in ein Verzeichnis (am besten ein Netzwerkverzeichnis, wenn es später mehrere Verwenden wollen).
Das ablegen erfolgt dann ganz Simple durch:

.\Tools\SymStore\Symstore.exe add /r /f .\*.* /s G:\MyProject\SymbolStore\Files /t "Project Name"

Das war alles 😉

Einstellungen in VS

Ok, fast… denn man will das ganze ja auch noch verwenden… dazu muss man in VS noch ein paar Einstellungen machen, da per default der “Source-Server” deaktiviert ist. Dies muss aktiviert werden:

Jetzt muss man noch den Pfad zu den zuvor abgelegten Dateien eintragen:

Bekommt man jetzt ein Dump oder will in dieser EXE/DLL debuggen, so werden die Sourcen direkt vom TFS geholt (und in einem temporären Verzeichnis gespeichert) und man kann dies dann direkt debuggen.

Ich hoffe, dass hilft dem ein oder anderen.

PS: Beide Verfahren werden übrigens auch intern von Microsoft schon sehr lange eingesetzt (deswegen auch das Source-Indexing in Perl; PowerShell gab es damals noch nicht). Die gesamten Windows Sourcen sind so indiziert und (der wer darf 😉 ) können dann via CCP die passenden indizierten PDB-Dateien abgefragt werden, welche dann z.B: in VS/WinDbg die passenden Source runterlädt.

PPS: Wer das ganze noch für SubVersion haben will, kann es bei Stefan nachlesen:
Source Server und Symbol Server Setup mit Subversion

ListBoxItem Template…

Wir haben hier für die ListBox ein eigenes Template gemacht, dass eben alle ListBoxen bei uns in der Anwendung gleich aussehen… dabei haben wir einfach das Beispiel aus der MSDN verwendet: ListBoxItem ControlTemplate Example

Eigentlich sollte man ja meinen, dass dies Beispiel zumindest einigermaßen funktioniert… leider weit gefehlt…

Das Problem ist: Sobald wir ein eigenes DataTemplate für spezielle Daten gemacht haben, hat ein Klick auf ein Element nur dann reagiert, wenn entweder genau auf den Rahmen des Items geklickt wurde oder genau auf den Text:
ListBoxItem

Es ist also relativ schwer z.B. das “!” genau zu treffen…wir haben ewig gesucht, bis wir endlich den Grund gefunden haben… (dank Franks Unterstützung haben wir es mittels Snoop und der Event-Ansicht gefunden): Der Border in dem ControlTemplate hat keine Hintergundfarbe. Somit ist der Border “durchsichtig” (bzw. “x:Null”), was dazu führt, dass ein Klick auf den Border nicht vom Border verarbeitet wird, sondern vom darunterliegenden Scroll-Container… und der macht natürlich hier nichts damit…
Hier ist auch ein Beispielprojekt (VS2008), damit man es mal selber probieren kann.

Für uns jetzt mal die Lösung: Wir setzen einfach die Hintergrundfarbe des Borders des ControlTemplates auf “Transparent”, dann wirken sich jetzt überall die Klicks auf die ListBox aus… danke an Hendrik für diesen Hinweis!