Dies war der Titel des Vortrags von Lars Keller bei der .NET Usergroup Karlsruhe gestern Abend.

Nach der Geschichte und Architektur von VSTO bis zur aktuellen Version stellte Lars die Programmierung des Ribbon UIs vor und zeigte die Fähigkeiten von VSTO am Beispiel von Outlook 2007 auf.

Außerdem präsentierte Lars wichtige Neuerungen und Erleichterungen durch die vor kurzem erschienenen Power Tools im Zusammenspiel mit VSTO.

Nach dem Vortrag ergaben sich zunächst noch einige interessante Diskussionen zu VSTO, die dann auch andere Bereiche der .NET-Entwicklung erfassten und so fand bis ziemlich genau um Mitternacht noch ein reger und konstruktiver Erfahrungsaustausch zu Patterns, Best Practices sowie Coding- & Design Guidelines statt.

An dieser Stelle nochmal ein Dankeschön an Lars ;-)

Wer sich bisher aufgrund der Komplexität gegen die Verwendung von Regulären Ausdrücken gesperrt hat, sollte sich Josh Flanagan's Readable Fluent Regex Api bzw. was Roy Osherove mit LINQ to Regex daraus gemacht hat, angucken.

Damit lassen sich RegExen künftig wie folgt abbilden:

An sich bin ich seit vielen Jahren mit den Produkten von Microsoft und der Linie, die Microsoft "fährt", immer sehr zufrieden gewesen - insbesondere natürlich, was .NET angeht, da dies teil meiner täglichen Arbeit ist.

Bis .NET Framework 2.0 stand ich Neuerungen gegenüber auf dem Standpunkt: "vielleicht noch nicht ideal, aber wir sind auch noch nicht bei der obligatorischen Version 3.0 angelangt".

Inzwischen gibt es für mich allerdings etliche Punkte bei .NET und Microsofts Strategie, die mich ernsthaft stören.

Da diverse Unterhaltungen im Messenger meine Meinung größtenteils bestätigen, möchte ich die Punkte hier zur Diskussion stellen:

• YAHOO!: Ich würde für YAHOO! keinen Cent (nicht EURO und nicht $) ausgeben, YAHOO! ist über kurz oder lang gegen Google dem Tode geweiht, das wird auch ein Kauf durch Microsoft nicht ändern. Microsoft kauft mit YAHOO eine fremde (nicht im Sinne von unbekannt) Technologie ein, die integriert werden muss. Microsoft hat mit (ASP).NET jedoch selbst eine - wie ich jetzt einfach mal zu behaupten wage - bessere Infrastruktur im eigenen Haus.
  Es wäre imho wesentlich sinnvoller, wenn Microsoft nur einen Bruchteil der ca. 40 Mrd. US-$ einsetzen würde, um eine vergleichbare Plattform mit (ASP).NET in Eigenleistung zu etablieren. Dies wäre zudem eine wunderbare Referenz für die .NET-Technologie.
  
  
• Ich habe keinen Bezug zu den Live-Produkten, allenfalls nutze ich Live Maps, den Writer und den Messenger (letzterer wurde wohl nur von MSN nach Live umbenannt, um Live bekannter zu machen). Ich benutze aber auch keine Google-Tabellenkalkulation oder ähnliches, nicht nicht mal Google-Mail. Für die Synchronisation von Daten möchte ich eine stabile Server-Platform, die auf mein Kommando hört und schlimmstenfalls bei einem Provider meines Vertrauens steht. Ich möchte meine Daten auch sonst niemandem als FileShare bereitstellen, dafür habe ich entweder E-Mail (mit PGP, wenns vertraulich ist) oder einen passwort-geschützten Download-Bereich auf einer Website.
  
  
• Ich entwickle seit dem Sommer 2003 mit (ASP).NET - eigentlich bin ich viel zu spät umgestiegen - und komme von Classic ASP (seit 1998) und HTML (seit 1995). Im Sommer 2004 haben wir in Karlsruhe die .NET Community Conference (NCC) veranstaltet. Die Themen waren damals unter anderem:
  
  
  • Sichere Webseiten mit ASP.NET
  • 3-Schichten-Architektur
  • Einfacher Datenbank-Zugriff im Code
  • Wiederverwendbarkeit von Code
  • Enterprise Library, damals noch als Application Blocks bekannt
    
  Wenn ich mir heute, fast genau 4 Jahre und 2,5 .NET-Framework-Releases später die Fragen der User in den Community-Foren wie glengamoi.com angucke, stelle ich fest, dass sich an der Problematik fast nichts geändert hat oder sich die Fragestellungen nur minimal verschoben haben.
  
  Nachdem mich das Thema bereits häufiger beschäftigt hat, bin ich zu folgendem Resultat gelangt:
  
  Microsoft verpasst bei jedem neuen Release von .NET und insbesondere Visual Studio die Chance, die Leute zu sauberer Softwareentwicklung zu erziehen. Stattdessen wird ab der ersten, der Öffentlichkeit vorzeigbaren Demo wieder die übliche "Mit-5-Klicks-ist-Deine-Website-Live"-Prozedur abgespielt, es werden neue Listen-Controls gezeigt, neue Datenbindungsmöglichkeiten usw..
  
  Der begeisterte User/Entwickler geht nach genau diesem Schema vor, sobald er eine öffentliche Beta bekommen kann und baut seine Seite nach exakt den Demos, die er inzwischen überall findet. Doch binnen kürzester Zeit stößt er auf das eine oder andere Problem, das tiefergehendes Verständnis für (ASP).NET verlangt und er wendet sich vertrauensvoll an eine der zahlreichen Online-Communities zu .NET. Dort erlebt er nun über kurz oder lang ein eiskaltes Erwachen,  denn er erfährt, dass
  
  
  • seine Seite im Jahre 2008 nach wie vor offen ist für SQL-Injection,
  • er bei einer anderen Architektur keinen Spaghetti-Code hätte,
  • er das Logging nicht hätte selbst implementieren müssen, da es das bereits fertig gibt
  • usw.
  
  Natürlich stellt sich nun die Frage, wie es besser wäre.
  
  Imho sollte Microsoft davon abkommen, mit jedem Release noch mehr Features in irgendwelche Listen-Controls zu stecken und noch mehr Databinding-Varianten zu schaffen. Denn was benötigt jeder ASP.NET-Entwickler immer wieder? Sicher nicht irgendwelche Listen mit Edit-Funktionen, sondern individuell und standardkonform gestaltete Formulare, an die er im Idealfall seine eigenen Objekte binden kann - und davon bitte nicht nur eines, denn eine Auftragsübersicht hat viel mehr Objekte und ist natürlich wiederverwendbar.
  
  
  • Warum ist Microsoft erst jetzt im Ansatz dabei, ein MVC-Pattern für ASP.NET zu implementieren, obwohl dieses bereits mit ASP.NET 1.1 realisierbar war? Microsoft bot bereits damals den - zugegebenermaßen monströsen -  User Interface Process Application Block an, der in die richtige Richtung zeigte - wie viele andere Dinge, die das Patterns and Practices Team geschaffen hat.
  • Warum schafft es Microsoft nicht, einen Designer für wiederverwendbare Custom-Controls - idealerweise als Views für MVP oder MVC-Pattern - zu entwickeln, die als eigene DLLs weitergegeben werden können?
  • Wieso versagt LINQ to SQL bei disconnected Szenarien nach einer so langen Entwicklungszeit trotzdem?
  • Wieso fließen die Arbeiten des Patterns and Practices Teams nicht stärker in die neuen Visual Studio Versionen ein?
  • Wozu gibt es ein Architecture Journal und ein MSDN-Magazine, in dem die Themen auf dem richtigen Level behandelt werden, wenn Visual Studio out-of-the-box zulässt, so ziemlich alles verkehrt zu machen, was in den beiden Magazinen gepredigt wird?
  • Wozu entwickelt Microsoft Unity, einen IoC/DI-Container und veröffentlicht Best Practices, wenn ich das mit meinem Spaghetti-Code gar nicht brauche?
  • Wozu soll ich mich an Prism orientieren, wenn ich meine WPF-Applikation mit Inline-Code "tunen" kann?
  
  Diese Liste liese sich noch beliebig weiterführen, aber ich denke, man versteht, worum es mir geht.
  
  Ein Argument, das Microsoft sicher in den Raum wirft, ist die Lernkurve für Neueinsteiger und Umsteiger - doch sollten nicht gerade diese lernen, wie man es einfach und dennoch richtig machen kann?
  
  Microsoft hat mit dem Team Foundation Server und Visual Studio Team System ein geniales Produkt für die professionelle Software-Entwicklung im Programm, das sich sicher noch besser verkaufen würde, wenn die Leute ein besseres Verständnis hätten für die Gründe, die hinter der Entwicklung von TFS u. VSTS standen: ins letzter Instanz ist es eine bessere Qualität beim Endprodukt, das damit oder dadurch ausgeliefert wird.
  
  Warum investiert Microsoft nicht die - dank des an sich wirklich gelungenen Visual Studio 2008 - gewonnenen Zeitvorteile bei der Entwicklung gegenüber Ruby, Java oder Perl, um die Lösungen nicht nur schnell, sondern auch wirklich sauber zu implementieren - auch für einen Einsteiger.
  
  Dass der Bedarf nach professionellen Ansätzen stärker denn je ist, zeigt die Entstehung der ALT.NET-Bewegung (die Dank Stefan Lieser inzwischen auch in Deutschland vertreten ist (warum nur in Gottes Namen bei Google ;-)) weltweit sowie die fast immer gleichen Fragen in den Foren, User Group Meetings, Konferenzen wie ASP-Konferenz, prio oder BASTA und zuletzt auch am ATE-Stand beim Launch von Visual Studio 2008, SQL Server 2008 und Windows Server 2008. Auch in Fachpublikationen wie dotnetpro, dotnet-Magazin oder ASP.NET Professional werden derartige Themen von den Lesern aufgesagt wie ein Schluck Wasser in der Sahara - warum nutzt Microsoft diese Chance nicht?
  
  Imho sollte .NET, nachdem inzwischen sogar Teile des Quellcodes offenliegen, nicht nur von oben nach unten - d.h. ASP.NET-Team -> Scott Guthrie (sein Blog = Bibel für .NET-Neuerungen) -> ASP Insiders -> MVPs -> Trainer -> Anwender funktionieren, sondern es sollten auch tatsächlich Lösungsansätze aus der Praxis, sei es von Usern oder dem hauseigenen Patterns and Practices Team in (ASP).NET zurückfließen.
  
  Dies erfordert natürlich auch von seiten der .NET-Community einen kriti(scher)en und fundiert(er)en Umgang mit .NET, anstatt (wie bisher), alles von Microsoft-Gegebene als das Maß der Dinge bei der Entwicklung anzusehen oder ansehen zu müssen...

So liebe Leser, jetzt seid Ihr dran ;-)

Wie und wo seht Ihr Euch, .NET und die Probleme, die es zu lösen gilt?

Wenn man Team Build mit den Standard-Einstellungen für den Team Build Agent verwendet, kann einem folgende Fehlermeldung sehr schnell ereilen:

"C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(737,5,737,5): error : TF10128: The path C:\Documents and Settings\NetworkService\Local Settings\Temp\GenericsDataLayer\GenericsDataLayerBuild\Sources\Development\Version 0.3\Source\Libraries\Microsoft Enterprise Library 3.1\Microsoft.Practices.EnterpriseLibrary.Security.Cryptography.Configuration.Design.xml contains more than the allowed 259 characters. Type or select a shorter path."

In der Build-Übersicht sieht das ganze wie folgt aus:

Der Grund hierfür liegt, wie bereits eingangs erwähnt, in der Konfiguration des zugehörigen Build Agents, genauer in der Einstellung Working Directory:

Der Eintrag "$(Temp)" wird zur Build-Laufzeit umgewandelt in "C:\Documents and Settings\[BuildUserAccount]\Local Settings\Temp\".

Der Eintrag "$(BuildDefinitionPath)" wird zu "[ProjektName]\[BuildName]\Sources".

Danach wird schließlich noch der Pfad angehängt, der in der Build-Definition unter Workspace / Source Control Folder definiert ist (bzw. ab dort absteigend).

Allein der Eintrag "$(Temp)" ist - je nach Länge des BuildUserAccount-Namens zwischen 50 und 60 Zeichen lang.

Dies lässt sich leicht ändern, indem man Working Directory z.B. auf "C:\Build\" ändert:

Allein mit dieser Änderung kann man je nach Länge des BuildUserAccount-Namens schon fast 50 Zeichen einsparen.

Weiter optimieren lässt sich das ganze natürlich, indem einen kürzeren Build-Namen wählt oder z.B. in der Build Definition im Workspace den Source Control Folder gezielter auswählt und damit die Zahl auszucheckenden Unterverzeichnisse verringert.

Christian Binder hat in seinem Blog-Post "Wie inkrementiere ich meine Assembly Versionen automatisch mit TFS2008 ?" ausführlich beschrieben, wie man die Assembly-Versionen mit Team Build in Team Foundation Server 2008 automatisch erhöhen lassen kann.

Allerdings läuft man dann in ein Problem, wenn man Continuous Integration mit Team Build nutzt und jeden Checkin dazu verwendet, um einen Team Build zu triggern: Die erhöhte Assembly-Version wird wiederum eingecheckt, was dann wieder einen Team Build anstößt usw., d.h. der Build-Prozess endet nie mehr.

Glücklicherweise gibt es seit Team Foundation Server 2008 für die Checkin-Comments ein Keyword, das man verwenden kann, um zu vermeiden, dass der damit kommentierte Checkin einen Build triggert.

Das Keyword lautet "***NO_CI***".

Damit muss das AfterCompile-Target wie folgt geändert werden:

Wie man eine Build Definition für Continuous Integration mit Team Foundation Server 2008 einrichtet, ist hier sehr gut beschrieben

Continuous Integration with Visual Studio 2008 (“Orcas”) Team Foundation Server

Nicht beschrieben ist jedoch, wie man nach der Installation von Team Build mit z.B. NT AUTHORITY\NETWORK SERVICE als Service Account einen Team Build auch erfolgreichen queuen kann.

Verwendet man nämlich eben diese Standard-Einstellungen, erhält man immer folgende Fehlermeldungen:

TF215085: An error occurred while connecting to agent \[ProjectName]\[BuildAgentName]

TF209009: The account [BuildAgentAccount] is not authorized to communicate with Team Foundation Server [TeamFoundationServer]. Verify that the account is a member of the Build Services security group for the appropriate team project on the Team Foundation Server and that the account's password has not expired.

Die in der Fehlermeldung TF209009 Berechtigungen lassen sich über den Team Explorer in den "Group Membership"-Einstellungen des jeweiligen Projektes leicht ändern.

Allerdings bleibt die Fehlermeldung auch danach bestehen.

Der Grund hierfür ist, dass der User NT AUTHORITY\NETWORK SERVICE noch der Gruppe "Team Foundation Licensed Users" hinzugefügt werden muss.

Dies lässt sich über das Kommandozeilentool tfssecurity.exe in C:\Program Files\Microsoft Visual Studio 2008 Team Foundation Server\Tools erledigen:

Nach einem erneuten Aufruf von Queue New Build klappt dann auch der Buildvorgang (möglicherweise muss man vorher noch den Status des zugewiesenen Build Agents von "Unreachable" auf "Enabled" zurücksetzen).

IETester ist ein Tool, das die Rendering- und JavaScript-Engine von IE 5.5, 6.0, 7 und 8 Beta 1 in einer Windows-Oberfläche zusammenfasst und auf diesem Wege eine einfache Kontrolle der jeweiligen Renderingergebnisse ermöglicht:

via High Resolution Weblog.

Die vor kurzem veröffentlichte WCF Security Guidance wurde um die WCF 3.5 Security Guidelines erweitert, welche folgende Themen umfasst:

• Auditing and Logging
• Authentication
• Authorization
• Binding
• Configuration Management
• Exception Management
• Hosting
• Impersonation and Delegation
• Input/Data Validation
• Proxy Considerations
• Deployment considerations