1. MVVM
2. Basic DataBinding
   1. INotifyPropertyChanged
   2. Basic DataBinding
   3. Binding class + full binding syntax
   4. Converters
   5. DataTemplate
3. Binding Collections
   1. INotifyCollectionChanged
   2. ObservableCollection + BindingList
   3. HierarchicalDataTemplate
4. Debugging DataBinding (thx to Dkowalsky)
5. Validation (thx to SKobalczyk)

Macie jakieś uwagi, życzenia albo sugestie?

PS: Spotkanie oczywiście darmowe, mile widziana wcześniejsza rejestracja na http://ms-groups.pl/pg.net/default.aspx
Inne podobne artykuły:

• Co się dzieje w poznańskiej grupie .NET ?
• 15. spotkanie PG.NET
• Microsoft Technology Summit 2008
• Grupy .NETowe w zeszłym tygodniu
• X spotkanie PG.NET już dzisiaj

Jeśli myślisz, że raz stworzysz schemat bazy danych dla swojej aplikacji i już nigdy go nie będziesz zmieniać to jesteś w błędzie. W czasie produkcji może się okazać, że coś zostało pominięte, coś można rozwiazać lepiej, jest błąd albo po prostu trzeba dodać nową funkcjonalność wymagającą zmian w schemacie.

Wprowadzanie takich zmian może być kłopotliwe, każda wprowadzona modyfikacja może powodować, że starsza wersja aplikacji nie będzie działać w oczekiwany sposób. Najlepszy rozwiązaniem jest wprowadzanie wersjonowania schematu bazy danych. W każdym pliku sa przyrostowe skrypty sql, tak żeby w dowolnym momencie można było, zaktualizować schemat z dowolnej historycznej wersji do najbardziej aktualnej albo stworzyć od początku.

Taki plik .sql może zawierać tworzenie nowych i  usuwanie istniejących tabel, kolumn, procedur czy cokolwiek innego co można wykonać w bazie.

Trzeba oczywiście również się zatroszczyć o to, aby zapisywać aktualną wersję, można to zrobić bardzo szybko poprzez extended property na bazie lub preferowane przeze mnie rozwiązanie, czyli osobna tabela z pełnymi informacjami kto i kiedy wykonał skrypt.

Takie podejście pozwala również zatroszczyć się o spójność bazy pomiędzy wieloma maszynami developerskimi.

W przypadku np NHibernate tworzenie plików można zautomatyzować za pomocą np.: SchemaUpdate. Tak ja jestem z tych paranoidalnych i nie lubie żeby na środowisku produkcyjnym SchemaUpdate z NHibernate grzebał w bazie.

Warto również w aplikacji zaszyć numer wersji schematu z którym współpracuje, ma to sens zarówno dla aplikacji desktopowych jak i webowych.

W naszych aplikacja z reguły korzystamy napisanego przez nas mechanizmu( nie cierpię na syndrom Not Invented Here;P ), ale okazuje się że jest coś gotowego z dużą ilością fajnych funkcjonalności: Roundhouse .

Smacznego!

UPDATE: na blogu Roba (autora RoundHouse są fajne tutoriale): http://ferventcoder.com/
Inne podobne artykuły:

• Dlaczego Entity Framework będzie rządzić światem
• Lokalizacja gotowej aplikacji ASP .NET MVC
• Windows Installer 4.5 i 5.0 – ciekawa funkcjonalność
• Zalety powtarzalności w tworzeniu oprogramowania
• Mono i CAB

Moją uwagę zwrócił kod Bootstrappera, który zawiera ciekawy trick, a mianowicie serializowanie obiektu Configuration do pliku:

private static void SaveConfigurationToFile(Configuration configuration)
{
    using(var file = File.Open(SerializedConfiguration, FileMode.Create))
    {
        var bf = new BinaryFormatter();
        bf.Serialize(file, configuration);
    }
}

A następnie zamiast wywoływać:

Configuration = new Configuration().Configure(ConfigFile);

Co odpowiada użyciu gołego NH, ale równie dobrze może to być Fluently.Configure z FluentNHibernate.

Ładowana jest konfiguracja z pliku:

private static Configuration LoadConfigurationFromFile()
{
            if (IsConfigurationFileValid == false)
                return null;
            try
            {
                using(var file = File.Open(SerializedConfiguration, FileMode.Open))
                {
                    var bf = new BinaryFormatter();
                    return bf.Deserialize(file) as Configuration;
                }
            }
            catch (Exception)
            {
                return null;
            }
}

Zysk czasowy jest bardzo duży – w przypadku sporej liczby mapowanych klas wywołanie Configure trwa nawet 5,5 sekundy, a deserializacja z pliku około 600 ms. Co ciekawe taki zserializowany obiekt Configuration zajmuje w moim przypadku 1,7MB na dysku.

Taki zapis jest wykonywany przy pierwszym starcie, więc oszczędza się dopiero przy następnych uruchomieniach. Zapisywanie obiektu na etapie deploymentu chyba nie byłoby dobrym pomysłem – z powodu różnic x86 i x64. Ma to też sens dla aplikacji desktopowych bardziej niż webowych.

Smacznego!

<TextBlock>
    <TextBlock.Text>
        <Binding Path="CurrentDate">
            <Binding.StringFormat><![CDATA[{0:dd MMMM yyyy}]]></Binding.StringFormat>
        </Binding>
    </TextBlock.Text>
</TextBlock>

W wyniku czegoś takiego można by się spodziewać, że pojawi się tekst “8 grudnia 2009”. Nic bardziej mylnego pojawiło się “8 December 2009”. Wynik całkiem zaskakujący ponieważ zarówno CurrentCulture jak i CurrentUICulture zawierały poprawne ustawienia dla pl-PL.

Okazuje się, że tak zachowuje się DataBinding w WPF-ie. Jedynym obejściem jest albo napisanie własnych implementacji IValueConverter, które zamiast przekazanego Culture używają CurrentUICulture, albo podanie przy wywołaniu convertera parametru ConverterCulture:

<TextBlock.Text>
    <Binding Path="CurrentDate" ConverterCulture="pl-PL">
        <Binding.StringFormat><![CDATA[{0:dd MMMM yyyy}]]></Binding.StringFormat>
    </Binding>
</TextBlock.Text>

Może ktoś zna bardziej globalen rozwiązanie tego problemu ? Tak żeby nie trzeba było określać ConverterCulture przy każdym Bindingu albo definiować własnego IValueConvertera…

Okazuje się, że wszystkie zainstalowane pakiety są przechowywane w C:\Windows\Installer:

Warto sobie zdawać sprawę z tego, że folder może zajmować dużo miejsca. Z tego co wyczytałem(sorry nie pamiętam gdzie) buforowane są tylko pliki .msi, więc jeśli mamy w takim pliku osadzone również całe archiwum  musimy okupić to zajętością dysku.

To czy nasz plik msi będzie zawierał również osadzone archiwum można kontrolować przy pomocy atrybutu EmbedCab w elemencie Media, standardowo stosujemy coś takiego:

<Media Id="1" Cabinet="media1.cab" EmbedCab="yes" />

Natomiast jeżeli chcemy uzyskać osobny plik( może być kłopotliwe do dostarczania użytkownikom) coś takiego:

<Media Id="1" Cabinet="media1.cab" EmbedCab="no" />

Wtedy plik media1.cab nie zostanie umieszczony w pamięci podręcznej windows installera, ale przy np naprawianiu instalacji będziemy musieli zapewnić nośnik/plik, z którego wykonywana była instalacja.
Inne podobne artykuły:

• Instalator w pliku msi część 2
• WiX: Merge modules
• Instalator w pliku msi część 1
• Instalator w pliku msi część 6 – upgrade
• Instalator w pliku msi część 3

Merge modules to plik z rozszerzniem .msm, który możemy dołączyć do naszego pliku .msi. Zaletą jest to, że na wyjściu dostajemy jeden plik Windows Installera, którego zawartość jest połączona(stąd nazwa merge module) z modułem.

Przykładowe użycie merge module w skrypcie wxs może wyglądać tak:

<Merge Id="CrystalReportsRedist" Language="1045" SourceFile="CrystalReportsRedist2005_x86.msm" DiskId="1" />

Czasem, są też problemy z nieistniejącymi tabelami w .msi, ale można to załawić przy pommocy EnsureTable:

<EnsureTable Id="Registry"/>

Sprawa wydaje się prosta. Jest jednak małe “ale” dołączanie zewnętrznego komponentu do naszego msi mocno komplikuje upgrady( patrz tutaj Rule 43). Dodatkowo wiążemy się z producentem pakietu .msm i musimy za każdym razem sami aktualizować plik msi o nowszy msm.

Producenci komponentów rzadko dostarczają merge moduły. Na przykład .NET Framework wogóle nie jest dostępny jako MSM. Nawet ludzie z Microsoft radzą raczej ostrożne stosowanie Merge modules.

W większości przypadków można zupełnie spokojnie użyć jakiegoś bootstrappera i instalować normalnie pliki .msi na przykład tak jak to opisałem w jednym z poprzednich wpisów.
Inne podobne artykuły:

• Instalator w pliku msi część 7 – generowanie listy plików do instalacji
• WIX – Wykrywanie zainstalowanych MSI
• Lokalizowanie setupów WiX
• Wix – wyświetlanie kopiowanych plików
• Instalator w pliku msi część 2

Przykład Firefox

Najlepszą aktualizację jaką do tej pory widziałem ma Firefox, jest tak zrobiona, że dla użytkownika( z domyślną konfiguracją) jest praktycznie przeźroczysta. Jedyne co zauważa to wyjeżdżające okno powiadomienia o nowej wersji, gdy już jest ściągnięta i gotowa do instalacji. Co ciekawe nowsza wersja ściąga się w taki sposób, że podczas przeglądania stron praktycznie tego nie widać. A sam Firefox aktualizuje się podczas następnego uruchomienia.

Jak to zrobić – jak w firefox

W windows jest ciekawy mechanizm, który pozwala zrealizować mało przeszkadzający użytkownikowi transfer plików nazywa się BITS – Background Intelligent Transfer Service. To właśnie tego mechanizmu używa Windows Update do pobierania aktualizacji. Z ciekawych rzeczy, które potrafi BITS to między innymi ponowienie zerwanego transferu od właściwego miejsca i wznowienie po restarcie. BITS potrafił używać Update Application Block, niestety został porzucony przez twórców, ale nadal można go znaleźć na codeplex ( trunk-updater).

A w Mini-Korpo

W korporacji potrzebna jest kontrola nad tym, która wersja aplikacji jest używana. Model stosowany w firefoxie nie sprawdzi się. Najłatwiej jest, gdy w firmie jest jakieś super-mega-hiper rozwiązanie do zarządzania stacjami klienckimi, ale mogą sobie na to pozwolić tylko duże przedsiębiorstwa.

Kolejnym rozwiązaniem mogłoby być zapakowanie produktu w msi(oczywiście przy pomocy WiX) i instalowanie z polityk grupowych. Jest to niepraktyczne  i wymagało by restartu maszyny klienckiej, żeby wykonała się aktualiazacja.

Tym co z reguły stosuje w takich wypadkach to zwykły ClickOnce. W korpo z reguły nie musimy się też pasmem, aktualizacje są ściągne lokalnie, więc nie trzeba sie bawić BITS. W ClickOnce można oprogramować sprawdzanie nowej wersji i np wymusić restart aplikacji. W ostateczności można polegać całkowicie na wbudowanym mechaniźmie aktualizowania przed uruchomieniem.

Miłym akcentem jest to, że ClickOnce może zainstalować także wymagane komponenyt np: .NET, Sql, czy co tam jeszcze jest potrzebne.

A co najlepsze to wszystko da się zrobić za darmo.

Badam też możliwość tworzenia pakietów instalacyjnych aplikacji .netowych ( w mono) na platformy linuxowe. Tutaj problem jest bardziej złożony – trzeba stworzyć pakiety linuxowe np .rpm albo .deb. Na szczęście serwer CI – Hudson, który mi się ostatnio spodobał pozwala na odpalenie nodów linuxowych
Inne podobne artykuły:

• MSBuild Community Tasks – wszystko czego brakuje w MSBuild
• Iron Python
• Zalety powtarzalności w tworzeniu oprogramowania
• Mono i CAB
• Wizardy w AERO

Agenda:

• Marek Błotny opowie o nowinkach w świecie .NET
• Michał Korsak o Hudson Continuous Integration Engine
• a na koniec ja opowiem o Windows Installer Xml

Rejestracja jest dostępna tutaj.

Inne podobne artykuły:

• 15. spotkanie PG.NET
• VII spotkanie poznańskiej grupy .NET
• Visual Studio 2008 InstallFest 25 lutego 2008 w Poznaniu
• Visual Studio 2008 InstallFest 25 lutego 2008 w Poznaniu
• Poznańska grupa .net – zmiana kierownictwa

Wybieram się na Bloggers Underground – spotkanie bloggerów technicznych organizowane w pierwszy dzień konferencji MTS, czyli 29 września o godzinie 19:00.

Chciałbym opowiedzieć o moich przemyśleniach po 4 latach blogowania:

• czytelnicy(jacy są i czego chcą)
• czy warto blogować technicznie,
• czy mikroblogi zabiły blogi techniczne?

Inne podobne artykuły:

• Hackfest
• XII spotkanie pg.net – prism + ironpython
• Poznańska grupa .net – zmiana kierownictwa
• Raymond Lewallen w Poznaniu
• Visual Studio 2008 InstallFest – podsumowanie

Praca przy organizowaniu spotkań była dla mnie fantastycznym przeżyciem i czas na to poświęcony mogę zaliczyć do skutecznie spożytkowanych. Miałem okazję poznać wielu fantastycznych ludzi i nauczyć się wielu nowych rzeczy. Od września będę się angażował w inne przedsięwzięcia, jednak nadal będę uczestniczył, w miarę możliwości, w spotkaniach i jeśli zostanę o to poproszony z chęcią wystąpię jako prelegent.

Oczywiście będę wspierał Michała i Daniela, jeśli zajdzie taka potrzeba i o to poproszą.

W tym miejscu chciałbym Wam podziękować za rok a wspaniałej współpracy w ramach grupy. Mam nadzieję, że oprócz spotkań będzie grupy okazja żeby się spotkać na gruncie towarzyskim lub przy okazji konferencji. No i oczywiście zachęcam do czytania mojego bloga.

Inne podobne artykuły:

• Second shot – przedłużony – zdajemy ?
• IX spotkanie poznańskiej grupy .net
• Co się dzieje w poznańskiej grupie .NET ?
• XX spotkanie PG.NET
• Wyniki ankiety PG.NET