Informationspolitik

Wenn es um Windows 8 geht in offiziellen Verlautbarungen von Microsoft, glänzen C#, .NET, WPF und Silverlight meistens durch Abwesenheit. Stattdessen wird jede Menge über HTML 5 und JavaScript für eine schöne neue Welt von modernen Windows-Applikationen erzählt.

Als das vor ein paar Monaten losging, waren verständlicherweise viele Programmierer ziemlich beunruhigt und haben auf verschiedenen Wegen Microsoft um Klärung gebeten. Die Auskunft damals war: Liebe Leute, wir verstehen Eure Sorgen, aber es tut uns leid, wir können im Moment nichts sagen. Wartet bis zur BUILD Conference in den USA im September.

Es versteht sich, das dieses Schweigen Microsofts nicht zur Beruhigung beigetragen hat, wie man ziemlich deutlich z.B. an isdotnetdead.com und Open Plea by Silverlight / WPF Devs ersehen kann.

Nun kam für mich als Schweizer gestern folgende Meldung: Für die TechDays 11 in Bern am 20. und 21. Oktober, also zeitlich eine ganze Weile nach der BUILD, wird bezüglich Windows 8 umdisponiert. An den TechDays gibt es neu keine Informationen über Windows 8; wer sich als Schweizer Programmierer dafür interessiert, wartet auf einen eigenen Informationsanlass am 9. Februar 2012. Zu lesen ist das z.B. auf der TechDays-Website oder der Website des SWISS DPE Teams.

Das monatelange Schweigen von Microsoft über die zukünftigen Stossrichtungen betreffend Programmieren für Windows 8 und jetzt die Verschiebung der Orientierung der Schweizer auf den Februar 2012 finde ich persönlich nicht gut, sehe das aber noch knapp innerhalb eines „normalen“ Rahmens.

Was ich allerdings jetzt definitiv nicht mehr verstehe und was mich über die Klippe gestossen und zu diesem Blog-Eintrag veranlasst hat: Microsoft liefert, so viel ich weiss, keine brauchbare Begründungen für all diese Wartereien und Verschiebungen, die man uns zumutet.

Wenn man schon die Leute monatelang hängenlässt, was in der heutigen Zeit eine kleine Ewigkeit bedeutet, gehört doch einfach dazu, den Leuten zu erklären, warum man das tut. Ohne Erklärung werden die Ängste nur um so grösser, und die Spekulationen umso wilder.

Ich bin Realist und weiss, wie klein die Chancen sind, dass nun genau dieser Blog-Eintrag etwas bewirkt, aber es musste mal gesagt sein.

Advertisements
Veröffentlicht in Allgemein. Schlagwörter: , . Leave a Comment »

Wie funktioniert ASP.NET-Inline-Code?

Seit den Anfangszeiten von ASP.NET vor vielen Jahren gibt es die Möglichkeit von Inline-Code, also die Möglichkeit, Code-Schnippsel in HTML einzustreuen. Hier ist ein kleines aktuelles Beispiel mit ASP.NET MVC 2, Teil einer Seite mit einer HTML-Tabelle, bei der die Zeilen mit Hilfe einer Schleife gebildet werden, die in C# programmiert ist:

<table>
    <% foreach (var item in Model) { %>
        <tr>
            <td>
                <%: Html.ActionLink("Edit", "Edit", new { id=item.Id }) %> |
                <%: Html.ActionLink("Delete", "Delete", new { id=item.Id })%>
            </td>
            <td>
                <%: item.Id %>
            </td>
            <td>
                <%: item.Title %>
            </td>
            <td>
                <%: String.Format("{0:g}", item.DateReleased) %>
            </td>
        </tr>
    <% } %>
</table>

Ich habe mich in der Vergangenheit schon öfters gefragt, wie genau ein solches buntes Gemisch von HTML und Code zur Ausführung kommt. Es wird ja wohl nicht so sein, dass irgendein Prozess den Text durchgeht und dabei jeweils fliegend zwischen einer Art „HTML-Modus“ und einer Art „Code-Modus“ wechselt, also quasi die Mischung nachvollzieht. Aber wie es geht es dann?

Am einfachsten sieht man, was läuft, wenn man auf irgendwelchen Code auf so einer Seite einen Breakpoint setzt und sich dann nach einem Break im Debugger genauer ansieht, wo man denn gelandet ist. Die Seiten einer Website mit Code werden durch dynamische Compilation in eine temporäre .NET-Assembly verwandelt, die typischerweise unter kryptischem Namen in einer kryptischen Directory abgelegt ist, bei mir z.B.

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\d0bb04eb\40bc3df1\App_Web_sm1qknju.dll

Pro Seite gibt es 1 Klasse, und in jeder Klasse ist eine Methode namens __RenderContent2() zuständig dafür, den Inhalt der Seite d.h. das reine HTML zu generieren. Dank dem IL-Disassembler ILDASM kann man sich auf einfache Weise die Details einer solchen Methode ansehen.

Die Lösung, wie genau die Mischung von Code und HTML realisiert wird, ist denkbar einfach und eigentlich wenig überraschend: Es wird alles zu Code. Was schon Code ist, bleibt natürlich Code, und alle verbleibenden Sequenzen von Zeichen vor, zwischen und nach Code-Stücken, die HTML darstellen, werden mit Hilfe von Aufrufen von System.Web.UI.HtmlTextWriter.Write ausgegeben.

Das sieht disassembliert dann z.B. so aus:

IL_0031: ldarg.1
IL_0032: ldstr „\r\n </td>\r\n“
IL_0037: callvirt instance void [mscorlib]System.IO.TextWriter::Write(string)

Nun zu wissen, „wie es geht“, bringt mir nicht unbedingt viel, aber immerhin habe ich jetzt kein schlechtes Gefühl mehr, wenn mir das ständige Abwechseln von kleinen HTML-Stücken und Code-Stücken zu dumm wird und ich dann Dinge schreibe wie:

<% Response.Write("<td>"+item.Id+"</td><td>"+item.Title+"</td><td>"+String.Format("{0:g}", item.DateReleased)+"</td>") %>

Schliesslich entspricht das mehr oder weniger dem, was technisch gesehen zur Ausführung kommt, wenn ich es als „Mischung“ hinschreibe. (Acht geben muss ich dabei allerdings darauf, dass ich den bei <%: automatisch inbegriffenen Aufruf von Server.HtmlEncode bei Bedarf selbst mache; siehe hierzu z.B. diesen Artikel.)

Veröffentlicht in Keine Kategorie. Schlagwörter: , , . Leave a Comment »

Schneller Directory-Zugriff via Netz in PowerShell

Wer schon etwas intensiver mit der PowerShell gearbeitet hat, kennt das Problem wahrscheinlich: Beim Zugriff auf Directory-Informationen via Netz d.h. bei Netzlaufwerken kann sie quälend langsam sein. Bei einem Befehl wie z.B. dir y:/texte/*power* kann es mehrere Sekunden dauern, bis das Auslisten der passenden Filenamen beginnt, und file name completion ist ebenfalls oft an der Schmerzgrenze, was die Ausführungszeit anbelangt, sobald Netzlaufwerke im Spiel sind.

Als ich neulich einen Server unter Windows Server 2008 R2 neu aufgesetzt habe, ist mir aufgefallen, dass sich dieses Problem dankenswerterweise in Luft aufgelöst hat. Ich habe mal recherchiert, was es damit auf sich hatte und wie es nun gelöst wurde:

Im Artikel Why is Get-ChildItem so Slow? sind die Gründe recht anschaulich erklärt. Einer davon hat mit der Objekt-Hierarchie des .NET Framework im Bereich der Klassen von System.IO zu tun: Gewisse Informationen, welche die PowerShell gar nicht benötigt, werden zeitaufwendig immer via Netz ermittelt, ohne dass die PowerShell etwas dagegen tun kann, weil das Ganze rein klassenintern abläuft. (Das ist eine Art von Problem, die wohl jedem vertraut ist, der schon mal so etwas wie ein „Framework“ gebaut hat.)

Entsprechend besteht die Lösung nicht in einer verbesserten Programmierung innerhalb der PowerShell, sondern in Erweiterungen im .NET Framework, welche für die Version 4 tatsächlich erfolgt sind, wie man hier nachlesen kann. Die konkreten neu in diesem Zusammenhang angebotenen Methoden beschreibt die MSDN Library im Artikel How to: Enumerate Directories and Files.

Etwas ist allerdings ein wenig seltsam: Gemäss der Information hier umfasst Windows Server 2008 R2 das .NET Framework in Version 3.5.1, nicht in Version 4. (Version 4 ist ja im Moment erst im Beta-Stadium.) Vielleicht hat da Microsoft der PowerShell zuliebe heimlich einer paar 4er-Verbesserungen reingemogelt…

Was ich bei meinen Abklärungen auch noch gefunden habe, ist dieser Blog-Eintrag von jemandem namens Tom Shelton, der mittels WIN32-API-Aufrufen und Extension Methods zur Selbsthilfe gegriffen hat und Directory-Zugriffe für Netzlaufwerke bereits heute im ganz normalen .NET Framework 3.5 mit guter Performance hinkriegt.

Veröffentlicht in Keine Kategorie. Schlagwörter: , . Leave a Comment »

Ein etwas nostalgischer Blick zurück

Als ich vor einiger Zeit ernsthaft mit Visual Studio und .NET/C# zu arbeiten begann, verglich ich diese Programmierumgebung ganz automatisch mit dem vor über 10 Jahren erschienenen VB6, mit dem ich vor allem durch eine privat damit gebaute Shareware sehr gut vertraut war.

Bei diesen beiden Systemen sind nur wenige Dinge exakt gleich, schon alleine wegen C# anstelle von BASIC als Sprache. Aber trotzdem hatte ich immer das Gefühl einer grossen Vertrautheit, den Eindruck einer weitgehenden Übereinstimmung bezüglich der grundlegenden Philosophie: Überall sah ich quasi den „Geist“ von VB6 durchschimmern.

Was mich aber noch viel mehr beeindruckte, und auch immer stärker, je genauer ich Visual Studio und .NET kennenlernte, war die folgende Geschichte: Im Gegensatz zum Nachfolger ist VB6 geradezu ein Winzling, weist aber trotz seiner bescheidenen Grösse (und trotz seines Alters) eine erstaunliche Menge der wichtigsten technologischen „Errungenschaften“ bereits auf.

Dinge wie Garbage Collection, IntelliSense im Editor, grafischer Form-Designer, hervorragendes Laufzeit-Debugging inklusive Watches und Immediate-Fenster, Code-Änderungen während das Programm läuft, mächtige String-Klasse, Kompilieren zu Native Code, Klassen inklusive Late Binding beim Aufruf von Objekt-Methoden, alles schon drin in diesem System von 1998, in einem Laufzeitsystem von nicht mal 3 MB und einer IDE von absolut lächerlichen 15 MB.

Natürlich könnte ich problemlos eine noch längere Liste von Eigenschaften aufzählen, die VB6 nicht hatte, ohne die man aber im Jahre 2009 zum Entwickeln von Software gar nicht anzutreten braucht.

Es geht mir um etwas Anderes: Der Vergleich VB6 versus Visual Studio 2010, C# und .NET 3.5 ist für mich mittlerweile eines der besten Beispiele, die ich persönlich kenne, um die 80%/20%-Regel zu illustrieren: Ja, das moderne System kann mehr als das gute alte VB6, aber man sehe sich mal an, wieviele der wirklich wichtigen, zentralen Eigenschaften VB6 bereits aufweist (die „80%“ in besagter Regel), erreicht mit vergleichsweise bescheidenem Aufwand (den „20%“). Oder umgekehrt: Ja, das moderne System ist überlegen, aber man sehe sich mal an, mit welch gigantischen Aufwand gewisse Verbesserungen erkauft werden mussten.

Natürlich kann ich als reiner Anwender von Visual Studio und .NET das Resultat geniessen, denn Microsoft trieb ja quasi für mich den grossen Aufwand, nicht ich. Und einen modernen Rechner bringen auch grosse IDEs und Laufzeitsysteme nicht ins Schwitzen.

Aber wenn ich selber etwas baue, tue ich gut daran, immer mal wieder an die 80%/20%-Regel zu denken und diese zu beherzigen. Mir persönlich fällt das nicht schwer, mit einem etwas nostalgischen Blick zurück zu VB6 dann und wann, zu dem ich z.B. Gelegenheit habe, wenn mein PC die Visual-Studio-IDE mit viel Festplatten-Aktivität in den Speicher wuchtet und diese riesige Maschine anwirft…

Veröffentlicht in Keine Kategorie. Schlagwörter: , , . 1 Comment »

Und wieder mal TechDays

Etwas über ein Jahr ist es her, seit ich mit einem Eintrag über die Microsoft TechDays 2008 diesen Blog eröffnen durfte. Letzte Woche war ich nun an den TechDays 2009, dieses Mal im Kursaal in Bern.

Es war eine gut besuchte, professionell durchgeführte und solide Veranstaltung. Wie schon letztes Jahr waren es für mich gut investierte 2 Tage, um zu erspüren, wo die Reise hingeht mit Microsoft und den Technologien dieser Firma.

Die für die Megos vielleicht wichtigste Information, die ich mitgenommen habe: WPF ist jetzt einsatzfähig. Dies wurde klar anhand der Preisverleihung für den .NET Swiss Innovation Award, wo eine WPF- und 2 Silverlight-Applikationen prämiert worden sind – alle 3 nicht-triviale, real existierende Applikationen, offenbar reif für den produktiven Einsatz. (Ein paar Details zum Award und den Gewinnern findet man in einem Infoweek-Artikle hier.) Auch der Stand von WPF plus entsprechender Tools ist mittlerweile um Längen besser als noch vor zwei Jahren oder so, wo Microsoft vorschlug, WPF-Applikationen ohne ein DataGrid-Control und ohne IntelliSense für XAML zu entwickeln…

Eine weitere interessante, in einem gut gemachten Vortrag präsentierte Sache sind die Parallel Extensions, mit deren Hilfe man für seine Programme unter .NET 4.0 auf relativ einfache Weise mehrere Cores bzw. Prozessoren wird nutzen können. Zunächst schien mir die Sache etwas überspitzt formuliert ein wenig paradox: Da baut man in der Form des .NET-Frameworks zuerst erst ein System, das mit seinem Pseudocode-basierten Ansatz, Garbage Collecting, aufwendigen Laufzeit-Informationen für Reflection usw. ziemlich gut geeignet ist, um Prozessorleistung abzufackeln, und dann geht man hin und baut eine Erweiterung, um das sogar noch mit mehr als einem Core gleichzeitig zu tun.

Aber es macht schon einen gewissen Sinn: Dank JIT-Compilierung und mächtigen Prozessoren spielt der .NET-Overhead mit der Zeit eine immer kleinere Rolle, aber wie man die laufend grösser werdende Zahl an Cores einfach und sinnvoll nutzen kann, wird wohl eine der grossen Fragen der Zukunft sein, und zwar eine, die sich als ziemlich harte Nuss erweisen dürfte.

Zudem sieht man, dass es auch klare Vorteile hat, sich mit dem .NET Framework auf einer relativ hohen Abstraktions-Ebene bewegen zu können: Microsoft hat es in der Hand, seine .NET-Sprachen geeignet um neue Sprachkonstrukte für paralleles Programmieren zu erweitern, und das .NET Framework ist ein geeignetes System, um möglichst viele der „schmutzigen“ Details vom Entwickler fernzuhalten und gewissermassen „hinter den Kulissen zu verstecken“.

Mehr zu diesem Thema find man auf der MSDN-Website hier.

Wie letztes Jahr besuchte ich mit grossem Genuss zwei Vorträge von Sascha P. Corti. Microsoft Schweiz soll gut Acht geben auf diesen Mann, den sollten sie unbedingt behalten.

Der für mich ganz persönlich absurdeste Moment dieser TechDays war, als stolz die Out of Browser genannte neue Fähigkeit der kommenden Version 3 von Silverlight präsentiert wurde: Damit ist es möglich, entsprechend vorbereitete Silverlight-3-Applikationen lokal zu installieren und dann komplett ausserhalb des Browsers laufen zu lassen. (Technische Details findet man z.B. hier).

Ohne Zweifel technisch gesehen eine beeindruckende Leistung, an der die Jungs und Mädels in Redmond wohl hart gearbeitet haben, um sie zu vollbringen. Aber warum fand ich das in gewisser Weise absurd? Lassen Sie es mich mit den Worten eines hypothetischen, fanatischen Web-2.0-Fans einmal so formulieren: „Wow! Ich dachte immer, man braucht einen Browser, um Applikationen laufen zu lassen. Jetzt geht das ja sogar ohne Browser!“. Ja, ja, wer hätte das gedacht, Applikationen, die lokal auf einem PC laufen.

Veröffentlicht in Keine Kategorie. Schlagwörter: , , . 1 Comment »

Die vielen Implementationen von .NET

Hat man sich erst mal mit Hilfe einer virtuellen Maschine im Prinzip von Betriebssystem und CPU-Architektur gelöst, wie das ja bei .NET und der CLR der Fall ist, ist man frei, diese virtuelle Maschine für ganz unterschiedliche Umgebungen zu implementieren. Und obwohl .NET noch ziemlich jung ist, kommen schon eine ganze Reihe von Implementationen zusammen. Ich habe mir für dieses Posting einmal einen aktuellen Überblick verschafft (allerdings ohne aufzuführen, welche Komponenten aus dem umfangreichen .NET-Technologie-„Baukasten“ denn genau wo zur Verfügung stehen):

Die allseits bekannte „Mutter“ aller .NET-Implementationen und dementsprechend relativ uninteressant für diese Auflistung ist diejenige von Microsoft selbst für die verschiedenen Windows-Varianten, die hier zu Hause ist.

Eine Spur interessanter ist das .NET Compact Framework, ebenfalls von Microsoft selbst, das auf PDAs und Smartphones mit Windows Mobile läuft. Interessant, wie viel vom „grossen“ Bruder es in die Kompakt-Variante schafft.

Es geht aber noch kleiner als Smartphones: Mit dem .NET Micro Framework versucht Microsoft, selbst Geräte mit stark limitiertem Speicher abzudecken, wie z.B. ihre experimentelle SPOT Armbanduhr zeigt.

Es ist mir nicht klar, ob die Shared Source Common Language Infrastructure, früher mit Rotor als Codename und in der Wikipedia hier beschrieben, eine zweite .NET-Implementation von Microsoft darstellt, oder nur eine neue Zusammenstellung einer einzigen Implementation, oder etwas dazwischen, aber interessant ist, dass frühe Versionen offenbar neben Windows auch auf FreeBSD und Mac OS X lauffähig waren.

Wer sich auch nur ein wenig dafür interessiert, wie die Welt ausserhalb von Microsoft aussieht, kennt sicher mittlerweile Mono, ein sehr erfolgreiches Projekt, welches es einem ermöglicht, seine .NET-Programme auch auf Linux und Mac OS X laufen zu lassen. Man kann offenbar, wie hier beschrieben, dank einem Hack Mono sogar verwenden, um Programme für das Compact Framework herzustellen, muss aber selbst aufpassen, nichts zu verwenden, was da nicht vorhanden ist.

Schon weniger bekannt dürfte sein, dass Mono im Bereich Open Source Konkurrenz hat in Form des DotGNU-Projekts. Ohne das Projekt im Detail zu kennen, bekam ich beim Studium der Website allerdings den Eindruck, dass hier im Moment um einiges kleinere Brötchen gebacken werden als bei Mono, und es scheint mit einem Motto GNU Freedom for the Net und Statements wie etwa Don’t get caught in a .Net auch stärker um ideologische Fragen zu gehen als bei der Konkurrenz.

Einen grossen Schub in Sachen Verbreitung könnte .NET erfahren, wenn es als Basistechnologie für Silverlight in der Version 2 den Weg in die Internet-Browser dieser Welt schafft. Microsoft will mit Silverlight 2 bereits selber eine Reihe von Plattformen abdecken, und das Mono-Pendant Moonlight will für eine nochmals grössere Reichweite sorgen. Wie erfolgreich die Sache wirklich wird, scheint mir im Moment noch etwas in den Sternen zu stehen, aber zumindest die Technologie sieht sehr solide aus.

Und jetzt wird es etwas exotisch: Die Firma Red Five Labs aus Südafrika hat, soweit erkennbar vollständig aus eigener Kraft, das .NET Compact Framework für Symbian/S60-basierte Smartphones implementiert. Wenn jetzt nur noch das Geld da wäre für eine ordentliche Werbekampagne, um dieses Produkt unter den Entwicklern auch bekannt zu machen… Und wie es damit weitergeht, wenn Silverlight 2 wie geplant ebenfalls auf S60 ankommt, ist eine offene Frage.

Wenn man mehr spielerisch veranlangt ist, kann man seine C#- und .NET-Kenntnisse auch dadurch erwerben, dass man mit Hilfe von XNA Spiele für die Xbox 360 programmiert. Sogar eine Unterstützung von Zune Players ist offenbar in der Pipeline.

Und zum Schluss noch dies: Unter dem Namen CrossNet hat offenbar jemand einen sehr speziellen CIL-Decompiler geschrieben, der Standard-C++-Code auswirft, den man dann fast überall kompilieren kann. Das ist für den eigenen Code ganz schön; das grosse und offenbar weitgehend ungelöste Problem scheint zu sein, wie man am „neuen Ort“ zu einer .NET Base Class Library, sprich zu einem „Framework“, kommt.

Veröffentlicht in Keine Kategorie. Schlagwörter: . 2 Comments »

Framework Studio

Als die Megos vor einiger Zeit vor der wichtigen Frage stand, womit sie in Zukunft ihre Software entwickeln will, haben wir uns ein Produkt der deutschen Firma Framework Systems näher angeschaut, das sich Framework Studio nennt.

Ich war überrascht, was ich da zu sehen bekam, denn dieses System hat eine sehr interessante Architektur. Es läuft für mich quasi unter dem Motto „Erstaunlich, was man mit .NET alles machen kann“.

Beim Framework Studio handelt es sich um ein Software-Entwicklungssystem. Es entstehen Web-Applikationen, die man mit Hilfe einer Java-basierten Client-Komponente und einer C#/.NET-basierten Server-Komponente ausführt, zwischen denen via SOAP kommuniziert wird. Applikationen entstehen einerseits durch stark Tool-unterstützes Spezifizieren von Forms, Datenbank-Strukturen und Verarbeitungs-Logik, und andererseits durch Programmieren spezieller Logik direkt in C#.

Wie ein ausführlicher Artikel (Teil 1, Teil 2) erläutert, erlauben die Architektur des Systems und die Struktur der damit geschaffenen Applikationen eine ziemlich weit gehende Anpassbarkeit von Standard-Software.

Die Firma Nissen & Velten Software GmbH hat offenbar eine ERP-Lösung namens NVinity mit Hilfe des Framework Studio realisiert.

Trotz aller Faszination über das, was Framework Systems hier geleistet hat, haben wir auf den Einsatz von Framework Studio verzichtet. Ein Hauptgrund war unsere Entscheidung, nicht oder zumindest nicht ausschliesslich auf Web-Applikationen zu setzen, wie das hier nötig gewesen wäre. Jemandem, der hierin kein Problem sieht, kann ich aber durchaus empfehlen, sich die kostenlose Probeversion des Produkts mal anzuschauen. Selbst wenn es am Schluss nicht zu einem tatsächlichen Einsatz reicht, kann man als Software-Architekt mindestens die eine oder andere Idee mitnehmen und in seine „konventionelle“ C#-Applikation einbauen.

Wenn dies nun etwas gar nach Werbung klingt: Nein, ist es nicht, aber ich kann eben meine Sympathie für eine Firma nicht verhehlen, die wie die Megos gegen Ende der 1980er-Jahre mit EMBASSY den Mut hat, Neues in einer Art zu versuchen, die man eher bei viel grösseren Firmen erwarten würde.

Etwas beunruhigend, dass offenbar NVinity immer noch die einzige vorzeigbare in Framework Studio realisierte Applikation ist. Da liegt noch viel Arbeit vor der Firma Framework Systems; Innovationen haben es eben oft schwer…

Veröffentlicht in 1. Schlagwörter: , . Leave a Comment »