coding.roecher.de

Ich bin Bahnfahrer. Pendler von Montabaur nach Frankfurt am Main. Täglich setzte ich mich morgens und abends in den ICE nach Frankfurt am Main bzw. Montabaur. Eigentlich eine angenehme Sache. Die Fahrtzeit kann man, Sitzplatz vorausgesetzt, sehr gut zum arbeiten nutzen. So sind in der Vergangenheit schon einige Präsentationen und Projekte entstanden. Sehr gerne nutze ich die Zeit auch um mich in neue Technologien oder Praktiken einzuarbeiten. Manchmal gibt es auch Ausfälle, doch die kann man mit einem Podcast oder Musik überbrücken. Für mich ist die Zugfahrt eine wertvolle Zeit die ich für meine Leidenschaft Softwareentwicklung nutze. Als Familienvater und Sportler ist meine restliche Freizeit bereits stark verplant.

Doch seit November 2009 funktioniert die Bahn nicht mehr. Züge fallen fast täglich aus, kommen nur mit einem Zugteil und sind entsprechend überfüllt. Morgens ist es besonders schlimm. Die Tage an denen die Bahn laut Fahrplan und Wagenstandsanzeiger verkehrt, lassen sich an einer Hand abzählen! Für mich ein katastrophaler Zustand. Zusätzlich zu meine Doings habe ich Ende 2009 mit einem OpenSource Projekt begonnen (http://ugssk.codeplex.com). Der Ideale Zeitpunkt um an diesem Projekt zu arbeiten ist meine tägliche Zugfahrt. Doch durch die ständigen Ausfälle und überfüllten Züge ist ein arbeiten an diesem Projekt fast nicht mehr möglich. Selbst Sitzplatzreservierungen und 1. Klasse Upgrades sind zur Zeit keine Garantie für einen Sitzplatz und somit der Möglichkeit seiner Arbeit oder Leidenschaft nachzukommen.

Ich kann also nur hoffen das die Bahn diese unsägliche Situation bald behoben haben wird und mich bei allen Projektbeteiligen für die Verzögerung nur entschuldigen.

Für die Visual Studio 2010 Version Beta 2 standen Entity Framework T4 Templates zur Erzeugung von POCO Klassen zur Verfügung. Nach der Installation von Visual Studio 2010 Release Candiate funktionieren diese aber nicht mehr. Beim erzeugen bzw. kompilieren erscheint die Fehlermeldung:

The type or namespace name ‘TemplateFileManager’ could not be found (are you missing a using directive or an assembly reference?)

Neue Templates zur Erstellung stehen, zumindest bis zum Veröffentlichungstermin dieses Blogeintrages, noch nicht zur Verfügung.

Grund für die Fehlermeldung ist eine Änderung im Include File “EF.Utility.CS.ttinclude”. Dieses ist im Template wie folgt angegeben:

<#@ include file="EF.Utility.CS.ttinclude"#>

Die temporäre Lösung, bis neue Templates zur Verfügung stehen, ist das alte Include File der Beta 2 Version zu benutzen. Die Include Files sind unter:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Microsoft\Entity Framework Tools\Templates\Includes

oder

C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Microsoft\Entity Framework Tools\Templates\Includes

abgelegt.

1. EF.Utility.CS.ttinclude Datei der Beta 2 Version besorgen.
   1. Steht die Datei nicht mehr zur Verfügung kann sie aus dem ISO Image der Beta 2 kopiert werden. Im Ordner WCU\EFTools\ die CAB Datei ADONETEntityFrameworkTools_enu.cab öffnen. Es handelt sich um die Datei “EntityDesignerTemplates_EFIncludeCS_x86.3643236F_FC70_11D3_A536_0090278A1BB8”. Diese Datei kopieren und umbenennen.
2. EF.Utility.CS.ttinclude Datei der Beta 2 Version umbenennen in z.B. EF.BETA2.Utility.CS.ttinclude
3. EF.BETA2.Utility.CS.ttinclude in das Include Verzeichnis kopieren
4. Im fehlerhaften T4 Template die Zeile <#@ include file="EF.Utility.CS.ttinclude"#> in <#@ include file="EF.BETA2.Utility.CS.ttinclude"#> ändern
5. Änderungen speichern

Nach diesen Änderungen konnte ich das Projekt wieder kompilieren und die POCO Klassen wurden wieder erstellt.

Mit dieser kleinen Hilfsmethode kann gezielt geprüfen werden wann eine Exception erwartet wird. Der Rückgabewert kann für weitere Untersuchungen genutzt werden.

Kaum hat man das Problem mit dem AppPool gelöst (ist bei mir übrigens nur bei der Installation über “Web Platform Installer” aufgetreten),  folgt auch schon der nächste Fehler beim starten der WCF Workflow Service Anwendung aus VS 2010. Der Grund sind die fehlenden Schema und Logik Objekte in der Persistence Database.

Das Problem lässt sich aber einfach beheben indem man die entsprechenden SQL Skripte ausführt. Die benötigten Skripte findet man unter: C:\Windows\Microsoft.NET\Framework\v4.0.21006\SQL\en

Es handelt sich um die Skripte:

1. SqlWorkflowInstanceStoreSchema.sql

2. SqlWorkflowInstanceStoreLogic.sql

Ich benutze für die Ausführung das Microsoft® SQL Server® 2008 Management Studio, das auch als Microsoft® SQL Server® 2008 Management Studio Express verfügbar ist. Alternative kann auch das Dienstprogramm osql verwendet werden. In meinem Beispiel würde die Syntax in etwas so aussehen:

osql -E -S .\sqlexpress -d ApplicationServerExtensions-i SqlWorkflowInstanceStoreSchema.sql

osql -E -S .\sqlexpress -d ApplicationServerExtensions-i SqlWorkflowInstanceStoreLogic.sql

Beim ersten Starten des WCF Workflow Services im Windows Server AppFabric kam es zu folgendem Fehler:

Cannot open database "ApplicationServerExtensions" requested by the login. The login failed. Login failed for user ‘IIS APPPOOL\DefaultAppPool’.

Lösen lässt sich das Problem in dem man die Identität der AppPools von ApplicationPoolIdentity auf LocalSystem ändert. Dafür muss man denn Internetinformationsdienst Manager starten. Unter Anwendungspools den richtigen Pool auswählen. Unter Erweiterte Einstellungen den Punkt Identität auf LocalSystem ändern.

Immer wieder benötige ich denn PublicKeyToken zur Angabe von Typinformationen und jedesmal suche ich erneut nach dem Befehl zum auslesen des PublicKeys. Hier jetzt als Reminder:

1. Visual Studio 2008 Command Prompt öffnen

2. sn.exe –Tp <AssemblyName>

Komfortabler wird das ganze natürlich wenn wir sn.exe als Externes Tool in Visual Studio einbinden.Unter Tools, External Tools öffnet sich folgender Dialog. Add auswählen und die Angaben tätigen wie sie im Screenshot abgebildet sind. Der Pfad zur sn.exe ist bei mir C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin.

Wenn die Angaben korrekt und vollständig getätigt wurden erscheint jetzt im Tools Menü der neue Eintrag.

Im Output Fenster wird die Ausgabe von sn.exe angezeigt.

Passend zum Juli Treffen der DNUG Koblenz der Beitrag von Steve Sanderson Writing Great Unit Tests: Best and Worst Practises.

Am 30. Juli fand das .NET User Group Treffen in Koblenz mit mir als Speaker statt. Thema war Mocking mit Rhino Mocks. Wir haben für die Demo Anwendung aus dem April Treffen neue Unit Tests mit Rhino Mocks geschrieben. Das Demoprojekt kann hier geladen werden:

CADemo.zip

Hier noch ein Hinweis zum Demoprojekt: Nach dem Download die Datei entpacken und im Ordner build die Datei buildDemo.cmd ausführen. Erst danach können die einzelnen Projekt ohne Fehler in Visual Studio geöffnet werden.

Die versprochenen Links zu Blogs und eBooks werde ich noch nachreichen.

hab mich soeben für den .NET Open Space vom 17. – 18.10.2009 in Leipzig angemeldet. Ich kann nur jedem empfehlen sich ebenfalls rasch anzumelden da die Plätze wie im letzten Jahr begrenzt sind.

Nach dem Erfolg im letzten Jahr ist wohl wieder mit einer hohen Anzahl von Teilnehmern aus der .NET Community zu rechnen. Die Teilnahme ist kostenlos. Erfahrungsaustausch ist das A und O und steht im Vordergrund. Die Sprache beim .NET Open Space 2009 ist Deutsch.

Themenfelder sind ALT.NET, Clean Code Developer, Mobile Computing, Soft Skills, User Interfaces / User Experience. Welche Inhalte in den einzelnen Themenfeldern und in welcher Form, z. B. als Vortrag oder in der Runde, bearbeitet werden, wird vor Ort bestimmt.

Wer mehr wissen möchte geht auf http://netopenspace.de/.

In stiller Trauer gedenken wir dem “System.Data.OracleClient”.

Wie ich dem ADO.NET Team Blog entnommen habe wird Microsoft den eigene Oracle Provider nicht mehr weiter entwickeln. Der OracleClient wird im .Net Framework 4.0 noch verfügbar sein, aber bereits als deprecated (abgekündigt, veraltet) markiert sein. Beim kompilieren werden somit entsprechende Warnings ausgegeben. Wann der Client vollständig aus dem Framework entfernt wird ist mir nicht bekannt.

Weitere Informationen findet ihr im ADO.NET Team Blog.

Ich persönlich habe immer sehr gerne mit dem System.Data.OracleClient gearbeitet und für mich gab es nie einen Grund auf einen 3rd Party Provider zu wechseln. Besonders das einfache Deployment und die Kompatibilität zu verschieden Oracle DB Versionen fand ich immer vorteilhaft.

Ich bedauere die Entscheidung kann sie aber auch nachvollziehen.

Deployment, Kompatibilität, Kosten, Unterstützung des Entity Frameworks sind mit Sicherheit die Faktoren die Einfluss auf die Entscheidung für oder gegen einen 3rd Party Provider bei mir nehmen werden.