Benjamin Gopp (HiQ-Software)

Spekulativ: VisualStudio 2012, TFS in da Cloud, und .NET 4.5

2011-05-16T07:52:00.000+01:00

Heute findet die teched North America in Atlanta statt. Die großen Zeiten einer teched sind längst vorbei, als noch Bill Gates die Keynote hielt, oder Dr. Brown mit seinem DeLorean, “zurück aus der Zukunft” kam. Stattdessen erwartet man heutzutage von Konferenzen wie der MIX oder PDC die großen Ankündigungen.

Schaut man sich jedoch die diesjährige Sessionliste an, kann man von der heutigen Keynote ein paar wichtige Ankündigungen erwarten. Einige Informationen sind schon durchgesickert, wie bereits “der Dotnet-Doktor” schrieb.

Wenn Jason Zander die Keynote hält, geht es meistens um VisualStudio und das .NET Framework; er ist nämlich der Hauptverantwortliche dafür. Sicherlich wird er einige Demos von VisualStudio 2012 und .NET 4.5 vorführen. Ich denke aber nicht, dass es bereits jetzt eine Beta geben wird.

Nach der Keynote folgen die Foundation Sessions, d.h. Vertiefungen von den Demos die in der Keynote gezeigt wurden. Diese sind meine Highlights:

Wie es mit TFS/VisualStudio als ALM Plattform weitergehen soll, hat Brian Harry auf der PDC10 gezeigt: Es geht in die Cloud!

Ein weiteres wichtiges Thema wird die “Async" Spracherweiterung für VB und C#sein. Damit wird Asynchrone Programmierung quasi zum Kinderspiel.

DEV324 | C# and Visual Basic Future: Async Made Simple

Unterstützung wird es vom Framework über neue APIs in der TPL sowie in WCF geben.

Evtl. gibt es auch hier die CTP3

Mal gucken ob ich mit meinem Blick in die Glaskugel recht behalte :-)

PDC10 Sessions online

2010-10-22T08:18:00.001+01:00

Die Sessions für die PDC vom 28. / 29. Oktober sind online.

Anhand der Session Beschreibungen lässt sich erahnen, welche Überraschungen uns erwarten werden.

Direkt nach der Keynote, die in den UserGroups zusammen gesehen wird, berichtet Anders Heijlsberg über die Zukunft von C# und VB. Vermutlich wird es aber kein C# 5 oder VB 11 geben. Ich könnte mir aber vorstellen, dass es eine CTP vom “Compiler as a Service” geben könnte.

In dem gleichen Slot behandelt Bart de Smet ein nicht weniger wichtiges Thema, nämlich LINQ und Rx.

Auffällig ist, dass einige Slots noch nicht besetzt sind. Es sind also einige neu Ankündigungen zu erwarten, im Bereich Azure, Windows Phone 7 und sogar VisualStudio. Unteranderem gibt es auch einen Placeholder für Silverlight! Vielleicht erhalten wir einen Blick von Silverlight 5?!

In der letzten Session geht es um die Zukunft von F#.

Alle Sessions werden live gestreamt! Es lohnt sich also statt dem Abendspielfilm, oder dem Besuch im Kino, eine Session von der PDC anzusehen!

The Silverlight Developer Runtime is not installed

2010-10-06T09:09:00.001+01:00

Silverlight ist schon eine tolle Plattform…

Heute morgen bin ich auf channel9 gesurft und wollte mir ein Video anschauen. Nach klick auf den Play Button, kam ein netter Bildschirm, der mich darauf hinwies, dass ich nicht die aktuellste Silverlight Version installiert hätte. Da ich das Video unbedingt gucken wollte, und auch sonst keine Probleme damit habe immer die neuste Version zu installieren, lud ich die neueste SL Version herunter und installierte sie.

Gleichzeitig war ich aber auch mit VisualStudio zugange. Während ich also das Video auf channel9 sah, arbeite ich fleißig an einem Silverlight-Spike. Als ich nun F5 drückte, kam folgende Meldung:

Zunächst dachte ich, dass es daran liegen könnte, dass nach der Installation der Silverlight Runtime nun die Silverlight Tools für VisualStudio ebenfalls aktualisiert werden müssten. Die Installation der SL Tools brachte aber keine Lösung.

Nach etwas “bingen” stieß ich auf einige Foreneinträge. Dieses Problem scheint wohl häufiger aufzutauchen,was ich erstaunlich fand. (Jedoch nicht ungewöhnlich für Silverlight)

Für Silverlight gibt es zwei Runtimes! Eine für “Normalos” und eine für Entwickler. Die developer runtime ist jedoch nicht im SDK oder den Tools enthalten, sondern es muss das sog. Silverlight managed debugging package heruntergeladen werden.

Überlegt euch also gut, ob ihr immer die neuste Silverlight Version braucht, sie könnte euer VisualStudio kaputt machen.

VB – Quo Vadis?

2010-04-16T10:53:00.001+01:00

Ja ich gebe zu, ich mag VB.

Ich finde VB10 hat ein paar sehr nützliche Features. So sind z.B. in den meisten Fällen keine underscores (_) als sog. Line continuations mehr nötig.

Auch nett sind die collection initializer, die es momentan in C# in der Form nicht gibt.

Bisher mochte ich VB immer verteidigen, wenn es darum ging, ob VB schlechter ist als C#.

Doch mittlerweile kommen mir Zweifel. Das mag daran liegen, dass ich C# doch recht lieb gewonnen habe. Vielleicht aber auch daran, dass ich immer mehr F# Code schreibe und dessen Eleganz einfach umwerfend finde.

Der Grund warum mir Zweifel an VB kommen, folgender VB10 Code, den ich in einem Blog entdeckt habe.

Public Sub LoadPolicyDetail()

Dim client As New Services.Service1Client()

AddHandler client.GetPolicyDetailCompleted,

Sub(s As Object, e As GetPolicyDetailCompletedEventArgs)

If e.Result <> Nothing Then

MessageBox.Show("Awesome!")

End If

End Sub

client.GetPolicyDetailAsync()

End Sub

Dieser Code zeigt, wie man eine anonyme Methode an einen Event bindet. Hier der gleiche Code in C#

void LoadPolicyDetail()

{

var client = new
Service1Client();

client.GetPolicyDetailCompleted += (s,e) => if (e.Result != null) MessageBox.Show("Awesome!");

client.GetPolicyDetailAsync()

}

Dieser Code ist doch deutlich lesbarer. Statt 8 Zeilen Code und einer Menge "Rauschen" brauche ich mit C# nur 3 Zeilen. Gut man könnte den Code noch etwas formatieren, dann kommt man auf 5.

Ich verstehe nicht, welche Vorteile eine Programmiersprache bringen soll, für die man bei gleichem Ergebnis 3x so viel Code schreiben muss.

F# und der Umgang mit out Parametern

2010-03-03T12:35:00.001Z

Jede Funktion bzw. Methode kann zunächstmal nur immer eine Informationen zurückgegeben. Dies wird durch den Rückgabewert oder Rückgabeparameter ausgedrückt. Was macht man aber, wenn man in einer Methode mehrere Informationen zurückgeben möchte, die evtl. sogar optional sein sollen? Eine Möglichkeit ist natürlich einen komplexen Datentyp zu definieren und diesen als Rückgabetyp der Methode zu benennen. Aus Bequemlichkeit macht man das aber eher nicht.

Ein pragmatischster Ansatz ist es, für die zusätzlichen Rückgabewerte jeweils out Parameter zu definieren. Die out Parameter sind in der Regel primitive Datentypen wie string oder int.

Im .NET Framework gibt es einige Methoden die einen out Parameter haben. Eine oft verwendete Klasse ist z.B. das Dictionary.

Hier ein Beispiel:

var dict = new
Dictionary<string, int>();

dict.Add("A", 1);

dict.Add("B", 2);

Jetzt versuchen wir Werte aus dem Dictionary zu ziehen. Da nicht garantiert werden kann, dass der gesuchte Wert auch in dem Dictionary ist, verwenden wir die Methode TryGetValue. Da diese nun einen out Parameter definiert, müssen wir bevor wir diese Methode aufrufen können eine Variable mit dem entsprechenden out Parameter Typ definieren und die Methode mit der Variablen aufrufen.Der Rückgabewert von TryGetValue ist ein bool, so dass man erkennen kann, ob der Wert im Dictionary vorhanden ist. Nur wenn der Wert vorhanden ist, hat auch die Variable einen Wert. Aber Vorsicht! Da int ein Werttyp, ist hat er immer einen Defaultwert, nämlich 0. Zur Sicherheit sollte man daher der out Variablen einen anderen Wert als den Defaultwert zuweisen, bei int z.B: -1 statt o.

int value = -1;

var success = dict.TryGetValue("A", value);

if (success)

{

Console.WriteLine(value);

}

Soweit dürfte das jedem klar sein und sicherlich schon oft gemacht worden. Für mich ist die o.g. Methode, genauso wie TryParse, ein legitimer Grund out Paramter zu verwenden. Alle anderen Gründe sind eher zweitrangig da hier Bequemlichkeit im Vordergrund steht. Man will halt keinen komplexen Datentypen nur für einen Rückgabeparameter erstellen.

Aber es geht auch anders: mit F#!

F# to the rescue

Da F# eine ganz normale .NET Sprache ist, kann man natürlich auch die Klassen des Frameworks aufrufen. Z.B. auch die Methoden die out Parameter definieren, wie z.B. das Dictionary. Wie geht F# damit um?

In F# können wir ganz normal ein Dictionary erzeugen.

open System.Collections.Generic

let dict = new Dictionary<string,int>()

Nun fügen wir Werte zum Dictionary hinzu

dict.Add("A",1)

dict.Add("B",2)

Schließlich wollen wir die Werte auch wieder auslesen.

let result = dict.TryGetValue("A")

Nun von welchem Typ ist jetzt result? Und warum muss man keinen out Parameter übergeben?

F# Interactive gibt die Anwort.

val result : bool * int = (true, 1)

Result ist vom Typ bool * int
, was in F# bedeutet dass dies ein Tupel ist. In .NET 4.0 kann man dies als Tuple<bool,int>
beschreiben.

Nun können wir diesen Tupel mit den Funktionen fst und snd zerlegen.

let success = fst result

val success : bool = true

let value = snd result

val value : int = 1

F# wäre nicht F# wenn man es nicht noch einfacher ausdrücken könnte. Man kann nämlich den Tuple direkt in seine Bestandteile zerlegen.

let (success,value) = dict.TryGetValue("A")

val value : int = 1

val success : bool = true

let (success,value) = dict.TryGetValue("C")

val value : int = 0

val success : bool = false

Fazit

Für meine Begriffe ist dies ein gutes Bespiel wie ausdrucksstark F# ist. In der Vergangeneheit sind viele Fehler im Programmiersprachendesign gemacht worden. Allem voran C++, aber leider auch bei C#. Tuples sind ein hervoragendes Mittel, um out Parameter zu vermeiden. Da Tuple in .NET 4.0 ein "first Class" Datentyp ist, gibt es keinen Grund mehr diesen nicht auch in C# als Alternative zu out Parametern zu verweden. Letztendlich macht es aber mit F# mehr Spaß!

Over und out!

Cassidy Marie shipped

2010-02-24T18:43:00.004Z

Beta

Release Candidate

Cassidy Marie shipped

Die glücklichen und schlaflosen Eltern
Marika und Benjamin Gopp

F#: Units of Measure

2010-02-12T10:17:00.001Z

Mit dem diese Woche erschienenen Release Candidate von VS2010, hat sich auch was bei F# getan. Wie Don Syme in seinem Blog schreibt, ist der F# Compiler auf Version 2.0 heraufgesetzt worden. Das bedeutet F# ist ausgereift um es produktiv einzusetzen (Obwohl viele es bereits mit früheren Version eingesetzt haben). Zeit sich also endlich ernsthaft mit F# und seinen genialen Features zu beschäftigen!

Ein Feature über das ich heute schreiben möchte sind Units of Measure oder zu Deutsch Maßeinheiten. Bei diesem Feature geht es um das Problem bei der Verwendung von unterschiedlichen Maßeinheiten im Code. Wie der Unfall des NASA Mars Climate Orbiter 1999 zeigt, kommt es auch heute noch zu Fehlern auf Grund der Verwendung von unterschiedlichen Maßeinheiten. Mittlerweile wird auch in der USA in Wissenschaft und Technik das Metrische System verwendet. Ein Zulieferer hatte jedoch in Pfund und Fuß gerechnet, was letztlich dazu führte, dass die Mars Sonde verglühte.

Dieses Feature hat also einen relativ ernsten Hintergrund. Damit solche Fehler sich nicht in Produktivcode einschleichen verwendet F# eine erweiterte statische Codeanalyse. Maßeinheiten werden dabei mit Attributen annotiert und bei Ihrer Verwendung vom Compiler auf Korrektheit geprüft. Dabei wird jedoch nicht nur geprüft ob der entsprechende Typ korrekt ist, sondern auch ob die Funktion in dem man diesen Typ verwendet, mathematisch korrekt ist. Durch die intelligente Typinferenz in F# können sogar abgeleitete Maßeinheiten ermittelt werden.

Nun wie funktioniert das? In C# könnte man eine gewisse Art der Typsicherheit hinbekommen, indem man für Maßeinheit einen eigenen Typen erstellt. Somit würde der Compiler beim Verwenden des Types dessen Typsicherheit garantieren. Was jedoch nicht möglich ist, dass auch auf die Einhaltung der mathematischen Regeln geprüft wird. Dies könnte man vielleicht zur Laufzeit realisieren in dem man für Maßeinheiten entsprechende Rules definiert. Letzlich würde aber eine Prüfung zur Laufzeit nicht den Absturz einer 100.000 km entfernten Sonde verhindern können. Die Prüfung muss also viel früher, also zur Compilezeit erfolgen.

Noch ein Hinweis: Units of Measure können nur mit Gleitkommazahlen verwendet werden! Dies liegt daran, dass man nicht nur dumme Maßeinheiten verwenden kann, sondern auch physikalische Größen wie Beschleunigung etc. Dies würde nicht mit Integers oder anderen Typen funktionieren. (Tatsächlich kann man aber Units of Measure mit Komplexen Zahlen oder Vektoren verwenden)

Ein Beispiel:

Man definiert zunächst die Maßeinheiten die man verwenden will als Typen. Diese Typen attributiert man mit[<Measure>]. (So sehen Attribute in F# aus. Eine Misschung aus C# und VB Attribute)

[<Measure>] type kg

[<Measure>] type s

[<Measure>] type m

Nun können wir Formeln schreiben. Wir wollen wissen, mit welcher Geschwindigkeit wir auf der Erde aufkommen, wenn wir aus einer bestimmten Höhe springen. Zunächst definieren wir die Höhe als Gleitkommazahl und auf welche Maßeinheit sich diese bezieht.

let höhe = 2.0<m>

Nun definieren wir die Gravitation. Diese ist eine Beschleunigungskraft: also Gravitationskonstate mal Meter pro Sekunde im Quadrat

let gravitation = 9.81<m/s^2>

Wir können nun ausrechnen wie groß die Geschwindigkeit ist, mit der man auf der Erde auftrifft.

let geschwindigkeit = sqrt (2.0 * gravitation * höhe)

F# Interactive sagt uns, dass die Geschwindigkeit in Metern pro Sekunde berechnet wird.

val geschwindigkeit : float<m/s> = 14.00714104

Demnach schlgt man mit 14 Metern pro Sekunde bei einem Sprung aus 2 Metern Höhe auf der Erde auf. Gut zu wissen!

Im F# Power Pack sind weitere Standardmaßeinheinten definiert, so dass man nicht jedes mal alle Naturgesetze herunterbeten muss. Auf der anderen Seite stellt sich die Frage, wann man dieses Feature wirklich brauch. Hier zeigt sich wieder das F# eine super Ergänzung zu bestehenden C# Code ist, jedoch keinesfalls den Anspruch erhebt C# in seiner Gesamtheit abzulösen. Bisher sind noch keine Überlegungen gemacht worden, Units of Measure auch nach C# zu portieren oder sogar in die CLR. Man wird mit der Zeit sehen müssen, ob dieses und andere Feature auch nach C# portiert werden, oder ob es dann keinen Grund mehr geben würde F# zu verwenden. Das wäre außerst schade!

Viel Spaß beim Ausprobieren mit F#

Benjamin

Top Ten Free Extensions for Visual Studio 2010

2010-01-26T07:54:00.001Z

Kate Gregory hat auf Codeproject eine Top 10 der Erweiterungen für Visual Studio 2010 zusammengestellt.

Darunter auch meine Erweiterung die "ZoomEditorMargin". Meine Beschreibung findet ihr hier: http://hiq-software.blogspot.com/2009/10/vs2010-extension-zoomeditormargin.html

Ein Video von meiner Extension kann man sich bei Youtube ansehen http://www.youtube.com/watch?v=sM_20hptWDc

Weitere Tools und die entsprechenden Videos hierzu findet ihr unter http://www.codeproject.com/KB/macros/TopTenFreeExtensions2010.aspx

Benjamin

VSTO 4.0 Runtime

2009-11-17T11:34:00.001Z

Die VSTO 4.0 Runtime wird nicht installiert, wenn man Office 2010 bereits installiert hat. Stattdessen wird die VSTO 3.5 Runtime installiert!

Warum? Keine Ahnung!

Mehr Informationen findet man unter: http://msdn.microsoft.com/en-us/library/bb608603(VS.100).aspx

Wer die Installation nachholen will kann die Runtime über den entsprechenden Bootstrapper installieren. Der wird nämlich installiert.

Der Bootstrapper Pfad lautet: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\VSTOR40

VS2010 Extension: ZoomEditorMargin

2009-10-20T15:27:00.005+01:00

VS2010 Beta2 ist endlich draußen. Kaum heruntergeladen und installiert, habe ich auch schon die erste Erweiterung für den neuen WPF Codeeditor geschrieben!

Besonders gespannt war ich auf die Zoom Funktion des Codeeditors. Als ich VS2010 zum ersten Mal öffnete, war ich jedoch etwas enttäuscht. Auf der linken Seite des Code Editors befand sich lediglich eine Combobox, über die man den Zoom einstellen kann. Aus meiner Erfahrung mit Office 2007, hätte ich jedoch gerne einen Slider gehabt, mit dem ich stufenlos zoomen könnte.

Zum Glück lässt sich der neue WPF Codeeditor in VS2010 an allen Ecken und Enden anpassen. Gesagt getan, habe ich eine eigene "Margin" für den Editor geschrieben. Eine Margin ist ein Bereich im Codeeditor, in dem man ein WPF Control platzieren kann. Dies ist nur eine von vielen Möglichkeiten den Codeeditor anzupassen und zu erweitern.

Wer das ZoomEditorMargin herunterladen und direkt ausprobieren möchte, kann dies in der , oder über den ExtensionManager in VisualStudio tun.

Der Code Editor ohne Zoom Extension

Der Code Editor mit Zoom Extension

In den nächsten Posts werde ich erklären, wie ich diese Extension erstellt habe. Es gibt viele Aspekte, auf die ich näher eingehen möchte. Deswegen verrate ich nicht alles schon in diesem Blog Post.

Viel Spaß und stay tuned

Benny

Stirnrunzeln über: "Stirnrunzeln über das Neuste von Microsoft seit geschnitten Brot"

2009-10-15T09:41:00.002+01:00

Ralf Westphal schrieb in seinem Blog "Stirnrunzeln über das Neuste von Microsoft seit geschnitten Brot", über das neue Reaktive Framework (Rx) von Microsoft. Zunächst wollte ich einen Kommentar in sein Blog schreiben. Der Kommentar ist dann etwas länger ausgefallen, so dass ich mich entschieden habe, einen eigenen Blog Eintrag mit meiner Meinung zu diesem Thema zu schreiben. Ralf fordert sogar zu Reaktionen auf: "Oder übersehe ich hier die eigentliche Erfindung? Geht der brillante Innovationshub an mir vorbei? Ich bitte um Erhellung"

Also versuch ich doch etwas Licht ins Dunkeln zu bringen.

Wo ist das Problem?!

Für Ralf besteht das Problem an dieser neuen Technologie, dass er ein "neues Vokabular für etwas Altes" benutzen muss. Nach dem Motto: Raider ist jetzt Twix. Klar, wenn etwas Neues mit einem alten Begriff besetzt ist und das Neue immer mit dem Alten assoziiert wird, sinkt natürlich die Akzeptanz für das Neue. Heißt das aber, dass da Neue schlecht ist? Das kann ich (noch) nicht beurteilen. Trotzdem bin ich Neuem erst mal aufgeschlossen eingestellt.

Was ist also das Alte? Für Ralf ist das Alte: Complex Event Processing (CEP).

"Das ist nicht neu, das ist kein Hexenwerk".

Aber das ist doch mit den meisten Erfindungen so! Irgendwo hat's Irgendwer bereits erfunden. Das Neue sieht nur hübscher aus: "es ist eben keine tolle neue Erfindung seit geschnitten Brot, sondern etwas lange Bekanntes in aufgehübschtes Gewand gekleidet". Ja, das ist vermutlich so.

"Tut mir leid, da ist nichts Neues für mich dabei. Wenn ich im etablierten Paradigma data flow denke, dann ist das etwas uraltes und kann mit heutigen Mitteln bewältigt werden."

Ralf, das mag für dich alles "kalter Kaffee" sein. Aber hallo? Data flow, etabliert? Wo denn bitte? In welcher Firma die Software Entwicklung ist denn dieses Paradigma etabliert? Frag doch aber bitte mal deine Kunden, die Teilnehmer der CCD Seminare, die Besucher einer Konferenz, die Zuhörer deiner Vorträge. Wer von denen:

hat von CEP, Esper oder CCR gehört?
hat einen Artikel über CEP, Esper oder CCR gelesen (von dir oder jemand anders)?
verwendet CEP, Esper oder CCR produktiv in seinen Buisiness Anwendungen?

Antwort: fast
Niemand.

Das ist das Problem: Für Dich und einige Wenige ist das alles Schnee von gestern (siehe 1. Kommentar von Holger Hofstätte). Für die breite Masse, absolutes Neuland.

"Wer das wirklich einmal ausprobieren will, was man mit einer Abfragesprache auf Event-Strömen tun kann, dann kann mit NEsper spielen"

Nein Ralf, ich will nichts ausprobieren, ich will auch nicht nur damit spielen. Ich möchte diese Funktionalität im .NET Framework haben und produktiv sein.

Reaktive Programmierung wird im Core .NET Framework vorhanden sein. Das ist das Neue! Das ist Etablierung!

Was ist mit LINQ

Zur Erinnerung: für Ralf besteht das Problem am Reactive Framework, dass es das alles schon einmal gab. Was war aber gleich nochmal LINQ?

Das Konzept hinter LINQ kommt aus der funktionalen Programmierung (Map, Filter, Reduce). Anscheinend hatte hier Ralf keine oder nicht genügend Berührungspunkte mit der funktionalen Programmierung, dass er automatsch LINQ mit einer längst erfundenen Technologie assoziiert hätte. Zumindest wird Erik Meijer für sein "Brainchild" LINQ gelobt, jedoch nicht für seine anderen Projekte (z.B: Volta und Rx).

Funktionale Programmierung war doch auch nur ein akademisches Thema. Vielleicht ist man im Studium mit LISP, ML oder Miranda in Berührung gekommen. Angekommen im Berufsleben hat man aber seine Daten über geschachtelte for-Schleifen gefiltert. Von wegen Map, Filter, Reduce. Obwohl die Technologie doch bereits in .NET vorhanden war (Delegates, Iteratoren). Trotzdem hat es keiner genutzt. Aber dann kam LINQ daher und mit ein bischen "syntactic sugar" für C#, etabliert sich ein Konzept aus der funktionalen Programmierung auch in einer objektorientierten Programmiersprache wie .NET. Und da das Konzept im Framework verankert ist, ist LINQ sogar für alle.NET basierten Programmiersprachen verfügbar.

Erst mit LINQ hat sich das funktionale Paradigma in der breiten Masse etabliert. Immer mehr Leute benutzen LINQ Queries um ihre Listen zu projizieren, filtern und aggregieren. Immer mehr Leute verwenden Lambda Ausdrücke für die alltäglichsten Dinge.

BetaMax vs. VHS, HD vs. BlueRay

LINQ hat da eine Tür aufgestoßen, das Reaktive Framework wird das gleiche machen und den Weg in den Mainstream finden

"Flows habe ich aber natürlich nicht erfunden. Die sind alt"... "Mainstream ist es aber nicht geworden, wie wir sehen. Schade. Denn die Schritte in einem Flow steigern die Evolvierbarkeit von Software, finde ich"

Ralf, das ist doch genau dein Wunsch, dass das Konzept den Weg in den Mainstream findet. Welche Technologie letztendlich das Rennen macht spielt doch keine Rolle. Ob BetaMax oder VHS, HD oder BlueRay, CEP oder Rx.

Fazit

Es gab schon immer Erfindungen, die nur einem kleinen elitären Bereich in Industrie und Forschung, zugänglich oder erschlossen waren. Nur weil es eine Technologie in einem kleinem Bereich Anklang gefunden hat, kann man nicht sagen die Technologie sei etabliert. Erst wenn sie es in den Mainstream geschafft hat, kann man von Etablierung sprechen. LINQ ist ein super Beispiel dafür, dass ein akademisches Thema dem Mainstream zugänglich wird.

CEP, Esper und CCR haben sich nicht etabliert und werden sich nicht etablieren.Das Reactive Framework wird sich aber etablieren. Warum? Ganz einfach, es wird Kernbestandteil von .NET sein und damit zugänglich und allgegenwärtig für .NET Entwickler. Kein separates Tool, kein irgendwo runterladen, kein rumspielen. Es wird einfach da sein. Bleibt nur noch es auch zu nutzen...

F# - Teil 1

2009-06-25T08:18:00.001+01:00

Vorgestern habe ich einen Vortrag bei der User Group Köln über F# gehalten. Dort habe ich über meine Erfahrungen mit F# geredet und ein paar Sprachfeatures gezeigt. Leider waren 30 Minuten viel zu wenig um alles zu zeigen und auch noch Fragen zu beantworten. In den kommenden Blogeinträgen werde ich daher meine Erfahrungen mit F# schriftlich festhalten.

F# ist eine neue Programmiersprache in der .NET Familie. Diese wird in VS2010 neben VB und C# eine der Hauptsprachen für die .NET Entwicklung werden; so der Plan.

Déjà-vu

Als ich zum ersten Mal die Beta1 von VisualStudio 2010 öffnete, hatte ich ein Déjà-vu Erlebnis. F# hatte ich bereits in VS2008 ausprobiert, aber erst mit VS2010 ist mir bewusst geworden, was Microsoft da eigentlich vor hat. Und dann lief es mir eiskalt den Rücken runter. Denn als ich zum ersten Mal vor ca. 6 Jahren ein VisualStudio 2003 installierte, um .NET zu lernen, stand neben VB und C# eine weitere Programmiersprache zur Auswahl; und das war J#.

Welchen Weg J# gegangen ist, muss ich nicht erwähnen. (Wer noch aktiv in J# programmiert, der möge sich bitte bei mir melden!). Könnte das gleiche Schicksal F# ereilen?

J# vs. F#

Die Frage ist, ob nur weil F# in VS2010 bereits vorinstalliert ist und man es sich nicht separat herunterladen muss, dieses dann auch öfters genutzt wird. Bei J# hat das ja auch nicht geholfen.

Nun, auf den ersten Blick hat F# ein schlechtes "Karma". Warum kann man aber doch sagen, das F# seinen Weg machen wird?

	J#	C#	F#
Paradigma	objektorientiert	objektorientiert	funktional
Sprachfamilie	C	C	ML
Kompatibilität	JAVA	-	OCAML

Vergleich von J# und F#

Der Vergleich zeigt, dass sich J# und C# einfach zu ähnlich sind, als dass es einen wirklichen Gewinn bringen wurde. Wer Java programmieren will, der macht das mit Java und nicht mit J#. Zumal man mit Eclipse eine weitaus bessere Entwicklungsumgebung hat. F# hat hingegen nichts mit C# zu tun. Die Sprache basiert nicht auf C sonder auf ML (Meta Language). Auch die Art der Programmierung ist anders, nämlich funktional. Microsoft hat jedoch mit F# ein paar Zugeständnisse gemacht. F# bezeichnet sich selber als "Multi Paradigmen" Programmiersprache, im Gegensatz zu reinen funktionalen Programmiersprachen wie Haskell. Man kann z.B. mit F# objektorientierte Klassenbibliotheken definieren, die von anderen .NET Programmen aufgerufen werden können.

Fazit

F# kann nicht mir J# verglichen werden, auch wenn es viele Ähnlichkeiten aufweist. Nicht in der Art der Syntax, sondern in der Art wie F# marketingtechnisch platziert wird. Ich vermute ganz stark, dass F# einen großen Einfluss auf die Weiterentwicklung von C# und .NET haben wird. F# hat dazu beigetragen, dass C# 2.0 Generics erhalten hat. Für C# 3.0 und LINQ wurden weitere Konzepte der funktionalen Welt in die objektorientierte Welt übertragen: Typinferenz, Lambda Ausdrücke und das sehr esoterische Konzept der Monadentheorie. Ich spekuliere dass C# 5.0, nachdem C# 4.0 Features aus der dynamischen Welt bekommen hat, wieder Konzepte aus der funktionalen Welt adaptieren wird. Meine Wunschfeatures für C# 5.0 sind: Pattern Matching, erweiterte Typinferenz, und Metaprogrammierung.

Ich glaube, dass man folgendes plakativ von F# sagen kann (andere funktionale Sprachen eingeschlossen):

Dank F# gibt es Generics. Dank F# gibt es Lambda Ausdrücke. Dank F# gibt es LINQ.

Danke F#!

Ausblick

Ich habe vor ein paar grundlegende Blogeinträge zu F# zu schreiben. Im nächsten Blog Eintrag wird es darum gehen, warum man eigentlich F# verwenden sollte.

Silverlight 3

2009-03-18T15:11:00.001Z

WOW!

Bereits vor der eigentlichen Ankündigung bei der Keynote auf der Mix09, ist das Silverlight 3 SDK freigegeben worden. Ob es jetzt offiziell ist, weiß ich nicht - auf jeden Fall kann man es jetzt schon downloaden ;-))

Als WPF Entwickler war ich eher enttäuscht von Silverlight 2. Ein intuitives programmieren war nicht möglich. Eigentlich war es nur ein Krampf. Also habe ich beschlossen "Silverlight" erst mal "silverNight" sein zu lassen. Bis ... ja bis heute.

Auf die Schnell konnte ich folgende interessanten, lang erwarteten und teilweise überraschenden Neuerungen feststellen.

ObservableCollection<T>

Wie bereits aus WPF bekannt, implementiert diese Collection das INotifyCollectionChanged Interface. Damit können Controls feststellen, ob sich etwas an dieser Collections geändert hat, also Items hinzugefügt oder gelöscht wurden, so dass man die UI aktuallisieren kann. Siehe ItemsControl und ListBox

ICollectionView

Eng mit der ObservableCollection sind die sog. CollectionViews verbunden. In WPF gibt es diverse View Implementiereungen, ItemsCollectionView, EnumerationCollectionView, ListCollectionView, BindingListCollectionView. Diese gibt es aber nicht in Silverlight 3.

PagedCollectionView

Interessanterweise gibt es aber die PagedCollectionView; die es aber nicht in WPF gibt...

Nachwievor bewegen sich WPF und Silverlight immer noch stark auseinander. Leider.

Animationen

Für Animationen gibt es jetzt "Ease" Funktionen. Diese interpolieren eine Funktion die z.B. eine Beschleunigung simuliert. So kann man z.B. auch einen Ball springen lassen.

In WPF kann man solche Effekte über "KeySplines" erzeugen, aber auch diese gibt es nicht in Silverlight.

Weitere Neuerungen werden noch gepostet. Stay tuned.

So jetzt schnell nach Hause, damit ich mir die Keynote live gestreamt angucken kann!

WPF Window als Vollbild

2009-01-28T11:13:00.002Z

Ein WPF Fenster kann auch im Vollbildmodus angezeigt werden und somit den gesamten Bildschirmplatz einnehmen ohne die Windowsstartleiste

Wie funktioniert das?

Nun, es ist einfacher als man denkt. Dafür braucht man keine nativen Windows APIs aufzurufen.

Folgender XAML Code zeigt wie es geht:

<Window x:Class="WpfApplication1.Window1"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

Title="Window1"

WindowStyle="None"

WindowState="Maximized"

WindowStartupLocation="CenterScreen">

</Grid>

</Window>

Zunächst wir der WindowState mit Maximized angegeben. Das bewirkt natürlich dass das Fenster den gesamten Bildschirm ausfüllt.

Den ganzen Bildschirm? Nein, denn unten (oder oben) [oder auch an den Seiten] befindet sich die Windows Taskbar.

Wird nun der WindowStyle wird auf None gesetzt, hat das Fenster keinen Rahmen, also auch keine Titelleiste und Controlbar.

Allerdings verschwindet nun auch die Taskbar und das Fenster füllt tatsächlich den gesamten Screen aus.

Nun kann z.B. eine Photoshow starten.

Problematisch wird es, wenn der Anwender versucht das Fenster zu schließen, denn es fehlt ja die Titelleiste mit dem Schließen bzw. Minimieren Button. Man sollte daher noch auf Events der Tasten ESC oder F11 reagieren. Diese werden standardmäßig in Vollbild Applikationen verwendet, um in den normalen Fenstermodus zurückzukehren.

public
partial
class
Window1 : Window

{

public Window1()

{

InitializeComponent();

this.KeyDown = RootKey;

}

void RootKey(object sender, KeyEventArgs e)

{

if ((e.Key == Key.Escape) (e.Key == Key.F11))

{

if (this.WindowStyle == WindowStyle.None)

{

this.WindowStyle = WindowStyle.ThreeDBorderWindow;

this.WindowState = WindowState.Normal;

}

else

{

this.WindowStyle = WindowStyle.None;

this.WindowState = WindowState.Maximized;

}

e.Handled = true;

}

Ob dieses Feature beabsichtigt ist; weiß ich nicht. Ob dieses Feature jede Anwendung benötigt? Eher nicht.

Wer allerdings eine Vollbild Anwendung entwicklen will, der kann auch das mit WPF tun, und zwar mit relativ wenig Aufwand.

PDC08: new XAML features

2008-10-08T11:08:00.002+01:00

XAML ist DIE deklarative Programmiersprache für .NET.

Sie findet hauptsächlich Anwendung in WPF, aber auch in WF und WCF

Auf der PDC wird sich eine Session rund um XAML drehen. Es wird gezeigt wie eine Anwendung komplett deklarativ in XAML geschrieben werden kann.

XAML wird außerdem mit XOML aus der Workflow Foundation vereinigt. Man darf gespannt sein auf welche Anwendungsbereiche XAML ausgeweitet werden wird.

Neue XAML Features werden sein:
- support für generics
- object references
- non default constructors

cu @ PDC
Benjamin

C# 4.0: dynamic

2008-10-08T09:31:00.003+01:00

C# wird dynamisch!

Das erste publik gemachte Feature von C# 4.0 sind dynamic lookups. Diese werden durch das neue Schlüsselwort - dynamic - ermöglicht.

Dynamic lookups ermöglichen das Auflösen von Namen zur Laufzeit und nicht zur Compilezeit. Das bedeutet, dass dies ein neues Runtime Feature ist, denn ein Sprachfeature von C#. Alle .NET Sprachen können also diesen dynamic lookup verwenden. VB.NET konnte dieses Szenario bereits umsetzen - besser bekannt als "Late Binding" - , musste jedoch deafür auf eigene Methoden aus der Microsoft.VisualBasic.dll zurückgreifen. (Daher musste man bisher immer diese DLL deployen, wenn man .NET in VB programmiert hat).

Dynamic Lookups sind in der DLR (Dynamic Language Runtime) implementiert und für dynamische Sprachen unerlässlich.

Das folgende Beispiel ist den Slides der Keynote von Anders Hejsberg auf der JAOO entnommen

Olso und D#

2008-09-10T08:45:00.002+01:00

Während die PDC immer näher rückt, werden die ersten heiß erwarteten Neuerungen bekannt. Unteranderem kommen immer mehr Details zum Vorschein, zu der langerwarteten Plattform Olso, die Teil des .NET Framework 4.0 sein wird.

Don Box ist einer der Architekten von Oslo und gibt in seinem Blog kleine versteckte Hinweise. Heute wies er auf einen interessanten Artikel hin, der weitere Geheimnisse zu Olso enthüllt.

Nach LINQ wird dieses Jahr ein weiterer Hammer vorgestellt werden:
Textuelle Domain Specific Languages (DSL)

Microsoft hat bereits ein DSL Toolkit mit dem man graphische DSL erstellen kann. Diese können dann über einen Designer in VisualStudio verwendet werden. Das Neuartige and denOslo DSL ist, dass sie wie eine eigene Programmiersprache funktionieren; also textuell. Diese TDSL basieren auf dem Microsoft Research Projekt TLA+ (T-emporalen L-ogik der A-ktionen)

Übrigens der Codename für diese TDSL ist "D".
Vielleicht bekommen wir nach C# nun ein D# !?

C.U. at PDC
Benjamin

PDC2008 I'm comming

2008-05-29T06:32:00.002+01:00

Bei der letzten PDC habe ich mir noch alle Sessions online angesehen.

Jetzt bin ich LIVE dabei!

Themen werden sein:

- The Live Developer platform, including the MESH.
- Cloud Computing" from computation, to storage and much more!
- Visual Studio 10" and .NET Framework 4.0
- ASP.NET Futures including v.next of MVC, Ajax and Dynamic data
- Silverlight Futures, including Silverlight for business applications
- And much, much more.

StackPanel Items in umgekehrter Reihenfolge anzeigen

2008-05-08T16:27:00.001+01:00

Das StackPanel in WPF kann Controls untereinander anordnen.

Mit der Eigenschaft Orientation=Horizontal ist es möglich auch die Elemente von Links nach Rechts anzuordnen.

Es gibt aber keine Eigenschaft StackItemsFrom="Top|Bottom".

Natürlich kann man ein eigenes StackPanel implementieren, das dies kann. Es geht aber auch einfacher.

Am Anfang war das ItemsControl

Wir benötigen zunächst ein ItemsControl. Ein ItemsControl kann beliebige Objekte, also auch Double, Boolean, Person etc., aufnehmen. Ein Panel hingegen nur Controls.

Das ItemControl benötigt jedoch ein Panel um die Objekte darstellen zu können. Standardmäßig ist dies ein StackPanel.

Über die Eigenschaft ItemsPanel können wir ein ItemsPanelTemplate definieren, und ein anderes von Panel abgeleiteten "Panel" angeben, in das nun die Items angeordnet werden.

Wie die Objekte aussehen bestimmt ein DataTemplate. Für jedes Objekt generiert das ItemsControl einen Container (ContentPresenter, für ListBox -> ListBoxItem). Da man auf diesen Container nicht direkt zugreifen kann, definiert das ItemsControl eine Property um den Style für den "ItemContainer" festlegen zu können.

Verkehrte Welt

Um nun die Elemente von unten nach oben statt von oben nach unten anordnen zu können, wie es das StackPanel macht, benötigen wir ein anderes Panel. Ein DockPanel ist geeignet, da es mehr als eine Möglichkeit gibt, Elemente in ihm anzuordnen. (Top,Left,Right,Bottom).

Nun müssen wir noch im ItemContainerStyle festlegen, dass die Elemente jeweils von Unten angeordnet werden sollen.

<ItemsControl.ItemsPanel>

</ItemsPanelTemplate>

</ItemsControl.ItemsPanel>

<ItemsControl.ItemContainerStyle>

<Style>

</Style>

</ItemsControl.ItemContainerStyle>

</ItemsControl>

Et Voila

AttachedProperties richtig initialisieren

2008-05-08T12:04:00.001+01:00

Manchmal ist es angebracht, nachdem sich ein Objekt bei einem AttachedProperty registriert hat, einige Initialisierungen durchzuführen. Hierbei kann in der Set Methode, nach dem Setzen des AttachedProperty, z.B. eine Initialisierungsmethode aufgerufen werden.

public
static
void SetAttachedProperty(DependencyObject obj, int value)

{

obj.SetValue(AttachedProperty, value);

InitializeProperty();

}

Die Set-Methode macht nichts Weiteres, als bei dem übergebenen DependencyObjekt SetValue aufzurufen. Der eigentliche Wert der AttachedProperty wird also wie eine ganz normale DependencyProperty gesetzt. Stellen Sie sich einfach vor, eine DependencyProperty ist nichts anderes als ein Schlüssel der zusammen mit einem Wert in einem Dictionary gespeichert wird. Jedes DependencyObject hat so ein Dictionary. Die Werte können aber auch von anderen Objekten abgefragt und gesetzt werden.

Um eine AttachedProperty zu setzen, reicht es tatsächlich lediglich die DependencyProperty am eigenen Objekt zu setzen und nicht am Containerobjekt durch Set[Property]! Das bedeutet aber auch, dass die Initialisierungsmethode nicht mehr aufgerufen wird, da die AttachedProperty über einen anderen Weg gesetzt wird. Nun kann man es natürlich zur Konvention machen in dem in einem API vorschreibt, dass AttachedProperties immer über Set[Property] gesetzt werden müssen. So ist der XAMLReader drauf angewiesen, dass wenn er eine AttachedProperty im Markup erkennt, auch eine entsprechende Set-Methode verfügbar ist, die er aufrufen kann.

Trotzdem ist es besser eine Initialisierung anders durchzuführen. Wie? Über einen Callbackmechanismus. Jede DependencyProperty verfügt über Metadaten die es erlauben, Code bzw. Callbacks für Validierungen, Änderungen etc. zu hinterlegen. Ändert sich z.B. der Wert einer DependencyProperty, so wird der Callback aufgerufen und die Initialisierung kann durchgeführt werden. Dieser Mechanismus funktioniert unabhängig davon wie eine DependencyProperty, gesetzt wurde.

public
static
readonly
DependencyProperty PropertyWithCallback;

//Definition der Metadaten mit Callback

PropertyMetadata metadata = new
PropertyMetadata();

metadata.PropertyChangedCallback += OnPropertyWithCallbackChanged;

//Registrierung der DependencyProperty

PropertyWithCallback = DependencyProperty.RegisterAttached("PropertyWithCallback",

typeof(int), typeof(Window1), metadata);

//Der Callback ruft die eigentliche Initializierungsmethode auf

private
static
void OnPropertyWithCallbackChanged(DependencyObject obj, DependencyPropertyChangedEventArgs value)

{

InitializeProperty();

}

Eigene Linien in Grid Panel zeichnen

2008-05-07T08:36:00.002+01:00

Das Grid ist das Mächtigste und am Häufigsten gebrauchte Panel in WPF.

Mit der Eigenschaft "ShowGridLines" lassen sich Hilfslinien anzeigen.

Diese Linien dienen nur als Hilfestellung für den Entwickler, der so die Position der Spalten und Reihen erkennen kann.

Leider kann man nicht selber bestimmen wie diese Linien aussehen. Oder etwas doch?

Was passiert eigentlich im Grid wenn ShowGridLines=True gesetzt wird?

WPF-Controls können sich selbst zeichnen, in dem sie die OnRender Methode überschreiben. Wie dies auch bei OnPaint in WinForms der Fall ist.

Doch beim Grid wird davon nicht Gebrauch gemacht um die Linien zu zeichnen! Stattdessen wird zu den logischen UI-Elementen in dem Panel ein zusätzliches visuelles Element der "GridLinesRenderer" hinzugefügt. Dies geschieht nicht per ControlTemplate. (Templates ändern ebenfalls das Aussehen also den VisualTree), sonder programmatisch durch den Aufruf von AddVisualChild(visual) in der Basisklasse.

Der GridLinesRenderer ist von DrawingVisual abgeleitet. UIElement und DrawingVisual haben also den Selben Vorfahr "Visual". DrawingVisuals sind jedoch wesentlichen performanter als UIElements, da sie direkt auf den "Bildschrim" (WPF-Subsystem) zeichnen.

Der VisualTree im XamlPad zeigt, dass neben dem logischen Child – einem Button - noch ein visuelles Element - der GridLinesRenderer - in der Hierarchie zu finden ist.

Möglichkeit 1: Einen eigenen GridLinesRenderer schreiben

Meine erste Idee war es einen eigenen GridLinesRenderer zu schreiben. Ganz nach dem Vorbild des in dem Grid zu findenden Renderer.

Das Problem ist, dass es nicht möglich ist den Renderer in den VisuallTree des Grid einzufügen. Die Methode die dieses möglich machen würde – AddVisualChild – ist nämlich protected.

Ein eigenes Grid zu erstellen, nur um die GridLinien zeichnen zu können war mir dann aber zu aufwändig.

Es muss einen anderen Weg geben.

Möglichkeit 2: Einen GridLinesAdorner schreiben

Wenn es keine Möglichkeit gibt ein UIElement von Innen zu verändern ohne ein eigenes Control abzuleiten, so muss man es eben von Außen probieren. Das machen sog. Adorner.

Adorner "verzieren" ein UIElement. Wie, das bestimmt der Adorner. Wichtig ist, dass ein Adorner immer über einem UIElement gezeichnet wird. D.h. der Adorner verdeckt darunter liegende Zeichnungen.

Public
Class GridLinesAdorner

Inherits Adorner

Private Grid As System.Windows.Controls.Grid

'Übergabe des zu verzierenden Elements (hier Grid)

Sub
New(ByVal grid As System.Windows.Controls.Grid)

MyBase.New(grid)

Me.Grid = grid

End
Sub

Private _pen As Pen

'Stift um die Linien zeichnen zu können

Public
Property Pen() As Pen

Get

Return _pen

End
Get

Set(ByVal value As Pen)

_pen = value

End
Set

End
Property

'Zeichnen der Linien

Protected
Overrides
Sub OnRender(ByVal dc As System.Windows.Media.DrawingContext)

If Pen Is
Nothing
Then
Exit
Sub

If Grid.ColumnDefinitions.Count > 0 Then

Dim x As
Double

For i As
Integer = 1 To Grid.ColumnDefinitions.Count - 1

x = Grid.ColumnDefinitions(i).Offset

dc.DrawLine(Pen, New Point(x, 0), New Point(x, Grid.ActualHeight))

End
If

If grid.RowDefinitions.Count > 0 Then

Dim y As
Double

For i As
Integer = 1 To Grid.RowDefinitions.Count - 1

y = Grid.RowDefinitions(i).Offset

dc.DrawLine(Pen, New Point(0, y), New Point(Grid.ActualWidth, y))

End
If

End
Sub

End
Class

Die Methode OnRender führt nun das Zeichnen der Gridlinien durch. Über die Row- und ColumnDefinitions des Grid, kann der Offset der einzelnen Spalten vom Grid abgerufen werden. Diese dienen uns als Koordination um an diesen Stellen die entsprechenden Linien zu zeichnen.

Anwenden des Adorners

Um den Adorner zum Einsatz zu bringen, müssen wir nun noch die Code-Behind Datei anpassen. Leider ist es nicht möglich den Adorner in XAML direkt anzuwenden. (Die Klasse AdornerDecorator ist nur dafür da einen Layer für ein zu verzierendes Element bereitzustellen, worauf ein Adorner angewendet werden kann; aber nicht für den Adorner selbst.)

Class Window1

Private
Sub Window1_Loaded(ByVal sender As
Object, ByVal e As System.Windows.RoutedEventArgs) Handles
Me.Loaded

'Layer für das Element holen in dem der Adorner gezeichnet wird

Dim layer As AdornerLayer = AdornerLayer.GetAdornerLayer(Me.Grid)

'Adorner mit Stift erstellen

Dim adorner As
New GridLinesAdorner(Grid)

adorner.Pen = New Pen(Brushes.Black, 2)

'Adorner dem Layer hinzufügen

layer.Add(adorner)

End
Sub

End
Class

Das Ergebnis

Wer noch einen Rahmen um das Grid herum haben möchte, der brauch nur noch das Grid in ein Border zu packen.

Achtung: Wie man sieht wird der Adorner über das Grid gezeichnet. Daher sind die Ränder der im Grid befindlichen Buttons nicht ganz zu sehen.

Hier muss dann noch ein entsprechendes Margin auf die Buttons angewendet werden um den richtigen Abstand zu den Gridinnenseiten zu ermöglichen.

WPF goes Transitions

2008-04-29T21:02:00.002+01:00

Effekte a la PowerPoint? Mit WPF kein Problem!?

WPF bietet zwar Animationsunterstützungen, doch diese müssen mühsam programmiert werden.

Nun gibt es ein Framework das Übergangseffekte für WPF bereitsstellt.
z.B. Wipe, Fade, oder RotatingCube. Auch aufwendige 3D Animation sind frei verfügbar.

Entwickelt hat dies Jaraed Bienz.
Download auf CodePlex: Transitionals

Wer jetzt vielleicht sagt: "He, das habe ich schonmal gesehen!"
der hat vollkommen recht. Auf der letzten Basta habe ich einen Vortrag über CAB gehalten und auch Acropolis vorgestellt. Für mich hatte Acropolis keine Zukunfstaussichten (Wurde ja auch eingestampft). Jedoch einige Bestandteile hatten Potential in WPF intigriert zu werden. U.a. auch das Transitionframework.

Zwar ist das Transitionframework (noch) kein Teil von WPF. Aber dennoch sehr nützlich, zumal frei zugänglich und erweiterbar.

Basta! 2008 Spring Edition

2007-12-10T17:24:00.000Z

Schon zum 2. Mal werde ich auf der BASTA! sprechen.

Meine Session(s)

Reflection in Action

Reflection gehört zu den coolesten und nützlichsten Features von .NET. In dieser Session schauen wir uns die bekannten und unbekannten Möglichkeiten von Reflection an. U.a. Wie performant ist Reflection und wie kann man die Performance optimieren? Wie generiert man dynamisch IL Code und kann ihn wieder auslesen!? Und vieles vieles mehr.

Allein dafür lohnt es sich auf die BASTA! zukommen.

Benny

PDC2008 announced!

2007-12-07T09:39:00.000Z

Nachdem die PDC2007 ausgefallen ist, weil "zu wenig Neues" und die TechEd2007 Europe tatsächlich wenig Neues zu bieten hatte, findet sie nun statt:

die PDC2008 in Los Angeles!

Link

Vermutliche Themen:
- .NET Framework 4.0
- Volta (MSIL Recompiler)
- Software + Services
- WPF Composite Smart Clients
- (hoffentlich neue (WPF Controls bzw. Features))
- Silverlight 2.0 und DLR

Urlaub ist schon geplant!

Benny

WPF Composite Clients formally known as Acropolis

2007-10-30T07:39:00.000Z

Das war es also mit "Acropolis". Dem Produkt das eigentlich CAB (Composite UI Application Block) ersetzen sollte...

Hier die offizielle Bekanntmachung:
Acropolis Team Blog

Die Erkenntnisse aus dem Acropolis Projekt werden zerstückelt und fließen in die .NET Klassenbibliothek ein (Version 4.0?). Dies Vermutung habe ich bereits auf der BASTA! 2007 in Mainz geäußert, wo ich einen Vortrag über CAB gehalten habe und einen Ausblick auf Acropolis gezeigt habe. Ein Artikel für das dotnet Magazin war bereits in Arbeit. Aber eine innere Stimme hat mich zurückgehalten weiter zu machen. Jetzt weiß ich warum!

Von Seiten der CAB-Community hagelte es eine Menge Kritik an Acropolis. Der Ärger bestand darin dass CAB und die Smart Client Software Factory nicht mehr weiterentwickelt werden. Stattdessen wurde das ehrgeizige Projekt Acropolis hochgezogen, dass viel wollte aber nichts konnte. Das größte Problem war eine nicht existierende Roadmap für das Produkt.

Hier ein Kommentar dazu aus der CAB Comunity.

Requiem for Acropolis; Fanfare for CAB +

Aber es gibt schon wieder ein Neues Projekt: WPF Composite Clients

Diesmal wieder unter der Leitung der Patterns & Practices Group. Hier fließt die ganze Erfahrung aus CAB mit ein. Acropolis ist (war) nähmlich ein Projekt der UIFX Teams, das für ASP.NET und WPF zuständig ist.

Glen Block bescheibt in seinem Blog das neue Projekt.
Glenn Block

WPF Composite Client ist keine neue Version von CAB. Es wird eine neue Library und Guidance geben. Zielplattform ist WPF. Der Grund für den Aufbau einer neuen Klassenbibliothek besteht darin, dass CAB nicht für WPF designt wurde. WPF bringt eigene Konzepte wie Commands und RoutedEvents mit sich, die es in WinForms nicht gibt und somit auch nicht in CAB unterstützt werden.

WPF bietet außerdem eine komplette andere "experience". Es wird daher keinen Migrationspfad von WinForms geben. (So wie dies noch in Acropolis vorgesehen war).

Wie herausklang wird es weiter Verbesserungen an WinForms geben! WinForms geht also noch nicht in Rente.

Ich lass erstmal die Korken knallen, dass wir das Thema Acropolis hinter uns lassen können! Ich habe schon befürchtet, dass wir uns ernsthaft mit dem Produkt auseinandersetzen müssen!

CSV Dateien verarbeiten mit LINQ

2007-10-10T12:25:00.000+01:00

Mein erster (langer) Artikel in der dotnetpro (http://www.dotnetpro.de/) ist erschienen!

Ich zeige, dass man mit LINQ nicht nur Datenbanken ansprechen kann, sondern ganz simple auch CSV Dateien einlesen, filtern und ausgeben kann. Mit LINQ und C# 3.0 ist das eine Sache von 3 Zeilen Code.

Auf die Idee bin ich durch den Contest der dotnetpro gekommen. Die Aufgabenstellung war CSV Daten zu verarbeiten. Es war abzusehen, dass die jeder mit einer Datenbank angehen würde. Der eine verwendet SQLServer, der andere MySQL. Besonders beliebt bei dem Contest war aber SQLLight.

Und der der Gewinner ist....

Gewonnen habe ich dann, mit meiner Lösung nicht. Und das obwohl ich 25% schneller war als die Siegerlösung!!!
(Ja Mama! Es waren wieder einmal die Flüchtigkeitsfehler)

Neulich auf der BASTA

2007-09-22T16:14:00.000+01:00

Hallo,

da bin ich also Zurück vom Abenteuer BASTA. Ich kann nur sagen ich hab's überlebt!

Die Keynote sollte eigentlich Dirk Primps halten. Das hat er aber irgendwie verpennt!
Er wurde natürlich von den anden Speakern ständig daran aufgezogen.

Das Essen beim Speakerdinner war nicht nach dem Geschmack der Meisten. So gab es z.B. Schafskäse an Raffaello. Das Essen auf der Konferenz war tiefkühlfraß und schlimmer als bei McDonalds. Kein Wunder, dass einige Teilnehmer und auch Speaker so ihre Probleme hatten. Holger S. hat seine Session mit Durchfall gehalten, Neno stand aber bereit um für Ihn einzuspringen.

Christian Groß hat sich bei seinem Workshop, das Handy eines Teilnehmers geschnappt und sich damit auf den Boden geworfen! Er wollte das Thema Security etwas verdeutlichen.

Der Oberhammer war Oliver Sturm. Hat er doch die 10 coolsten Features in C# 3.0 gezeigt. Er hat sich extra einen Timer programmiert und die Features auf die Sekunde vorgeführt. Man hat er die Leute weggeblasen. Er von Dingen geredet die die Leute noch in C# 5.0 kappieren werden.

Feucht fröhlich ging es beim Abschlussessen weiter:
Jörg N.: "Jetzt geht schon wieder die Diskussion los, was besser ist C# oder VB
Jörg N.: "Ich bin einfach nur müde"
Benny G.: "VB ist eine Lebenseinstellung"
Daniel F.: "VB ist eine Krankheit"
Oliver S.: "VB ist eine Lebenseinstellung -
so wie Arbeitslosigkeit!"

In diesem Sinne, bis zur nächsten BASTA!

Benjamin

Der Name "InitializeComponent" wurde nicht deklariert

2007-09-08T20:08:00.000+01:00

Hallo WPF Freunde!

In letzter Zeit verwende ich immer mehr WPF in meinen Anwendungen. Ganz auf WinForms möchte ich aber nicht versichten. Aus Gewohnheit nehme ich für einen neues VisualStudio Projekt die Projektvorlage "WinForms Anwendung". Wenn ich nun versuche ein WPF-UserControl zu meinem Projekt hinzufüge erscheint beim Kompilieren diese Fehlermeldung:

Der Name "InitializeComponent" wurde nicht deklariert

Mir kamen sofort einige Fragen in den Sinn:
-Habe ich .NET 3.0 richtig installiert?
- Habe ich die .NET 3.0 Extensions für VisualStuido richtig installiert?
- Ist meine XAML Datei in Ordnung?
- Macht ExpressionBlend die Probleme (damit designe ich die UserControls)?

Die Lösung ist dann doch relativ einfach.
Man muss die Projektdatei *.proj öffnen und dem BuildSystem von VisualStuido MSBuild mitteilen wie es XAML und Code-Behind Dateien zu kompilieren hat.

Diese Zeile muss man einfügen:

<import project="$(MSBuildBinPath)\Microsoft.WinFX.targets">

Klar, dass die normale .NET 2.0 WinForms Anwendung Projektvorlage noch nichts von XAML und WPF gehört hat und dementsprechend die Dateien nicht richtig kompilieren kann.

Benjamin Gopp

LINQ wird missverstanden!

2007-08-05T09:18:00.000+01:00

In der Ausgabe 9 des dotnet magazins ( http://www.dotnet-magazin.de ) sind in der OpenStage Kolumne meine Gedanken zu LINQ abgedruckt. Nachdem der Artikel nun erschienen wird er auch hier "abgeblogged".

Mittlerweile habe ich schon dutzende Artikel und Vorträge zu LINQ gehört. Und immer wieder sehe am Inhalt der Vorträge und den Reaktionen, dass LINQ missverstanden wird. Auch die Innovatoren von LINQ tragen nicht gerade zur Klarheit bei. Ein typisches (schlechtes) LINQ-Beispiel ist:
From c in Customer Where c.City == “London“ Select c
Dieses Beispiel suggeriert, dass man es hier mit SQL zu tun hat. Zugegeben etwas verdrehtes SQL, das From steht vorne und das Select hinten, aber es sieht nach SQL aus. Die Assoziation die dabei unweigerlich beim Programmierer entsteht ist Folgende: Linq … SQL … Datenbank; Ah! Linq ist für Datenbanken bestimmt. Die ganze Power von LINQ verpufft in diesem Moment, wo LINQ mit SQL gleich gesetzt wird und auf die Verwendung von Datenbanken reduziert wird.
Liege ich mit meiner Einschätzung so falsch? Ein Blick in das LINQ MSDN-Forum zeigt, dass über 90% der Fragen auf die Verwendung von LINQ in Verbindung mit Datenbanken abzielen. Da wird von LINQ sogar als O/R Mapper gesprochen.
Auch die LINQ Queryoperatoren tragen nicht gerade dazu bei, dass man sich von SQL unterscheiden will. From, Select, Where - diese kennen wir alle von SQL. Was LINQ gerade auszeichnet, ist aber dass man alle Datenquellen befragen kann, also auch Objekte und XML etc.. Was vorher nur auf Datenbanken beschränkt gewesen ist, ist nun für andere Datenquellen möglich. Das ist das Revolutionäre an LINQ! Ein einheitliches Konzept um Daten abzufragen!
Natürlich muss auch ein einheitliches API für LINQ gefunden werden. Es kann schlecht sein, dass man um Datenbanken abzufragen eine andere Syntax verwenden muss, als für XML oder Objekte. Das hatten wir nämlich bisher: SQL für Datenbanken, XPath für XML und diverse Methoden für Arrays. Damit soll nun Schluss sein. Warum gerade aber LINQ so nah an SQL angelehnt ist, kann ich nicht verstehen. Vielleicht will man damit LINQ schneller etablieren. Langfristig gesehen wird man sich damit aber Probleme einhandeln. Wir können erwarten, dass mit der Zeit LINQ Implementationen für exotischere Datenquellen, auftauchen werden. Dann mag eine SQLnahe Syntax nicht mehr passend sein! Und dann sind wir bei dem Punkt angelangt, was LINQ eigentlich vermeiden wollte, nämlich fester Bestandteil einer Programmiersprache zu werden. Denn Programmiersprachen leben länger als APIs.

My Extensions in VS2008

2007-07-28T20:53:00.000+01:00

Nach einem Tag downloaden und Installation, habe ich nun endlich die Beta2 von Visual Studio 2008 "Orcas" auf meinem Rechner.

Aufgefallen ist mir der neue Projekttab "My Extensions"

Sollte es damit einfacher möglich sein neue Erweiterungen für den My Namespace zu erstellen?

Der Link "Learn more about customizung the My Namespace" war leider tot. Auch nachdem ich die 2Gig große VS2008MSDN runtergeladen und installiert hatte.

Gefunden habe ich dann doch noch, wonach ich gesucht hatte. Und zwar die Quelldatei für die WPF My Extensions, die bereits in Orcas auszuwählen sind. Diese befindet sich unter dem Ordner "My Project" in dem Ordner "MyExtensions". Dort wird man dann auch in Zukunft eigene Extensions für den My Namespace ablegen können.

Bleibt nach wie vor die Frage: Woher weiß VisualStudio, dass eine "My Extension" vorhanden ist? Ich habe weder eine Assembly noch ein Item-Template gefunden, dass die Vorlage für die "WPF My Extension" liefert. (Eine entsprechende Frage wie man denn diese My Extensions verwendet habe ich gleich nach der Entdeckung in das MSDN Forum gestellt. Mal gucken ob in nächster Zeit eine Anwort darauf zu finden ist.)

Demnächst erscheint ein Artikel von mir im dotnet.magazin über das Erstellen eines eigenen My Namespaces. Der My.Data Namespace bietet einfachen Zugriff auf eine im Vorhandene Datenbank. Der Artikel ist deswegen nur noch nicht fertig, weil das Deployment von My Extensions Probleme macht. Die Erweiterungen bestehen nämlich aus generiertem Code, der von den Projekteinstellungen abhängt, und kann deswegen nicht als Assembly verteilt werden. Es bleibt also nur noch ein Item-Template übrig für ein simples Deployment. Wenn man eine Vollintegration haben will, muss man wohl oder übel ein eigenes Add-In für Visual Studio schreiben. Das finde ich aber zu Aufwendig.

Auf der Basta 2007 Spring hatt ich mit Jay Schmelzer (Principal Program Manager Visual Basic) meine My.Data Erweiterung vorgestellt und mit ihm darüber gesprochen, wie man eigene My Erweiterungen in Visual Studio integrieren kann. Er versprach dies für Orcas mit einzuplanen.

Schade Jay, das war eigentlich nicht das, was ich mir vorgestellt hatte!

#If _MyType <> "Empty" Then
Namespace My
'''

''' Module used to define the properties that are available in the My Namespace for WPF
'''

'''
_
Module MyWpfExtension
Private m_Computer As New ThreadSafeObjectProvider(Of Global.Microsoft.VisualBasic.Devices.Computer)
Private m_User As New ThreadSafeObjectProvider(Of Global.Microsoft.VisualBasic.ApplicationServices.User)
Private m_Windows As New ThreadSafeObjectProvider(Of MyWindows)
Private m_Log As New ThreadSafeObjectProvider(Of Global.Microsoft.VisualBasic.Logging.Log)
'''

''' Returns the application object for the running application
'''

Friend ReadOnly Property Application() As Global.System.Windows.Application
Get
Return Global.System.Windows.Application.Current
End Get
End Property
'''

''' Returns information about the host computer.
'''

Friend ReadOnly Property Computer() As Global.Microsoft.VisualBasic.Devices.Computer
Get
Return m_Computer.GetInstance()
End Get
End Property
'''

''' Returns information for the current user. If you wish to run the application with the current
''' Windows user credentials, call My.User.InitializeWithWindowsUser().
'''

Friend ReadOnly Property User() As Global.Microsoft.VisualBasic.ApplicationServices.User
Get
Return m_User.GetInstance()
End Get
End Property
'''

''' Returns the application log. The listeners can be configured by the application's configuration file.
'''

Friend ReadOnly Property Log() As Global.Microsoft.VisualBasic.Logging.Log
Get
Return m_Log.GetInstance()
End Get
End Property
'''

''' Returns the collection of Windows defined in the project.
'''

Friend ReadOnly Property Windows() As MyWindows
_
Get
Return m_Windows.GetInstance()
End Get
End Property
_
_
Friend NotInheritable Class MyWindows
_
Private Shared Function Create__Instance__(Of T As {New, Global.System.Windows.Window})(ByVal Instance As T) As T
If Instance Is Nothing Then
If m_WindowBeingCreated IsNot Nothing Then
If m_WindowBeingCreated.ContainsKey(GetType(T)) = True Then
Throw New Global.System.InvalidOperationException("The window cannot be accessed via My.Windows from the Window constructor.")
End If
Else
m_WindowBeingCreated = New Global.System.Collections.Hashtable()
End If
m_WindowBeingCreated.Add(GetType(T), Nothing)
Return New T()
m_WindowBeingCreated.Remove(GetType(T))
Else
Return Instance
End If
End Function
_
Private Sub Dispose__Instance__(Of T As Global.System.Windows.Window)(ByRef instance As T)
instance = Nothing
End Sub
_
_
Public Sub New()
MyBase.New()
End Sub
Private Shared m_WindowBeingCreated As Global.System.Collections.Hashtable
Public Overrides Function Equals(ByVal o As Object) As Boolean
Return MyBase.Equals(o)
End Function
Public Overrides Function GetHashCode() As Integer
Return MyBase.GetHashCode
End Function
_
Friend Overloads Function [GetType]() As Global.System.Type
Return GetType(MyWindows)
End Function
Public Overrides Function ToString() As String
Return MyBase.ToString
End Function
End Class
End Module
End Namespace
#End If

Wie kann ich Controls in einer Form zentrieren?

2007-07-16T12:47:00.000+01:00

Ich habe eine sehr einfache Methode herausgefunden um ein beliebiges Steuerelement in einer Form zu zentrieren; also genau mittig anzuzeigen. Wenn die Form verschoben wird, soll natürlich auch die Position des Controls wieder an die neue Mitte verschoben werden.

Meine Lösung erfordert keinen Code!

Man nehme ein TableLayoutPanel und stellt seine Dock Eigenschaft auf Dock.Fill. Nun füllt das Panel die ganze Form aus. Dann reduziert man das Panel auf genau 1 Zelle, d.h. RowCount und ColumnCount = 1. Auchtung eine Zelle kann immer nur 1 Control beinhalten. Wer daher mehere Elemente mittig anzeigen lassen will muss ein weiteres Panel verwenden in das er diese Elemente einfügt. Das Control wird nun auf Anchor = Anchor.None gesetzt. Siehe da das Control befindet sich nun immer in der Mitte!

Achtung! .NET 3.5 Beta1 und .NET 3.5 June CTP inkompatibel!

2007-07-13T13:55:00.000+01:00

Achtung bei dem Ausprobieren von Programmen, die unter Orcas erstellt worden sind. Orcas installiert standardmäßig das .NET Framework 3.5 Beta1 vom April 2007. Wer sich bereits die neue Juni CTP runtergeladen hat, wird Programme die LINQ verwenden nicht ausführen können. Es erscheint folgende Fehlermeldung:

Der Typ System.Linq.Func`2 in der Assembly System.Core, Version 2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561924e089 konnte nicht geladen werden.

LINQ macht excessiven Gebrauch vom generischen Delegate Func<>. Dieser wurde nun in einen anderen Namespace verfrachtet. Statt bisher im Namespace System.Linq ist Func<> im Namespace System zu finden. Er ist somit überall verfügbar, ohne dass man einen bestimmten Namespace einbinden muss. Denn im Namespace System befinden sich alle Grundlegenden Datentypen.

Hinzugekommen sind nun auch diverse Überladungen des Action-Delegate. Es ist nämlich bisher nicht möglich einen Delegate Func zu erstellen. Jedoch kann man einen normalen Delegate delegate void Action(T obj) erstellen.

Hier nochmal die vorgefertigten Delegates in der Übersicht:

TReturn Func
TReturn Func
TReturn Func
TReturn Func
TReturn Func

void Action
void Action
void Action
void Action

WPF: Wie erstelle ich einen autoskalierenden Text?

2007-07-09T11:45:00.000+01:00

Es hat lange gebraucht bis ich mich an WPF (Windows Presentation Foundation) rangewagt habe. Ich erkenne aber immer mehr die Vorzüge von WPF. Z.B. erstelle ich gerade für eine Anwendung einen animierten Splash-Screen bzw. Intro. Das gibt natürlich wesentlich mehr her als ein statisches Bitmap auf dem das Anwendungslogo zu sehen ist. Ich brauche nicht zu erwähnen, dass dies mit GDI+ echt aufwändig wäre und lange nicht so gut aussehen würde wie mit WPF.

Der Splash-Screen soll natürlich voll Vektrobasiert sein, d.h. alle Grafiken, Text und Animationen, sollen sich der Größe des Fensters anpassen. Doch wie schaffe ich es, dass die Schriftgröße eines Textes in einer TextBox automatisch skaliert wird? Ich habe lange gesucht, und keine passende "einfache" Einstellung gefunden, wie z.B. TextBox.Strech = Fill; Hieran sieht man, dass WPF noch nicht ganz ausgereift ist. Es sind zwar viele Grundelemente vorhanden, die man zu anderen komplexen Elementen zusammenstellen kann, aber das muss man halt selber machen. Zudem braucht man eine Menge Wissen über WPF, was man am Anfang natürlich nicht hat. Wenn man also eine DataGridView in WPF braucht, wird man nicht direkt rangehen können, um sich eine eigene DataGridView zu bauchen; auch wenn die dafür erforderlichen Grundelemente vorhanden sind. 1. Braucht man viel Efahrung mit WPF und 2. kostet es enorm viel Zeit.

Aber zurück zu unserem skalierbaren Text.

Wir benötigen zunächst das Tool ExpressionBlend. Meine Lösung kann nicht programmiert werden, sondern benötigt ein Feature von ExpressionBlen

1. Wir nehmen einen TextBlock. (Achtung keine normale TextBox!)
2. Wir schreiben einen Text in unseren TextBlock. Es können auch andere Elemente wie Elipsen, Controls etc. zwischen dem Text stehen. Das ist mit einem TextBlock möglich. Dann die Schriftart und andere Einstellungen setzen.
3. Wir konvertiere nun den TextBlock in einen Path. Menü->Objekt->Pfad->in Pfad konvertieren. Alle Elemente des TextBlock auch der Text wird in einen Pfad konvertiert. Dieser Pfad besteht aus relativen Punkten die Vektororientiert sind und somit voll skalierbar.
4. Wir umgeben den Pfad mit einer ViewBox. Diese ViewBox kann automatisch ihre Childelemente skalieren.
5. Tada! Fertig ist unser automatisch skalierender Text

Nachteil: wenn man den Text ändern will muss man die Schritte erneut durchführen ;-(

Es wäre natürlich auch denkbar eine Skalierung in Abhängigkeit der Fenstergröße per Databinding zu ermöglichen. Hierzu müsste man aber entsprechende Berechnungen anstellen.

Was gibt's Neues in VisualBasic 2008?

2007-06-27T19:10:00.000+01:00

Ich probiere seit einiger Zeit die neue VisualStudio Version Orcas bzw. VS2008 in der Beta1 aus. Was mich natürlich besonders daran interessiert, sind die neuen VB Features. Nach langem Suchen musste ich feststellen, dass bestimmte Funktionen noch nicht in Orcas Beta 1 zu finden sind. Das betrifft z.B. Lambda Funktionen - also inline Funktionen. Während ich in C# eine lambda-funktion so schreiben kann x => x+1 (Eine Funktion mit dem Parameter x der x + 1 zurückgibt) sollte man in VB dies schreiben können Function(x) x+1. Anscheinend kann dies der Beta Compiler noch nicht. Was blieb mir anderes übrig als mit LINQ in C# weiter zu experimentieren. (Ich muss sagen, langsam gefällt mir C#.)

Werden solche kleinen Probleme in der endgültigen Version von VB 2008 behoben sein?

Ja, die gröbsten Sachen werden wohl in VB laufen, aber man wird keine großen Sprünge machen können. Es sieht so aus als würde C# 3.0 einen Produktivitätsgewinn gegenüber VB 9.0 haben. Was besonders ironisch ist C# wird dynamischer sein als VB. (Das wird aber mit VBx sicherlich wieder aufgeholt werden) Warum?

Keine Collection Initializer in VB!
Während C# so ziemlich jeden Typ ableiten kann, kann dies VB anscheinend nicht.
Im C# kann ich einenen anonymen Typen definieren:
var obj = new { Property1 = "Hallo", Property2 = 12345};
VB
Dim obj = New With { Property1 = "Hallo", Property2 = 12345}

Was ist wenn ich ein Array erstellen will?
C#
var list = new[] {1,2,3};
VB
Dim list = New Integer() {1,2,3}

Ärgerlich ist hier, dass ich bei VB den Datentyp des Arrays angeben muss. Warum kann dieser nicht abgeleitet werden wie bei C#?

Mit C# kann man auch Auflistungen erstellen, die vom Compiler abgeleitet werden können.
var list = new[]
{
new {Property1 = "hallo"};
new {Property1 = "test"};
};

Sowohl der Anonyme Typ als auch die Anonyme Collection können abgeleitet werden. Man kann also einen ObjektInitializier (also {Property=Value}) auch verschachteln und damit Collections bauen.

http://oakleafblog.blogspot.com/2007/06/will-visual-basic-90-have-collection.html sagt, dass auf mysteriöse Weise in den neusten HandsOnLabs zu VB 9 alle Verweise auf Collection Initializer verschwunden sind. Noch schlimmer: Keins der angeführten Beispiele soll funktionieren. Wie man also in Zukunft dieses C# Beispiel in VB umsetzten wird, ist also noch unklar.

Was gibt es sonst Neues? http://www.panopticoncentral.net/archive/2007/06/27/21113.aspx

Das InternalsVisibleToAttribute wird endlich vom VB Compiler erkannt. Damit ist es möglich, dass man die mit Friend gekennzeichneten Klassen und Member aus einer anderen Assembly aufrufen kann. Dies ist für UnitTests wichtig! Zwar konnte man bisher schon dieses Attribut in VB verwenden, aber die entsprechenden Friend Klassen wurden nicht angezeigt.
Relaxed Delegates. Hat man z.B. einen Click EventHandler für einen Button und man möchte dieses Ereignis verarbeiten, musste man immer die entsprechende Signatur des EventHandler Delegates als Verarbeitungsmethode schreiben. In der Regel also Button1_click(sender as Object, e as EventArgs). Das war lästig, da weder sender noch e benutzt wurden (Es sei den EventArgs hatte wirklich wichtige Argumente). Es wird aber nicht das sog. Currying unterstützt, d.h. dass man auch nur einen Parameter verwenden kann, statt alle Parameter wegzulassen.
VB Programme können auch ohne Microsoft.VisualBasic.dll kompiliert werden. Der VB Compiler hat bisher für bestimmte late-binding Funktionen von VB dieses Dll benötigt.
Es können Objektmember auf Interfaces aufgerufen werden. Es gibt zwar keine Beispiele hierzu, aber ich stell mir das als Extrem LateBinding vor. Beispiel:

Interface ITest

Sub CallFunktion

End Interface

Class Person Implements ITest

Property Name

End Class

Dim p as ITest = New Person

p.Name

Ich könnte ein Objekt zu einem Interface casten und dann auf diesem Interface ein Member des Objekts aufrufen, obwohl die Variable ja jetzt ein Interface ist. (Wofür soll das gut sein???)

Es wird einen ? Operator wie in C# geben, um If Else Condition in Kurzform schreiben zu können. (Was für ein Blödsinn!)

Was wird nicht umgesetzt?
Erlaubt es C#, dass in Labdas auch Statements wie - Console.WriteLine(x) - möglich sind, werden in VB nur Expressions erlaubt sein - also x+1. Dadurch wird VB um echte Funktionalität für LINQ beschnitten. Auch einen yield Operator wird es in VB nicht geben. Dadurch wird VB Programmierern die Möglichkeit genommen, wirklich produktiv und kreativ mit LINQ zu arbeiten. (Shame on you Microsoft!)

Insgesamt bin ich schon sehr enttäusch von den neuen VB Features! Echt schwache Leistung Microsoft. Ich werde wohl für den Einsatz von LINQ C# einsetzten MÜSSEN, obwohl ich lieber VB verwenden würde!

Meine erste BASTA! als Speaker

2007-06-22T12:24:00.000+01:00

Ich war etwas spät dran mit der Einreichung meiner Vorträge. Es hat aber doch noch geklappt:

Ich bin bei der BASTA! als Speaker dabei!!!

Ursprünglich waren 3 Sessions vorgesehen. Das Programm war jedoch schon sehr vollgepackt, so dass ich nur 2 Sessions halten kann. Beide wahrscheinlich am Donnerstag 21.07.2007.

Meine Sessions:

SmartClients mit CAB, SCSF und "Acropolis"
Der Composite UI Application Block (CAB) der patterns & practice Group von Mirosoft ermöglicht den Bau von komplexen, lose gekoppelten und modularen Smart Clients. CAB stellt eine Infrastruktur für Architekturmuster wie MVP/MVC, Commands und Dependency Injection zur Verfügung. UseCases, Views und Services werden in Module verpackt, die je nach Anwendungsfall oder Berechtigung in eine Shell geladen werden. Bei der Entwicklung von Applikationen mit CAB werden Sie von der Smart Client Software Factory (SCSF) unterstützt. Erfahren Sie außerdem, wie in Zukunft Smart Clients für die WPF mit dem Framework "Acropolis" aussehen werden.

Visual Studio 2005 erweitern: Ohne Add-ins!
Auch ohne ein kompliziertes Add-in schreiben zu müssen, lässt sich VS 2005 erweitern. Wie? Kommen Sie in meine Session und erfahren Sie, wie Code Snippets für Visual Studio funktionieren und wie einfach diese erstellt werden können. Lernen Sie, wie sich lästiges Tippen von immer wiederkehrendem Code durch eigene Projekt- und Item-Templates ersparen lässt. Schließlich gebe ich eine Einführung in das Guidance Automation Toolkit (GAT). Mit GAT haben Sie ein mächtiges Werkzeug durch das Sie eigene Software Factories erstellen können.

Dank dem Rhetoriktraining vom Professional Developer College mit Ralf Westphal und Renate Klein, sehe ich mich der Aufgabe 100% gewachsen.

Wir sehen uns auf der BASTA! in Mainz

Aller Anfang ist schwer!

2007-06-22T11:49:00.000+01:00

Hello World!

Jetzt habe ich es endlich geschafft meinen ersten Blogeintrag zu schreiben.
Lange habe ich überlegt, was ich eigentlich in einen Blog schreiben sollte!
Ich habe nun beschlossen einfach drauf los zu schreiben.

Warum Blogs?
Man könnte meinen Blogs haben keinerlei Nutzen. Nur wieder ein Haufen von Wichtigtuern, die das mit dem "Online-Tagebuch" missverstanden haben und tatsächlich ihr Tagebuch online stellen. 'Liebes Tagebuch, ich glaub ich bin verliebt...' oder Ähnliches.

Blogs sind mir bei meiner Arbeit sehr nützlich! Früher habe ich alle 30 Minuten meinen InternetExplorer gestartet und alle meine News Seiten geöffnent, um zu sehen ob es was Neues gibt. Heute werden meine abonierten Feeds automatisch aktuallisiert. Ich kann mehr Informationen in weniger Zeit aufnehmen. Ich muss nämlich nicht erst groß auf einer Seite danach suchen was mich interessiert. Blogs verhelfen einem, "up to date" zu sein, ohne dass man mit Newslettern überschwämt wird.

Warum Bloggen?
Konsumieren ist zwar schön, aber es ist auch schön was zurückzugeben. Ich merke wie ich durch Blogeinträge inspieriert werde. Es müssen nicht unbedingt ausformulierte Artikel sein. Nur einfache Gedanken die jemand in seinem Blog veröffentlicht hat. Sich gegenseitig intellektuell zu befruchten, finde ich sehr befriedigend.

Benjamin Gopp
HiQ-Software