LINQ ist doch tot, oder?

Die Language-Integrated Query bleibt in aller Munde – auch wenn LINQ-to-SQL schon wieder “auf dem Abstellgleis steht” (iX, Ausgabe 7 Juli 2009, S. 97) und nur noch wenige Neuerungen erhält. Für diejenigen, die auf LINQ-to-SQL gesetzt haben, nicht auf den EntitFramework-Zug springen können oder wollen und Persistence Ignorance kein Thema ist, könnte PLINQO interessant sein. Der Hersteller verspricht: “It's still LINQ to SQL, but better!”. PLINQO basiert auf CodeSmith Templates und bringt Features wie beispielsweise Entity Detach in die LINQ-to-SQL Welt, ermöglicht es u.a. Manager- und QueryExtensionklassen generieren zu lassen und unterstützt Many-to-Many Relationen. In den NightlyBuilds wurde diese Woche die Unterstützung für einen Caching-Mechanismus implementiert.

Für mich als Plain old CLR Objects (POCO) liebender LINQ-to-* Neuling sind wahrscheinlich Seiten wie 101 LINQ Samples oder diese MSDN Seite ein guter Einstieg, selbst wenn man mit dem spezifischen LINQ-to-SQL nicht in Berührung kommt.

Interessant finde ich in diesem Zusammenhang auch das, was Daniel Simmons (Dev Manager Entity Framework) über Persistence Ignorance (PI) zu sagen hat. Dass man PI seit der Visual Studio 2010 .Net 4.0 Beta 1 auch mit dem EntityFramework hinbekommen kann und schließlich DDD, POCOs und das EntityFramework unter einen Hut bekommen kann, wenn man dieses denn will.

Hass-Liebe Opera

Eigentlich wollte ich nur zwei Bilder meines kurzurlaubes auf ImageShack® hochladen und diese dann an Bekannte verschicken. Per click auf imageshack’s “email”-Schaltfläche sollte das auch eigentlich kein Problem sein, jedoch verwendet imageshack die “Socialweb” Schaltflächen von Gigya.com – und dort scheint man Opera nicht zu mögen, denn anstelle des @ wird lediglich ein Q in die Adresszeile übernommen. Mit IE, Safari und Firefox funktioniert es natürlich. Bleibt zu hoffen, dass Gigya.com auf meine Email reagiert und das Problem behebt. Andere können das ja schließlich auch (beispielsweise gibt es keine Probleme mit den Socialbuttons von AddThis).

Nunja, hochgeladen habe ich sie dann trotzdem:

Update (17.06.09): Imageshack.us hat auf meine Email geantwortet, Gigya hat’s gefixt. Schön. Ansonsten hätte man sich mit einem der anderen Imagehoster behelfen können.

DotnetKicks nun auch auf Deutsch und via Blogger

Vor langer Zeit habe ich mich auf der Seite DotNetKicks.com - .NET links, community driven. angemeldet und täglich werde ich über einen RSS Feed mit englischen Beiträgen zum Thema .Net versorgt. Zugegeben, nicht alles ist interessant oder lesenswert, aber dennoch stimmt meist die Qualität der gekickten Artikel.

Um so schöner ist es, das es nun eine deutschsprachige Community gibt. Leider habe ich erst jetzt davon erfahren: dotnet-kicks.de gibt es mittlerweile seit dem 13.03.2009 – zumindest ist das der erste Eintrag im DNKde’s eigenem Blog. Ich habe dieses zum Anlass genommen um mich dort anzumelden – leider braucht man auch bei DNKde einen Login – OpenId wird derzeit nicht unterstüzt (vielleicht baut man sowas einfach mal ein – sobald die Sicherheitslücken gestopft sind…). Was beiden Seiten bislang fehlt ist ein Link auf die jeweils lokalisierte Seite – andernfalls gelangen Besucher erst durch Zufall auf die lokalisierte Seite.

Damit relevante Posts automatisch den kick-it  Button bekommen habe ich meine Blogger Vorlagen erweitert. Hierzu genügt es im Bloggeraccount unter “layout”, “HTML bearbeiten” die Vorlage auszuwählen, den Haken bei ”Vorlagen zum Erweitern von Widgets” zu setzen und folgenden Code unter <p><data:post.body/></p> zu setzen:

<b:if cond="data:post.labels">
     <b:loop var="label" values="data:post.labels">
       <b:if cond="data:label.name == ".net"">
         <p><a expr:id="data:widget.instanceId + "_kickit"" expr:href=""http://dotnet-kicks.de/submit/?url=" + data:post.url + "&title=" + data:post.title"><img alt="Kick It on dotnet-kicks.de" border="0" expr:src="" dotnet-kicks.de http: kickitimagegenerator.ashx?url=" + data:post.url" services images /></a></p>
       </b:if>
     </b:loop>
   </b:if>

sodann werden alle Posts mit dem Label .net durch den DNKde Button verziert. Gut, dass es die Bloggerhilfe gibt und auch andere DotNetKicks in Blogger integrieren.

Meine Lieblings-Entwickler-Tools

Die MSDN-Blogparade ruft die “Softwarehersteller in Deutschland” dazu auf, an einem Gewinnspiel teilzunehmen und die Frage “Was sind Ihre Lieblings-Entwickler-Tools?” zu beantworten. Meine Antwort:

1. TestDriven.Net
2. .NET Reflector (RedGate, vormals Lutz Roeder)
3. GhostDoc (SubMain, vormals Roland Weigelt)

Nunja, selbst wenn ich nicht unter den Gewinnern sein sollte, so bin ich doch wenigstens auf interessante Helferlein gestossen. Zum Beispiel nennt dieser Teilnehmer Clone Detective für das Visual Studio.

Spring.Testing.NUnit, ConfigLocations und die App.config

Bei dem Versuch, Integrationstests unter Zuhilfenahme von Spring's Spring.Testing.NUnit  zu schreiben stand ich vor folgendem Problem:

Spring.Testing.NUnit wurde gegen eine ältere NUnit-Version kompiliert - daher war ein Assembly-redirect in der App.config nötig (unschön, denn nun hab ich eine App.config für eine dll):
   1: <runtime>
   2:      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
   3:        <dependentAssembly>
   4:          <assemblyIdentity name="nunit.framework"
   5:                        publicKeyToken="96d09a1eb7f44a77"
   6:                        culture="neutral"/>
   7:          <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="2.4.3.0"/>
   8:        </dependentAssembly>
   9:        <dependentAssembly>
  10:          <assemblyIdentity name="Common.Logging" publicKeyToken="af08829b84f0328e"/>
  11:          <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="2.0.0.0"/>
  12:        </dependentAssembly>
  13:      </assemblyBinding>
  14:    </runtime>

Am Rande: Wie die Zeilen 10 und 11 benutze ich für Spring die neue Common.Logging Version. Laut Dokumentation muss man nun lediglich die Integrationstestklasse von AbstractTransactionalDbProviderSpringContextTests ableiten und ConfigLocations angeben, die Spring dann zur Contextinstanziierung verwendet - und schon hat man zurückrollende Transaktionen am Ende eines jeden Tests. Meine ConfigLocations sahen zunächst so aus:
protected override string[] ConfigLocations
{
   get { return new string[]{ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None).FilePath };
}
}

Diese wurde dann mit einer Exception zur Laufzeit geahndet:

failed: Spring.Objects.Factory.ObjectDefinitionStoreException : Error registering object defined in 'file [IntegrationTests\bin\Release\IntegrationTests.dll.temp.config] at line 3' : There is no parser registered for namespace ''

Die ersten Zeilen der Konfiguration sehen so aus:
   1:  <?xml version="1.0" encoding="utf-8" ?>
   2:  <configuration>
   3:    <configSections>
   4:      <sectionGroup name="common">

Die übrigen Zeilen der Konfiguration beinhalten die üblichen Spring Sections: spring, parsers, context, objects. Nach langer Suche hatte ich's dann: die ConfigLocation sieht nun so aus:
   1: protected override string[] ConfigLocations
   2: {
   3:  get { return new string[]{ "config://spring/objects" };  }
   4:  }

So hat man schlussendlich beides mit nur einer Konfigurationsdatei: AssemblyRedirection durch die App.config und normale Spring-Configsections. Glücklicherweise sind die beiden Namespaceparser DatabaseNamespaceParser und TxNamespaceParser offenbar automatisch registriert, sodass es nicht weiter ins Gewicht fällt, dass die parsers-Section nicht ausgewertet wird. Für nicht registrierte Namespace Parser bleibt schließlich noch das programmatische Registrieren in der XmlParserRegistry.