Dienstag, 17. November 2009

VSTO 4.0 Runtime

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

Dienstag, 20. Oktober 2009

VS2010 Extension: ZoomEditorMargin

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

Donnerstag, 15. Oktober 2009

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

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...

Donnerstag, 25. Juni 2009

F# - Teil 1

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.

Mittwoch, 18. März 2009

Silverlight 3

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!

Mittwoch, 28. Januar 2009

WPF Window als Vollbild

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 Background="Red">



</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.