Konsola zarządzania

Jakiś czas temu stwierdziłem, że w projektach jakie wykonuję brakuje mi takiego jednego centralnego czegoś... Konsoli w której szybko i bez problemu mógłbym wykonać przewidziane wcześniej zadania takie jak:

NHibernate 3 i QueryOver API

Całkiem niedawno pojawiła się nowa wersja NHibernate oznaczona numerem 3. Informacje co, gdzie i jak uległo zmianie można oczywiście znaleźć na głównej stronie projektu. Mi z tych wszystkich nowości najbardziej przypadło do gustu nowe API do wykonywania zapytań czyli QueryOver.

Fluent Validation i dziedziczenie

FluentValidation jest całkiem przyjemną biblioteką, która jak wskazuje nazwa dostarcza narzędzie do walidacji klas poprzez interfejs typu fluent. Co czyni ją bardzo prostą w użyciu (przykłady w dokumentacji). Poza standardowym przypadkiem tzn mamy klasę, mamy walidator i gotowe, wspiera również zagnieżdżenia klas oraz walidację kolekcji. Do pewnego czasu wydawało mi się, że więcej do szczęścia nie będzie mi potrzebne. Zawsze jest jednak jakieś ale... Biblioteka ze względu na sposób budowania walidatorów (dziedziczenie po klasie AbstractValidator<T>) nie wspiera dziedziczenia ich samych, co jednak czasem może się przydać.

Operacje asynchroniczne, czyli C# 5.0

Każda kolejna wersja platformy .NET wprowadza coraz "fajniejsze" ułatwienia dla programisty. I chyba trudno się z tym stwierdzeniem nie zgodzić. Zaczęło się od anonimowych delegatów. Później bardziej funkcyjne podejście i LINQ. W .NET 4.0 wprowadzono słowo kluczowe dynamic. Teraz przyszedł czas na lepsze wsparcie dla operacji asynchronicznych. Od wczoraj dostępny jest do pobrania Visual Studio Async CTP, który do C# i VB wprowadza dwa nowe słowa kluczowe await oraz async.

Debugowanie testów jednostkowych NUnit

Główną rolą testów jednostkowych jest wspomaganie wytwarzania oprogramowania poprzez testowanie element po elemencie (jednostce) całego rozwiązania. O ich zaletach nie trzeba się specjalnie rozwodzić ponieważ temat ten był i wciąż jest wałkowany na wielu blogach i serwisach tematycznych. Istotne jest, że po uruchomieniu testu wiemy co poszło nie tak, gdzie oraz jaki wynik powinniśmy otrzymać, a jaki otrzymaliśmy. W tym wszystkim zawsze brakowało mi jednak dokładnej wiedzy dlaczego coś poszło nie tak. Stąd możliwość debugowania testów jednostkowych wydaje się bardzo kusząca.

Problem PasswordBox przy wykorzystaniu wzorca MVVM

PasswordBox jak łatwo się domyślić jest standardową kontrolką WPF dzięki której użytkownik otrzymuje zamaskowane pole tekstowe do wpisywanie haseł itp. Kontrolka spisuje się wyśmienicie do czasu gdy przy budowaniu aplikacji nie wykorzystywany jest wzorzec MVVM (i inne pokrewne Model-View-* oparte o bindowaniu). Powód jest bardzo prosty. Ze względów bezpieczeństwa właściwość Password kontrolki nie jest uznawana jako Dependency Property co uniemożliwia bindowanie. Panowie z MS dokonali akurat takiego wyboru ponieważ wymusiłoby to ciągłe utrzymanie jawnego hasła w pamięci.

Problem zależności pomiędzy zewnątrznymi bibliotekami

Wykorzystując zewnętrzne biblioteki można bardzo łatwo wpaść w pułapkę niezgodności ich wersji. Dla przykładu nasza aplikacja wykorzystuje biblioteki A i B. Każda z nich do pracy potrzebuje biblioteki C. Ale A używa wersji 1.2, a B 1.5. Może to doprowadzić do następującego błędu kompilacji (i to w najlepszym przypadku):

Assembly 'B, Version=1.0.0.000, Culture=neutral, PublicKeyToken=17863af14b0044da' uses 'C, Version=1.5.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' which has a higher version than referenced assembly 'C, Version=1.2.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc'

Ostatnio sam spotkałem się z tym problemem wykorzystując w jednym projekcie możliwości AOP kontenera Autofac i NHibernate. Obydwie biblioteki były zależne od Castle.Core.dll. Zostawiając jedynie jej nowszą wersję kontener działał bez zarzutu, ale NHibernate przy próbie stworzenia proxy do encji rzucał pięknym wyjątkiem:

System.IO.FileLoadException : Could not load file or assembly 'Castle.Core, Version=1.1.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Najprostszym rozwiązaniem problemu okazało się zmuszenie NHibernate do wykorzystywanie nowszej wersji Castle.Core poprzez tzw Assembly Binding Redirection. Sprowadza się to do dodania paru linijek w pliku *.config

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Castle.Core" publicKeyToken="407DD0808D44FBDC" />
        <bindingRedirect oldVersion="0.0.0.0-1.2.0.0" newVersion="1.2.0.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Castle.DynamicProxy2" publicKeyToken="407DD0808D44FBDC" />
        <bindingRedirect oldVersion="0.0.0.0-2.2.0.0" newVersion="2.2.0.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Dzięki temu działa zarówno Autofac jak i NHibernate, a co najważniejsze nie trzeba nic rekompilować podmieniając zależności u źródła. Należy jednak pamiętać, że sztuczka nie zawsze musi działać. W przypadku braku zgodności między kolejnymi wersjami biblioteki mogą pojawić się inne ciekawsze błędy ;).
Warto również zauważyć, że ta metoda wykorzystywana jest w ASP MVC 2, gdzie w standardowym szablonie dla Web.config istnieje wpis:

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35"/>
      <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
    </dependentAssembly>  
  </assemblyBinding>
</runtime>