Blog Maksymiliana Mulawy

Code review, lubię to!

2012-01-11T22:12:00.002+01:00

Czy na pewno code review to strata czasu?

Cóż może być nudniejsze i bardziej kosztowne niż przeglądanie cudzego kodu źródłowego? Chyba już tylko poprawnianie w nim błędów. Jeszcze kilka lat temu koncepcja przeglądania mojego kodu przez kolegów z zespołu była dla mnie totalną abstrakcją. Aczkolwiek, z czasem zrozumiałem, że w tym szaleństwie jest metoda. W kilku punktach chciałbym przedstawić benefity, które może wprowadzić Code Review do Twojego ekosystemu projektowego drogi Czytelniku.

Edukacja

Mam w zespole kolegę, które właśnie przez code review nauczył mnie na nowo pisać obiektowo. Było to trochę karkołomne, gdyż po pierwszym review dostałem ~30 komentarzy do kilku plików kodu, ale opłacało się. W ten sposób przekazał mi swoją wiedzę, cenne uwagi, które inaczej zatrzymałby dla siebie, a kod źródłowy pozostałby w ciężkim stanie. Edukacja w obrębie zespołu jest potrzebna, ale nie dokońca wiadomo jak bardziej "ogarnięci" programiści mogą dzielić się swoim doświadczeniem ze swoimi "młodszymi" kolegami (np. inną opcją jest programowanie w parach Junior-Senior). Code review stwarza takie możliwości, wspomniani Juniorzy to mogą być też nowe osoby w projekcie, które nie poznały jeszcze wszystkich meandrów kodu z którym pracują.

Standardy i jakość

Przy większych, a nawet kilku osobowych zespołach wymuszenie pewnych kowencji jest bardzo trudne, chyba, że wszystko zautomatyzujemy StyleCop'em i będziemy wymuszać pewne reguły na poziomie kompilacji. Nie zawsze to może być praktycznym rozwiązaniem, a review może być tutaj dobrym narzędziem do "nadzoru", ponieważ wtedy jest to idealny moment na "zwrócenie uwagi" swojemu koledze z zespołu, że w tym miejscu "dał ciała".

Inną sprawą, że dobry reviewer w pewnym sensie bierze częściową odpowiedzialność za jakość kodu źródłowego. Pomimo, że nie jest on autorem, podpisuje się imieniem i nazwiskiem, że kod, który widział jest "produkcyjny".

Często code review może odkryć więcej błędów, niż proces testowania. Jest to też ważny atut, który można w łatwy sposób przetłumaczyć na gotówkę.

Kanał komunikacyjny

W rozproszonych zespołach, np. nie pracujących razem w jednym pokoju, budynku, mieście, kraju komunikacja między-developerska jest znacząco utrudniona. Code review może być okazją, żeby przedyskutować pewne rozwiązania, ewentualnie zaproponawać bardziej eleganckie rozwiązanie danego problemu.

Narzędzia

Codre review możę być nieformalne i uwagi mogą być przesłane email'em, lub zapisane w systemie do rejestracji zmian lub bug'ów. Mi zdarzyło się używać Crucible'a, aczkolwiek nie jest on bezpłatny, ale warty swojej ceny, jest też trochę rozwiązań open-source, ale nie miałem z nimi żadnego doświadczenia.

Podsumowanie

Jeżeli masz w zespole spore zróżnicowanie umiejętności, problemy z wprowadzeniem pewnych konwencji, standardów to może na próbę trzeba dać szansę code review. Na koniec kilka wskazówek:

Code Review powinno być wykonane przez doświadczonego programistę, mogą być też rotacje dyżurujących reviewer'ów, lub można ustalić pary programistów, które sprawdzają sobie kod.
Code Review można wykonać po zakończonym zadaniu, lub po jakimś etapie zadania
Najlepiej jak jedna osoba przegląda modyfikacje wykonane przez tylko jedną osobę, żeby nie wprowadzić zamieszania (tutaj przydaje się system do zarządzania code review i zmianami w repozytorium kodu).
Każda zmiana, nawet drobna nadaje się do weryfikacji przez inną osobę, gdyż może to zapobiec potencjalnym błędom, które w przyszłości będą już trudniejsze i bardziej kosztowne do naprawienia.

Jestem ciekawy, czy code review jest już standardem na naszej polskiej ziemi, i jak ono funkcjonuje w Waszych zespołach.

Hope this helps.

SQL Tipsy (3) – deklaracja i inicjalizacja zmiennych w MS SQL Server 2008

2011-11-29T07:00:00.014+01:00

Można prościej

Pewnie większość programistów SQL Server'a już zapoznała się ze zmianami w sposobie deklarowania i inicjalizacji zmiennych w wersji MS SQL Server 2008. Aczkolwiek, dla tych którzy jeszcze o tym nie czytali przygotowałem krótkie demo (dzisiaj 289 sekund, więc trochę długo), w którym przepisuje kod napisany w stylu T-SQL'a z MSSQL 2000 na wersję 2008.

Kod przed modyfikacjami:

IF OBJECT_ID('dbo.temp','U') IS NOT NULL DROP TABLE dbo.temp
CREATE TABLE temp(id int)

IF OBJECT_ID('dbo.temp2','U') IS NOT NULL DROP TABLE dbo.temp2
CREATE TABLE temp2(id int)

DECLARE @i int 
      , @concatenated VARCHAR(100)
   , @myDate DATETIME
SET @i = 0
SET @concatenated = ''
SET @myDate = GETDATE()
WHILE (@i < 10)
BEGIN
 INSERT INTO temp(id)
 SELECT 1
 UNION
 SELECT 2

 INSERT INTO temp2(id)
 SELECT a.id
   FROM (
  SELECT 3 id
  UNION
  SELECT 4
  ) a
 SET @i = @i + 1
 SET @concatenated = @concatenated + CAST(@i AS VARCHAR)
 SET @myDate = @myDate + 1
END

SELECT (SELECT COUNT(*) FROM temp) AS TempCount
     , (SELECT COUNT(*) FROM temp2) AS Temp2Count
     , @concatenated AS Concatenated
     , @myDate AS MyDate

Kod po modyfikacjach:

IF EXISTS(SELECT * FROM sys.types WHERE name = 'temptables') DROP TYPE dbo.temptables
CREATE TYPE dbo.temptables AS TABLE ( Id int );
GO
DECLARE @temp AS dbo.temptables
     , @temp2 AS dbo.temptables;
DECLARE @i int = 0 
      , @concatenated VARCHAR(100) = ''
   , @myDate DATETIME = GETDATE();
WHILE (@i < 10)
BEGIN
 INSERT INTO @temp(id)
 VALUES (1), (2)

 INSERT INTO @temp2(id)
 SELECT a.id
   FROM (
  VALUES( 3 ) , (4)
  ) a (id)
 SET @i += 1
 SET @concatenated += CAST(@i AS VARCHAR)
 SET @myDate += 1
END

SELECT (SELECT COUNT(*) FROM @temp) AS TempCount
     , (SELECT COUNT(*) FROM @temp2) AS Temp2Count
     , @concatenated AS Concatenated
     , @myDate AS MyDate

Hope this helps.

Dwie instancje webpart'ów oraz IsClosed

2011-11-25T19:41:00.001+01:00

Tańcowały dwa webpart'y

Praca z webpart'ami od strony SharePoint API może być czasami frustrująca. Kilkukrotnie zdarzyło mi się exportować konfigurację, usuwać instancję, zmieniać właściwości webpartów. Przynajmniej trzy razy byłem zaskoczony tym, że strona wyświetla np. jednego webpart'a a kolekcja Webparts z obiektu SPLimitedWebPartManager zwraca więcej instancji, często tego samego typu.

Pewnie domyślacie się, że te dodatkowe instancje webpart'ów to zamknięte, a nie usunięte webparty'y. Rezydują sobie one szczęśliwe w kontentowej bazie danych, aczkolwiek nie są wyświetlane w UI.

Wszystko byłoby wporządku, gdybym już trzeci raz o tym nie zapomniał, że jeżeli modyfikuje widoczne webpart'y, to muszę wziąć pod uwagę też te niewidoczne instancje.

Moim zadaniem było usunięcie duplikatów webpartów, niestety z "jakiegoś" powodu zawsze usunwałem tylko widocznego webpart'a, a niewidoczny zostawał na stronie. Nie mogłem też zrozumieć skąd w kolekcji WebParts jest tyle elementów.

Podglądam webpart'a

W celu wizualizacji mojego problemu, utworzyłem nową witrynę przy użyciu szablonu 'Blank'. Wybrałem tryb edycji strony i dodałem dwa takie same webparty.

Poniżej widać sztuk dwie "Html Form WebPart".

Zamykamy drugą instancję webpart'a.

I wtedy jako użytkownik widzę tylko jednego webparta. I niestety ciągle zapominam, że webpart'y mogą żyć w najlepsze będąc zamknięte. Teraz krótko o tym, jak sobie uświadomiłem, że użytkownik może zamykać webpart'y, a ich instancje są dalej dostępne z poziomu API, no i oczywiście z poziomu edytora webpart'ów w UI (pojawia się wtedy nowa kategoria Closed Web Parts).

Odkrycie zamkniętego webpart'a

W końcu z braku pomysłów napisałem skrypt w Powershell'u który wyświetlił wszystkie instancje webpart'ów wraz z ich właściwościami.

#DumpWebpartContent.ps1
$site = Get-SPSite "http://webapp/sites/myteam"
$web = $site.RootWeb;
$wpManager = $web.GetLimitedWebPartManager("Default.aspx", [System.Web.UI.WebControls.WebParts.PersonalizationScope]::Shared)
foreach($webpart in $wpManager.Webparts)
{
 #this will dump webpart members content
 $webpart
}
$wpManager.Web.Dispose();
$wpManager.Dispose();

Zapisałem informacje zwrócone przez skypt i uruchomiłem WinMerge, żeby porównać dwie instancje webaprtów.

Okazało się, że jedną z właściwości, którymi się różnią sie jest IsClosed. Widoczne webparty mają ją ustawioną na FALSE, a te które są "zamknięte" przez użytkownika mają tą właściwość ustawioną na TRUE. Nagle mnie oświeciło, że ten dodatkowy webpart w kolekcji WebParts to właśnie zamknięte cudo.

Może zamiast uruchamiania tych skrytów Powershell'a powinienem pójść na kawę do kuchni, sam już nie wiem. Decyzja należy do czytelnika.

Hope this helps.

Automatyzacja SharePoint'a to konieczna konieczność

2011-11-24T19:57:00.001+01:00

Automatyzacja, automatyzacja, automatyzacja

Często zdarza mi się klikać jak przysłowiowa "małpa". Wielokrotnie powtarzać pewne akcje zamiast daną czynność zautomatyzować. Wynika to chyba z głupoty, ponieważ człowiek leniwy by to po prostu zrobił, żeby się nie narobić.

Kilka dni temu musiałem naprawić za pomocą skrytpu kilka witryn (chyba tak się tłumaczy site collection?), które na środowisku produkcyjnym przeszły jakieś niebezpieczne mutacje. Otrzymałem od zespołu wsparcia trzy backup'y wybranych witryn i zacząłem testowanie.

Przygotowałem pustą bazę kontentową
Dodałem ją do wybranej aplikacji webowej
Odtworzyłem skryptem backupy witryn do nowej bazy kontentowej
Zmieniłem administratorów witryn na lokalne konta
Uruchamiałem skrypt naprawiający bajzel na witrynach
i tak w kółko (przynajmniej z 5 iteracji).

Pózniej jeszcze z 3 iteracje na środowisku testowych i w sumie 8 iteracji powyższej listy daje klikania przynajmniej na godzinę.

Polak mądry po szkodzie

Po napisaniu "fix-bajzelskrypt.ps1" pozostał kac moralny. Takie ilości klikania pozostawiają uszczerbek na psychice. W ramach terapii w 15 MINUT napisałem skrypt, który to wszystko zrobi poprawnie i szybko za mnie.

$contentDabaseName = "WSS_Content_001"
$webApplicationUrl = "http://webapplication"
$siteCollectionBackupsDir = "c:\backup\sitecollections\"
$siteCollectionPrefix = "http://webapplication/sites/"
$primarySiteOwner = "Domain\User1"
$secondarySiteOwner = "Domain\User2"

Remove-SPContentDatabase $contentDabaseName
New-SPContentDatabase -Name $contentDabaseName -WebApplication $webApplicationUrl > $out-null
$backupFiles = dir $siteCollectionBackupsDir -Filter *.bak
foreach($backup in $backupFiles)
{
 $siteCollectionUrl = $siteCollectionPrefix + $backup.Name.Replace(".bak","");
 $siteCollectionBackupFile = $siteCollectionBackupsDir+$backup.Name
 Restore-SPSite -Identity $siteCollectionUrl -Path $siteCollectionBackupFile -force -confirm:$false -DatabaseName $contentDabaseName
 Set-SPSite –identity $siteCollectionUrl -Owner $primarySiteOwner –SecondaryOwner $secondarySiteOwner
}

Zanim napisałem ten skrypt wydawało mi się, że kilka kliknięć to chwila, a skrypt będę pisał godzinę. Nie doceniłem rozszerzeń PowerShell'a dla SharePoint'a.

Co mógłbym automatyzować, a czego czasami nie robię:

Operacje w Visual Studio (np. process attach)
Operacje kopiowania na plikach
Skrypty SQL i zmienne w skryptach
Operacje konfiguracji SharePoint'a
itd

Hope this helps.

SQL Tipsy (2) – skróty klawiaturowe w SSMS

2011-11-22T07:05:00.013+01:00

Produktywność i wygoda

W drugim odcinku SQL Tipsów opisuję jak można wykorzystać skróty klawiaturowe w SQL Server Management Studio. Zapraszam do oglądania Tipsa, tylko 163 sekundy, zwrot produktywności prawie gwarantowany.

Hope this helps.

SQL Tipsy (1) – zapytanie na wielu serwerach

2011-11-14T23:38:00.000+01:00

Debiut

Chciałbym zapoczątkować nową świecką tradycję na moim blogu. Pokusiłem się o nagranie 2 minutowego filmiku na którym prezentuje jak uruchamiać jedno zapytanie na wielu serwerach przy użyciu SQL Server Management Studio. Moim celem jest dzielenie się prostymi, aczkolwiek mam nadzieję, że przydatnymi "pomysłami" w jak najkrótszym czasie antenowym. Poniżej przykładowy filmik. Zachęcam do poświęcenia 140 sekund na obejżenie tego filmiku i oczywiście proszę o komentarze na temat takiej formy knowledge sharing.

Hope this helps.

SQL Server Profiler dla początkujących

2011-11-11T22:01:00.001+01:00

Czy mój system jest zdrowy?

Pewnego słonecznego poranka, z braku laku uruchomiłem SQL Server Profiler'a. Bez konkretnego celu, postanowiłem przejrzeć rodzaj i ilości zapytań SQL które są generowane podczas jednego wejścia na stronę pewnego systemu z którym pracowałem. Ku mojemu zakoczeniu, web'owa aplikacja okazała się bardzo skuteczna w produkcji dużej liczby zapytań do pobrania małej ilości danych. Trace w Profiler'rze wyglądał jak świąteczna lista życzeń.

We wspomnianym przypadku, jednym z powodów nadmiernej ilości zapytań, było nieumiejętne wykorzystanie mechanizmów NHibernate'a (w tym wypadku lazy load). Nie chodziło nawet o niezrozumienie działania użytych narzędzi, raczej była to kwestia braku monitorowania tworzonych dynamicznie zapytań. Oczywiste jest, że pisząc systemu oparte o silnik baz danych istotne jest aby unikanąć pisania "małpiego" kodu odczytywania i zapisywania danych. Z wielkim entuzjazmem środowisko .NET przyjeło jedynego słusznego OR Mapper'a, który odciążył "statystycznego" programistę formatek od klepania kolejnych linijek kodu w ADO.NET. Niestety, jak z każdą technologią nie można popadać w zbyt wielki optymizm i czasami należy zachować zimną krew. Wszystkim używającym NHib'a polecam przejrzenie listy problemów jakie mogą pojawić się przy pracy z jedynym słusznym OR Mapperem. Koniec dygresji na temat NHib'a, przechodzę do sedna sprawy, czyli monitorowania i analizy zapytań generowanych przez zewnętrzną aplikację.

Szukając winnego

Dla niewtajemniczonych, SQL Server Profiler jest to oprogramowanie, które pozwala przeglądać/filtrować/zapisywać zdarzenia lub zapytania wykonywane na danej instancji MS SQL Server'a. Jest to bardzo przydatne narzędzie, jeżeli pracujemy z SQL Server'em warto spędzić trochę czasu by poznać je lepiej.

W tym poście skupię się na funkcjonalności SQL Server Profiler'a związanej z filtrowaniem zapytań dla danej bazy, zapisywaniem tzw. trace'u w tabeli bazy danych i "analizie" ilościowej zapytań. Analiza powinna pomóc w znalezieniu potencialnych problemów ukrytych za setkami/tysiącami rekordów trace'u.

Przykładowy kod aplikacji konsolowej będzie odpytywał bazę danych AdwentureWorks dla MS SQL Server 2008 R2. W szczególności tabele Sales.Customer, Sales.SalesOrderHeader i Sales.SalesOrderDetail. Poniżej kod naszej testowej aplikacji. Na uwagę zasługuję atrybut Application Name w connection stringu. Implementacja jest dosyć kulawa, pobiera najpierw wszystkich klientów, później oddzielnie dla każdego klienta pobiera listę zamówień i listę pozycji dla danego zamówienia. Taki kod obrazuje jak można wygenerować dziesiątki zapytań, które równie dobrze można obsłużyć jednym lub dwoma zapytaniami.

using System;
using System.Data.SqlClient;

class Program
{
    static void Main(string[] args)
    {
        using (var conn = new SqlConnection(@"Server=HOME\SQL2008R2;
                    Database=AdventureWorks2008R2;
                    Application Name=MyTestConsoleApp;
                    MultipleActiveResultSets=true;
                    Trusted_Connection=true"))
        {
            conn.Open();
            using(var cmd = new SqlCommand(
                    @"SELECT TOP 10 cust.CustomerID, p.LastName 
                        FROM Sales.Customer cust
                        JOIN Person.Person p
                        ON cust.PersonID = p.BusinessEntityID
                    WHERE p.LastName LIKE 'A%'", conn))
            using (var customerReader = cmd.ExecuteReader())
            {
                while (customerReader.Read())
                {
                    Console.WriteLine(customerReader["LastName"]);

                    GetSalesOrders(conn, customerReader);
                }
            }
        }

    }

    private static void GetSalesOrders(SqlConnection conn, SqlDataReader customerReader)
    {
        using (var cmdSalesOrder = new SqlCommand(
            @"SELECT sod.SalesOrderID, sod.OrderDate, sod.CustomerID
                FROM Sales.SalesOrderHeader sod
                WHERE sod.CustomerID = @customerId", conn))
        {
            cmdSalesOrder.Parameters.AddWithValue("@customerId", customerReader["CustomerID"]);
            using (var sodReader = cmdSalesOrder.ExecuteReader())
            {
                while (sodReader.Read())
                {
                    Console.WriteLine(sodReader["OrderDate"]);
                    GetSalesOrderDetails(conn, sodReader);
                }
            }
        }
    }

    private static void GetSalesOrderDetails(SqlConnection conn, SqlDataReader sodReader)
    {
        using (var cmdSalesOD = new SqlCommand(
            @"SELECT SalesOrderID
                ,SalesOrderDetailID
                ,OrderQty
                ,ProductID
                ,LineTotal
            FROM Sales.SalesOrderDetail
            WHERE SalesOrderID = @SalesOrderID", conn))
        {
            cmdSalesOD.Parameters.AddWithValue("@SalesOrderID", sodReader["SalesOrderID"]);
            using (var deatailReader = cmdSalesOD.ExecuteReader())
            {
                while (deatailReader.Read())
                {
                    Console.WriteLine(deatailReader["ProductID"] + " " + deatailReader["LineTotal"]);


                }
            }
        }
    }
}

Filtry i kolumny

Uruchamiamy SQL Server Profiler i podłączamy się do instancji. Możemy podłączyć się zdalnie do instancji serwera jeżeli nasze konto ma uprawnienia ALTER TRACE. SQL Server Profiler możemy odpalić z SSMS lub przez Menu Start (aka Perłę od Windows Vista).

Jednym z bardziej istotnym aspektem korzystania z SQL Profiler jest ogracznienie zbioru danych jakie będziemy otrzymywać.Do przechowywania trace'u zakładamy bazę danych TraceStore na lokalnym serwerze.

CREATE DATABASE TraceStore;

Podłączam się do instancji MS SQL Server'a.Na zakładce General dla nowego trace'u konfiguruję opcje 'Save to table', wybieram rodzaj template'u i wpisuję nazwę sesji.

Przełączam się na zakłądkę 'Events Selection'. W pierwszym kroku wybieram kolumny, które zapełnią się danymi ze zdarzeń:

TextData - zapytanie
ApplicationName - nazwa aplikacji, można ja podać w connection string'u aplikacji (atrybut Application Name)
CPU - czas CPU w milisekundach wykorzystany przez dane zdarzenie
Reads - liczba odczytów stron danych przez zdarzenie
Writes - liczba zapisów stron danych przez zdarzenie
Duration - czas w microsekundach potrzebny na wykonanie zdarzenia
SPID - Server Process Identifier
EndTime - czas zakończenia wykonywania zdarzenia

Wybieram następujące zdarzenia:

RPC:Completed - procedura wywołana zdalnie zakończyła swoje działanie
SQL:BatchCompleted -batch zakończył swoje działanie

Na zakładce 'Events Selection' wybieram przycisk 'Column Filters'. Ustawiam filtr na nazwę aplikacji (Application Name), ponieważ tylko zdarzenia z mojej konsolowej aplikacji są w kręgu moich zainteresowań.

Filtrujemy po Application Name, jeżeli korzystamy z tej opcji w connection string'u. Może to być przydatne, jeżeli inne aplikacje korzystają z tej samej bazy danych, lub baza jest np. subskrybentem replikacji. Zapobiega to zaśmiecaniu trace'a zapytaniami, które mnie w tym momencie nie interesują.

Wybieramy 'Run' i zaczynamy śledzenie trace'a, który jest zapisywany również w tabeli TraceStore.dbo.AdwentureWorks_2011Nov10. Uruchamiamy testową aplikację DemoProfiler (kod podany powyżej) i czekamy na pojawienie się wpisów w tabeli. W oknie SQL Profiler'a wygląda to następująco.

Sprawdzam teraz jak przedstawiają się wyniki dla najbardziej popularnego zapytania w zgromadzonym trace'ie.

SELECT  SPID, SUBSTRING(CAST(TextData AS NVarchar(max)), 1, 150),COUNT(*) QueryCount
FROM TraceStore.dbo.AdwentureWorks_2011Nov10
 GROUP BY  SPID, SUBSTRING(CAST(TextData AS NVarchar(max)), 1, 150)
 ORDER BY SPID, QueryCount DESC

Powyższe zapytanie daje następujące rezultaty.

Widać, że zapytanie o listę pozycji w zamówieniu było najczęściej wykonywane. Nie zawsze musi oznaczać to problemy, ale warto sprawdzić kilka zapytań z górnej części listy.

exec sp_executesql N'SELECT SalesOrderID
                  ,SalesOrderDetailID
                  ,OrderQty
                  ,ProductID
                  ,LineTotal
                FROM Sales.SalesOrderDetail
                WHERE SalesOrderID = @SalesOrderID',N'@SalesOrderID int',@SalesOrderID

Jak to można stosować?

Zachęcam wszystkich do uruchomienia SQL Profiler'a na swoim systemie (oczywiście nie na produkcji, bo to obciąży znacząco i niepotrzebnie SQL Server'a). Może się okazać, że to co zobaczymy przerośnie nasze najśmielsze oczekiwania. W moim zespole używamy namiętnie NHibernate'a, kiedyś zaproponowałem, żeby używać SQL Profiler'a jako część code review, ale zostałem wyśmiany :). Zapewne byłaby to strata czasu, ale osobiście zawsze darzyłem sympatią SQL Profiler'a. Tylko ten program prawdę ci powie, nie jakaś tam cyganka.

Hope this helps.

Czy warto być przygotowanym na najgorsze?

2011-11-02T23:47:00.000+01:00

Dlaczego?

Dzisiejsze systemy to nie tylko kod źródłowy, to przede wszystkim niezawodność i dostępność. Programiści/projektanci odpowiadają w pewnej mierze za te atrybuty systemów, które implementują. Muszę przyznać, że zagadnienie planu ciągłości działania (dalej DR, ang. disaster recovery plan) było dla mnie czymś zupełnie nowym i abstrakcyjnym. Jakiś czas temu miałem okazję pracować z moim zespołem nad przygotowaniem planu DR. Chciałbym wytłumaczyć się co nas skłoniło do przygotowania i przetestowania takiej procedury i jakie korzyści odnieśliśmy z takiej inwestycji.

Do rozwiązania problemu biznesowego zaproponowaliśmy architekturę, która ze swej natury (używała replikacji MS SQL Server'a) była bardzo podatna na błąd użytkownika. Użytkownikiem mógłbyć niewyspany administrator, nadgorliwy programista czy zmęczony inżynier wsparcia. Najbardziej obawialiśmy się destabilizacji całego produkcyjnego systemu, którą można było osiągnąć np. poprzez usunięcie jednego wiersza w jednej z 10 baz danych. Jeżeli rozwiązanie oparte o mechanizm replikacji okazałoby się zbyt mało bullet-proof, to mogliśmy w pewnym sensie wydać na siebie wyrok skazujący.

Przygotowanie Disaster Recovery

Wydawałoby się, że administrator, ludzie od infrastruktury będą w całości odpowiedzialni za przygotowanie planu "gaszenia pożarów". Taki scenariusz nie zawsze ma racje bytu, spora część wiedzy o meandrach systemu jest w posiadaniu programistów. W naszym przypadku najwięcej pracy wykonaliśmy wspólnie z zespołem administratorów baz danych.

Na wstępie wyodrębniliśmy dwa scenariusze "katastrof", które w sumie pokryły większość kombinacji nieszczęśliwych wypadków. Wypisaliśmy też przykładowe kroki, które miały służyć do przywrócenia systemu do działania. Po zakończeniu testowania, z oryginalnej listy kroków, został tylko jej ogólny zarys. W zderzeniu z rzeczywistością teoretyzowanie nie miało szans. Dlatego plan DR bez testowania jest jak babcia bez wąsów.

Testowanie planu DR

W czasie testowania planu DR okazało się, że system wcale nie jest taki odporny na wszelkie możliwe kombinacje backup'ów, modyfikacji itd. Na bieżąco naprawialiśmy pojawiające się problemy i notowaliśmy co ważniejsze zmiany które należało zaimplementować.

Istotnym elementem był całkowity czas przywrócenia systemu. Mierzyliśmy czas wykonania dla każdego kroku. Skrupulatnie zapisywaliśmy czasy kopiowania backup'ów, wykonywania czynności administracyjnych itd.

Wymiana doświadczeń z administratorem bazy danych okazała się bardzo cennym doświadczeniem. Wzajemnie wymyślaliśmy scenariusze, które trzeba obsłużyć. Obecność osoby spoza zespołu zapobiegała "zamiataniu pod dywan" pojawiających się problemów i wymuszała szybkie ich rozwiązywanie.

Po przygotowaniu i przetestowaniu

posiadaliśmy solidne przekonanie, że nowa wersja systemu działa
mogliśmy spać spokojnie, gdyż wiedza o przywróceniu systemu do działania została spisana i przetestowana
naprawiliśmy kilka błędów
zastosowaliśmy kilka cennych modyfikacji, które przyczyniły się do większej stabilności systemu

Czy warto?

Decyzję czy warto przygotować przygotować plan ciągłości działania dla systemu, który rozwijacie lub utrzymujecie pozostawiam Wam drogim czytelnikom. W przypadku mojego zespołu miało to znaczący wpływ na komfort psychiczny przy wdrażaniu nowej wersji systemu opartego na MS SQL Server replikacji.

Któregoś dnia wróciłem z urlopu, podszedł do mnie szef i mówi, że w czasie weekend'u padł dysk na serwerze i coś tam z systemem IO poszło nie tak. System zastygł, aczkolwiek ze strony szefa pełen spokój. Wyciągnął z szuflady plan DR, spojrzał, który scenariusz pasuje do zainstniałej sytuacji i rozesłał dokumenty do ludzi z insrastruktury. Wszystko poszło jak po maśle :). Ta sytuacja, IHMO, była dla mnie namacalnym dowodem potwierdzającym sensowność spędzonego czasu nad planowanie ciągłości :).

Wymienię IF/EXISTS/SELECT/UPDATE/INSERT na MERGE

2011-10-22T21:34:00.001+02:00

Ignorancja to słabość

Ostatnio przeglądałem T-SQL kod w którym została użyta pewna siermiężna acz użyteczna konstrukcja (użyteczna w poprzednich wersjach SQL Server'a, tak od 2005 w dół). Zapytałem się autora kodu, czy przypadkiem nie używają MS SQL Server 2008, otrzymałem pozytywną odpowiedź "nawet w wersji R2". Kod który prezentuje ogólny zarys problemu znajduje się poniżej. Przykłądowa implementacja wstawia rekord do tabeli jeśli jeszcze on nie istnieje, w innym wypadku aktualizuje wartości wybranych kolumn przy pomocy UPDATE'u.

IF EXISTS(SELECT * FROM Table1 WHERE Id = @Id)
BEGIN
  INSERT INTO Table1(Id, Name) VALUES(@Id, @Name)
END
ELSE
BEGIN
  UPDATE Table1
     SET Name = @Name
   WHERE Id = @Id
END

Niestety i na szczęście każde triki, schematy ulegają w końcu przedawnieniu. I tak się stało z powyższym IF/EXISTS/SELECT/UPDATE/INSERT.

MERGE na ratunek

W MS SQL Server 2008 pojawiło słowo kluczowe MERGE. Nigdy nie miałem okazji używać MERGE produkcyjnie. Aczkolwiek warto śledzić jak się rozwija Transact-SQL, ponieważ nie znasz dnia ani godziny kiedy taka zdawkowa wiedza może zostać wykorzystana (np.warto wiedzieć, że w wersji MS SQL Server 2012 wprowadzono wsparcie dla "paginacji" ).

Wracając do tematu. Powyższe zapytanie (EXISTS .... UPDATE) można w prosty sposób przepisać przy użyciu MERGE.

IF OBJECT_ID('dbo.Table1','U') IS NOT NULL DROP TABLE dbo.Table1

CREATE TABLE dbo.Table1(
  Id Int NOT NULL PRIMARY KEY,
  MyName Varchar(10) NOT NULL
)

IF OBJECT_ID('dbo.SmartUpsert','P') IS NOT NULL DROP PROC dbo.SmartUpsert
GO
CREATE PROCEDURE dbo.SmartUpsert(
  @Id Int
, @MyName VARCHAR(10)
)
AS
BEGIN
    MERGE dbo.Table1 AS target
    USING (SELECT @Id, @MyName) AS source (Id, MyName)
    ON (target.Id = source.Id)
    WHEN MATCHED THEN 
        UPDATE SET MyName = source.MyName
 WHEN NOT MATCHED THEN 
     INSERT (Id, MyName)
     VALUES (source.Id, source.MyName)
OUTPUT deleted.MyName OldMyName, inserted.MyName as NewMyName ;   
END
GO
DECLARE @Id1 Int = 1
, @MyName1 VARCHAR(10) = 'Max'
, @Id2 Int = 2
, @MyName2 VARCHAR(10) = 'Joanna'

EXEC dbo.SmartUpsert @Id1, @MyName1
EXEC dbo.SmartUpsert @Id2, @MyName2
EXEC dbo.SmartUpsert @Id1, @MyName2

Wyniki zgodne z oczekiwaniami, tabele deleted i inserted zachowują się jak w triggerach DML.

Dla MERGE otrzymujemy następujący plan wykonania.

Panta rei, trzeba ciągle poszerzać swoje horyzonty.

Hope this helps.

Linked Server w SQL Server dla początkujących

2011-10-20T22:56:00.000+02:00

Linked Server jako dobry wujek

Linked Server w SQL Serwerze oferuje prosty mechanizm udostępnienia danych ze zdalnego serwera (MS SQL Server, Oracle, DB2, itd). Z mojego doświadczenia wyniki, że jest to jeden z bardziej nadużywanych komponentów MS SQL Server'a. Korzystanie z Linked Server'ów jest na tyle proste, że większość systemów opartych na silniku baz danych MSSQL używa ich do przesyłania danych pomiędzy systemami.

Łatwość używania Linked Server'ów spowodowała, że stały się one jakby "standardem" wykorzystywanym do "integracji" systemów. W przypadku jednorazowego przesłania pewnej ilości danych użycie Linked Server'a jest jak najbardziej zrozumiałe. Jednak tworzenie w ten sposób rozwiązania integrującego np. dwa kluczowe systemy w firmie jest dla mnie pewnym nieporozumieniem.

Często połączenie dwóch systemów zaczyna się jako niewinne udostępnienie jednego widoku, tak na próbę. Po jakims czasie zaczynamy zaciągać kolejne tabele, nawet wykonywać złożone zapytania z JOIN'ami pomiędzy widokami/tableami zdalnymi i lokalnymi. Apogeum takiej sytuacji jest udostępnianie procedur składowanych wywoływanych przez zewnętrzne systemy.

Primo, żeby działało czyli architektura gwoździa i młotka

Użycie Linked Server jest często drogą na skróty, zdarza się, że integracja z innymi systemami to ostatni etap projektu. Wtedy nie ma czasu na implementację zestawu pakietów SQL Server Integration Services(SSIS), czy zaprojektowanie usług do pobierania danych, już nie mówię o SOA (przede wszystkim dlatego, że się na tym nie znam:)).SSIS zapewnia duży worek kompnentów np. do kowersji typów z którą mogą pojawić się problemy jeżeli wyciągamy dane z np. Oracle'a. SSIS jest też bardziej elastyczny, pozwala skalować te rozwiązania, które z czasem mogą zrobić się bardzo skomplikowane.

Secundo, dane są przesyłane po sieci

Inny problemem jest to, że z jakiegoś magicznego powodu, programiści MSSQL'a zapominają o jednej ważnej kwestii. Podczas wykonywania zapytań na Linked Server dane muszą zostać przesłane przez sieć zanim dotrą do docelowej instancji MSSQL'a. Ostatnio widziałem rozwiązanie oparte na Linked Server'ach, które wywoływały zdalne zapytania z poziomu aplikacji klienta. Okazało się, że aplikacja pomimo, że była używana na razie tylko przez kilku użytkowników już przeżywała problemy wydajnościowe. Ciężko, też było zrozumieć architektom systemu, że przesyłanie 1 miliona wierszy pomiędzy serwerami dla każdego wywołania zapytania nie jest dobrym pomysłem.

Mechanizm Linked Server'a umożliwia wywoływanie zdalnych procedur (jeżeli źródło danych to instancja MSSQL'a). Nie znaczy to, że koniecznie trzeba go używać. Niech przestrogą jak to może być nadużywane będzie następująca historia. W pewnym systemie z którym pracowałem ten mechanizm został "użyty" w następujący sposób. Poniżej jak wyglądała implementacja z użyciem Linked Server'a i wywołań procedur na zdalnych serwerach.

Aplikacja intranetowa wywoływała procedurę ProcA na serwerze ServerA
Procedura ProcA na ServerA wywoływała procedurę ProcB na serwerze ServerB (via Linked Server)
Procedura ProcB na ServerB wywoływała procedurę ProcC na serwerze ServerC (via Linked Server)
Procedure ProcC na ServerzeC wywoływała (korzystając z Linked Servera wskazującego na lokalną instancje) wywoływała ProcC2 na ServerC

Rozwiązania to w pewnym momencie działało (chyba było to nawet kilka lat), aczkolwiek ilość danych i użytkowników w systemach A, B, C systematycznie rosła, i zaczęły pojawiać się timeout'y, blokowanie itd. Rozwizanie tego problemu, bez przepisania połowy systemu A i B, okazało się praktycznie niemożliwe, nawet hardware upgrade nie pomógł.

Przykład użycia

Chciałbym nie pozostać gołosłownym i zademonstrować dwa przykłady użycia Linked Server'a. Na dwóch serwerach HOME i HOME\SQL2008R2 mam po jednej instancji bazy danych AdventureWorks.W pierszym przykładzie prezentuję zapytanie skonstruowane z dwóch tabel znajdujących się na zdalnym serwerze HOME.

Tworzymy login linkedaccount na serwerze HOME (zdalny) i użytkownika dla bazy AdventureWorks z uprawnieniami do odczytu danych.

IF  EXISTS (SELECT * FROM sys.server_principals WHERE name = N'linkedaccount')
BEGIN
 DROP LOGIN [linkedaccount]
END
GO
CREATE LOGIN [linkedaccount] WITH PASSWORD=N'P@ssw0rd', DEFAULT_DATABASE=[AdventureWorks]
GO
USE [AdventureWorks]
GO
IF  EXISTS (SELECT * FROM sys.database_principals WHERE name = N'linkedaccount')
BEGIN
 DROP USER [linkedaccount]
END
GO
CREATE USER [linkedaccount] FOR LOGIN [linkedaccount] WITH DEFAULT_SCHEMA=[dbo]
GO
EXEC sp_addrolemember db_datareader, [linkedaccount]

Na serwerze HOME\SQL2008R2 tworzymy Linked Server o nazwie HOME i konfigurujemy login linkedaccount jako konto z dostępem do danych zdalnego serwera HOME.

IF  EXISTS (SELECT srv.name FROM sys.servers srv WHERE srv.server_id != 0 AND srv.name = N'.\WE2005')
BEGIN
 EXEC master.dbo.sp_dropserver @server=N'HOME', @droplogins='droplogins'
END
GO
EXEC master.dbo.sp_addlinkedserver @server = N'HOME', @srvproduct=N'SQL Server'
EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'HOME',@useself=N'False',@locallogin=NULL,@rmtuser=N'linkedaccount',@rmtpassword='P@ssw0rd'

Uruchamiamy pierwsze zapytanie na serwerze HOME\SQL2008R2.

use AdventureWorks;

SELECT empRemote.LoginID
     , empHistoryRemote.StartDate
     , empHistoryRemote.DepartmentID
  FROM HOME.AdventureWorks.HumanResources.Employee empRemote
  JOIN HOME.AdventureWorks.HumanResources.EmployeeDepartmentHistory empHistoryRemote
    ON empRemote.EmployeeID = empHistoryRemote.EmployeeID
 WHERE empHistoryRemote.StartDate < '1998-12-12'

Powyższe zapytanie do dwóch zdalnych tabel znajdujących się na serwerze HOME jest uruchamiane z poniższym planem wykonania. Widać na nim, że JOIN został wykonany na serwerze zdalnym i tylko 19 wierszy zostało zwróconych do serwera HOME\SQL2008R2.

Drugi przykład prezentuje plan zapytania przy użyciu trzech tabel "zdalnych" i jednej lokalnej znajdującej się na serwerze HOME\SQL2008R2. Po dodaniu do zapytania pierszego jednej tabeli zdalnej HumanResources.EmployeePayHistory i jednej lokalnej HumanResources.Employee otrzymujemy całkiem inny plan zapytania. Zdalne zapytanie (Remote Query na planie) jest wykonywane dwukrotnie, ponieważ SQL Server w ten sposób radzi sobie z optymalizacją (mniej lub bardziej udaną).

use AdventureWorks;

SELECT empRemote.LoginID
     , empHistoryRemote.StartDate
     , empHistoryRemote.DepartmentID
     , empPayRemote.Rate
     , empLocal.Gender
  FROM HOME.AdventureWorks.HumanResources.Employee empRemote
  JOIN HOME.AdventureWorks.HumanResources.EmployeePayHistory empPayRemote
    ON empRemote.EmployeeID = empPayRemote.EmployeeID 
  JOIN HumanResources.Employee empLocal
    ON empRemote.EmployeeID = empLocal.EmployeeID 
  JOIN HOME.AdventureWorks.HumanResources.EmployeeDepartmentHistory empHistoryRemote
    ON empLocal.EmployeeID = empHistoryRemote.EmployeeID
 WHERE empHistoryRemote.StartDate < '1998-12-12'

Nie doszukiwałbym się jakiejś szczególnej logiki w powyższym zapytaniu. Chodziło mi tylko o pokazanie jak plan zapytania z użyciem Linked Server może ulec zmianie. W pewnym momencie może się okazać, że pobieramy ze zdalnego serwera całą dużą tabelę, żeby tylko ją lokalnie odfiltrować.

Podsumowanie

Nie jestem w stanie udowodnić w tak krótkim poście, że rozwiązania na Linked Serverach są trudne do utrzymania i mogą doprowadzić do problemów wydajnościowych. Mogę tylko zachęcić do wnikliwej ewaluacji potencjalnych pomysłów, które używają mechanizmu Linked Server. Pewnie, jest on wygodny, prosty w użyciu i w administracji, aczkolwiek jak ze wszystkim trzeba zachować pewną dozę rozsądku.

Obudziłem się z ręką w piaskownicy SharePoint'a

2011-10-17T23:32:00.000+02:00

Kontakty trzeciego stopnia z Sandbox Solutions

Microsoft w SharePoint 2010 zaproponował nowy sposób wdrażania i uruchamiania komponentów SharePoint'a, który nazywa się Sandbox Solutions (z angielskiego Sandbox to piaskownica). Sandbox Solutions są to "normalne" pliki CAB z rozszerzeniem .wsp, tak jak stare dobre Farm Solutions. Zasadnicza różnica polega na tym, że Sandbox Solutions (SS) mogą być wdrażane na poziomie Site Collection i na poziomie farmy, a Farm Solutions mogą być wdrażane tylko na poziomie farmy SharePoint'a. Docelowo najbardziej pożądanym miejscem dla SS jest Site Collection.

SharePoint udostępnia oddzielne środowisko uruchomieniowe dla kodu z Sandbox Solutions w postaci oddzielnego procesu (Sandbox Worker Process). Całe środowisko jest tak skonstruowane, że udostępnia tylko część SharePoint API do którego ograniczono dostęp poprzez wprowadzenie Sandbox Proxy Worker Process. Sandbox Woker Process komunikuje się z Proxy w momencie gdy chce wywołać jakąś metodę lub klasę z Microsoft.SharePoint.dll. Ładny obrazek architektury SS można zobaczyć tutaj.

Taka architektura ma swoje następstwa. Ograniczono możliwość korzystania praktycznie ze wszystkich pozostały bibliotek SharePoint'a. Powód tego jest prostym, często wymagają one dostępu poza Site Collection np. do Web Application i jest to sprzeczne z architekturą Piaskownicy.

TypeLoadException

Wyobraźmy sobie WebPart, który jest częścią Sandbox Solution. Nie może on skorzystać w kodzie zarządzalnym z Shared Service Applications (np. Manage Metadata Service odpada). Co więcej nie może pobrać nawet kontektu klasy SPServiceContext, gdyż otrzyma wyjątek TypeLoadException. Trudno sobie to wyborazić, ale pozostaje korzystanie z podzbioru Microsoft.SharePoint.dll. Ograniczenia są ładnie opisane w poniższych artykułach, ale aż trudno w nie uwierzyć do momentu aktywacji solution i wyświetlenia np. webpart'a z błędem. Dla przykładu Microsoft.SharePoint.Taxonomy.dll nie jest oznaczony AllowPartiallyTrustedCallers atrybutem i nie można go załadować do Piaskownicy.

Microsoft.SharePoint.dll APIs That Are Available from Sandboxed Solutions
What Can Be Implemented in Sandboxed Solutions in SharePoint 2010
Available and Unavailable .NET Assemblies from Sandboxed Solutions
Available and Unavailable SharePoint Assemblies from Sandboxed Solutions
Restrictions on Sandboxed Solutions in SharePoint 2010

Innym scenariuszem gdzie znacząco odczujemy ograniczenia Piaskownicy jest logowanie w sensie zapisu trace'u. API Developer Dashboard'u, ULS (Unified Logging Service) są niedostępne, czyli w Piaskownicy zapomnij o tym co przeczytałeś o logowaniu. Pozstaje SharePoint Sandbox Logging, ale to rozwiązanie pozostawiam bez komentarza.

Obejścia, czyli drugie oblicze Piaskownicy

Pierwszą możliwością objeścia ograniczeń SS jest użycie Full-trust proxy. Polaga ono na implementacji klasy, która udostępnia bardzo prymitywny interfejs. Bazuje on na metodzie przyjmującej nazwę operacji oraz argument i zwracającej obiekt. Rejestracja proxy wymaga dostępu administracyjnego do farmy SharePoint'a, czyli odpada np. w większości planów SharePoint Online.

Innym sposobem jest korzystanie z Client Object Model, pod każdą możliwą postacią, czyli JavaScript, Silverlight, Managed code. W praktyce sprowadza się to do kodowanie w JavaScript'cie, użyciu jQuery i intensywnym reverse enginnering Web Service'ów SharePoint'a (polecam zapoznać się z projektem jQuery Library for SharePoint Web Services).

Microsoft tylnymi drzwiami wprowadził Visual Studio 2010 SharePoint Power Tools. Jest to bardzo ubogi zestaw narzędzi do walki z Sandbox Solutions, umożliwia on tworzenia np. Visual WebPart dla SS (nie wspominałem, że nie można nic dodawać do katalogu 14-hive zatem odpadają User Control i nie tylko). Z tym zestawem "toolsów" miałem pewną przygodę. Pisałem pierwszego w życiu WebPart'a, który miał być częścią Sandbox Solution. W momencie gdy chciałem zaimplementować jakąś funkcjonalność, to kończyło się pisaniem JavaScript'u, w pewnym momencie dostałem błąd przy kompilacji paktycznie pustego code behind.

Microsoft.VisualStudio.SharePoint.Commands.CommandParameter. The maximum string content length quota (8192) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader. )

I myślę sobie, kurka ... okazało się, że mój plik ascx przekroczył 8Kb tekstu i dostałem coś takiego.

Warnining, który powoduje błąd kompilacji. Po przerzuceniu kilku linijek JavaScript'u do odzielnego pliku wszystko wróciło do normy. Spodziewam się więcej tego typu przygód w przyszłości.

What's hot, what's not? I dlaczego Piaskownica może być hot?

Piaskownica została wymyślona na potrzeby Office 365 i żeby administratorom żyło się lepiej. SharePoint Online na chmurze daje spore możliwości zaistnienia na rynku produktów. W tym momencie jak ktoś ma pomysł, to można wykorzystać tą jeszcze "przez moment niszę" i wyprodukować jakieś cudo polskiej myśli inżynierskiej.

Poza tym Sandbox wymusza pisanie bezpiecznego oprogramowanie, dlatego, że RunWithElevatedPrivileges odeszło do lamusa. Cały czas działamy w kontekście użytkownika, czyli musimy pisać oprogramowanie działające z różnymi zestawami uprawnień, a nie tylko Elevate i do domu....

Pewnym problemem z adaptacją SharePoint'a Online może być to, że w aktualnej wersji SO Microsoft zapomniał napisać provider'a do PowerShell'a (a do Exchange'a napisał). Konsekwencją tego jest to, że wdrożenie pliku wsp na Site Collection będzie zautomatyzowane ręczną aktywacją :).

Ogólnie nie jest łatwo w Piaskownicy, ale w dzieciństwie też nie było łatwo. Zatem trzeba zakasać rękawy i do roboty.

Przygód kilka Pana NULL'a

2011-10-04T19:40:00.010+02:00

Znam się z NULL'em od lat

Oglądając materiały z Introduction to Databases, przypomniały mi się koszmary z dzieciństwa. Zdarzyło mi się wspierać jako programista bądź inżynier support'u kilka systemów używających MS SQL Server'a (każdy z nich był rozwijany przynajmniej 5 lat). Miały one kilka cech wspólnych , jedna z nich sprawiła mi sporo problemów przy rozwijaniu i utrzymywaniu tych systemów. Posiadały one dużo tabel w których definicje kolumn umożliwiały wstawianie wartości NULL. Poniższa definicja tabeli FooTable prezetuje ten sposób definiowania kolumn.

CREATE TABLE FooTable(
....
FooName VARCHAR(20) NULL
....
)

Ogólnie zachęcam do definiowania explicite czy dana kolumna w tabeli jest NULL czy NOT NULL, ale wracając do tematu. W tym poście chciałbym podsumować w kilku słowach konsekwencje jakie niesie ze sobą tworzenie dużej ilości kolumn z możliwością wstawienia NULL'a. Moim celem jest przekonanie szanownego czytelnika do prostej zasady, która brzmi następująco.

Jeżeli ktoś nie przystawia wam towarzyszu "pistoletu do głowy" to proszę nie definiujcie kolumn, które umożliwiają wstawianie wartości NULL. Używajcie wartości domyślnych, stałych wartości lub pustych ciągów znakowych.

NULL i operator NOT IN

Pewnego dnia po wdrożeniu nowej wersji systemu w raportach zaczęło "brakować" danych. Oskarżenia padły na programistów, którzy na pewno coś pozmieniali w kodzie. Po dogłębnym przeanalizowaniu problemu, okazało się, że przyczyną problemu było pojawienie się wartości NULL w klauzuli operatora NOT IN. Ta sytuacja nie miała nic wspólnego z nową wersją, po prostu dane z zewnętrzengo systemu zawierały te wartości NULL.

Zatem na czym polegał kwas? Załóżmy, że mamy dwie tabele FooTable i BooTable.

CREATE TABLE dbo.FooTable
(
 FooId Int NOT NULL,
 FooName Varchar(10) NULL
)

CREATE TABLE dbo.BooTable
(
 BooId Int NOT NULL,
 FooName Varchar(10) NOT NULL
)

Do tabeli FooTable wstawiamy wartość NULL do kolumny FooName.

INSERT INTO dbo.FooTable(FooId, FooName)
VALUES (1, 'Foo 1'), (2, NULL), (3, 'Foo 3')

INSERT INTO dbo.BooTable(BooId, FooName)
VALUES (10, 'Foo 1'), (11, 'Foo 2' ), (12, 'Foo 3')

Spróbujmy wyciągnąć te rekordy z BooTable, które wartość FooName nie ma odpowiednika w tabeli FooTable. Zakładam, że powinien pojawić się jeden wiersz(BooId=11, FooName='Foo 2'), niestety otrzymujemy pusty zestaw wyników.

SELECT b.*
  FROM BooTable b
  WHERE b.FooName NOT IN (SELECT FooName FROM FooTable)

Powodem takiego zachowania silnika baz danych jest NULL w zbiorze wynikowym zapytania 'SELECT FooName FROM FooTable' i wynik porównywania wartości do NULL'a. Operator NOT IN można przetłumaczyć na b.FooName <> FooName1 AND b.FooName <> FooName2 etc. Ponieważ warunek b.FooName <> NULL zawsze zwróci NULL, niezależnie od wartości w kolumnie FooName. Zatem klauzula WHERE w naszych przypadku dla każdego wiersza zwróci NULL. To wyjaśnia kwestię pustego zestawu danych.

NULL w klauzuli WHERE

Inny problemem który powstaje w wyniku definiowania 'NULLowalnych' kolumn, jest konieczność używania funkcji ISNULL oraz operatora IS NULL. Jeżeli chcielibyśmy naprawić powyższe zapytanie, bez zmiany schematu danych możemy to zrobić na dwa sposoby.

Przykład z użyciem operatora IS NOT NULL

SELECT b.*
  FROM BooTable b
  WHERE b.FooName NOT IN (SELECT FooName FROM FooTable WHERE FooName IS NOT NULL)

Przykład z użyciem funkcji ISNULL, która zwraca wartość drugiego argumetu (w tym przypadku '') jeżeli FooName będzie równa NULL.

SELECT b.*
  FROM BooTable b
  WHERE b.FooName NOT IN (SELECT ISNULL(FooName,'') FooName FROM FooTable)

Rozwiązania nie są równoważne, ponieważ w przykładzie z ISNULL do zbioru wynikowego podzapytania dołożymy wiersz z wartością ''. Aczkolwiek, daje nam obraz jak kod może się komplikować z powodu występowania wartości NULL.

NULL i JOIN dwa bratanki

Moim największym zarzutem wobec NULL'a jest to, że często wymusza stosowanie pokrętnych konstrukcji z użyciem ISNULL, IS NULL lub COALESCE. Powoduje to znaczące problemy z utrzymanie kodu. Przykładem może być ewolucja następującego zapytania.

Etap 1)

SELECT b.*
  FROM BooTable b
 INNER JOIN FooTable f
    ON b.FooName = f.FooName

Zapytanie zwraca następujący wynik:

Etap 2) Załużmy, że użytkownik zgłosi programiście, że barkuje mu rekordu (11, Foo 2) i wtedy po zmianie kodu mamy już taki twór.

SELECT b.*
  FROM BooTable b
 INNER JOIN FooTable f
    ON b.FooName = ISNULL(f.FooName,'Foo 2')

Powyższe zapytanie zwraca następujący wyniki:

I tam możemy bez końca, w powyższym zapytaniu mamy tylko dwie tabele. A jak to będzie wyglądało przy np. 7 tabelach i wielu kolumnach w warunku JOIN'a.

Mam nadzieję, że te kilka przykładów zachęci czytelnika do refleksji czy zawsze warto pójść na kompromis i zadeklarować Column1 VARCHAR(20) NULL, czy jednak lepiej być twardym, nie miętkim i wybrać NOT NULL.

Hope this helps.

Triumwirat czyli podatki, dynamic i tuple

2011-10-03T20:22:00.024+02:00

Progresywny podatek dochodowy w Izraelu

Zbliżają się wybory, zatem podatki to teraz gorący temat. Tak się złożyło, że Ayende Rahien na swoim blogu opublikował jedno z zadań rekrutacyjnych, które wykorzystywał do weryfikacji umiejętności potencjalnych kandydatów na programistę. Problem polegał na obliczeniu podatku dochodowego od danej kwoty, zakładając, że stawki podatku i progi podatkowe w Izraelu są następujące.

Progi podatkowe	Podatek
do kwoty 5,070 ILS	10%
od 5,071 do 8,660	14%
od 8,661 do 14,070	23%
od 14,071 do 21,240	30%
od 21,241 do 40,230	33%
powyżej 40,230	45%

Przykładowe odpowiedzi:

5,000 ILS –> 500
5,800 ILS –> 609.2
9,000 ILS –> 1087.8
15,000 ILS –> 2532.9
50,000 ILS –> 15,068.1

Tuple w akcji

Problem nie jest skomplikowany, ale można użyć go do wypróbowania nowych mechanizmów, klas dostępnych w .NET Framework 4. Pierwsze rozwiązanie używa klasy Tuple, która umożliwia definiowania krotek z wieloma uporządkowanymi atrybutami. Wykorzystanie Tuple umożliwia proste zdefiniowanie progów podatkowych i procentu podatku.

public class TaxCalculator
{
    readonly List<Tuple<decimal, decimal, decimal>> taxRanges = new List<Tuple<decimal, decimal, decimal>>
        {
            new Tuple<decimal, decimal, decimal>(0m, 5070m, .10m),
            new Tuple<decimal, decimal, decimal>(5070m, 8660m, .14m),
            new Tuple<decimal, decimal, decimal>(8660m, 14070m, .23m),
            new Tuple<decimal, decimal, decimal>(14070m, 21240m, .30m),
            new Tuple<decimal, decimal, decimal>(21240m, 40230m, 0.33m),
            new Tuple<decimal, decimal, decimal>(40230m, decimal.MaxValue, .45m)
        };

    public decimal CalculateTax(decimal salary)
    {
        return taxRanges.Sum(tr=>CalculateTaxValuePerRange(salary, tr.Item1, tr.Item2, tr.Item3));
    }

    private decimal CalculateTaxValuePerRange(decimal salary, decimal bottomLimit, decimal upperLimit, decimal taxRate)
    {
        decimal calculatedTax = 0m;
        if(salary - upperLimit >= 0)
        {
            calculatedTax = (upperLimit - bottomLimit)*taxRate;
        }
        else if (salary - bottomLimit >= 0)
        {
            calculatedTax = (salary - bottomLimit)*taxRate;
        }

        return calculatedTax;
    }
}

Wersja z wzorcami i dynamic

Załóżmy, że przy obliczaniu podatku chcielibyśmy mieć możliwość wykorzystania typu decimal, double, lub własnego typu obliczeniowego. Możemy do tego wykorzystać wzorce, aczkolwiek nie umozliwiają one wykorzystywania operatorów artymetycznych. Do obejścia tego ograniczenia można wykorzystać typ dynamic (jest to alias typu Object), który umożliwia dzięki wsparciu kompilatora wywoływanie metod, operacji które będą dostępne dopiero w czasie wykonywania kodu (late binding).

public class TaxRange<T>
{
    public TaxRange(T bottomLimit, T upperLimit, T taxRate)
    {
        BottomLimit = bottomLimit;
        UpperLimit = upperLimit;
        TaxRate = taxRate;
    }

    public T BottomLimit { get; set; }

    public T UpperLimit { get; set; }

    public T TaxRate { get; set; }
}

public class TaxCalculator2<T>
{
    private readonly List<TaxRange<T>> _taxRanges;

    public TaxCalculator2(List<TaxRange<T>> taxRanges)
    {
        _taxRanges = taxRanges;
    }

    public T CalculateTax(T salary)
    {
        dynamic totalTaxAmount = 0;
        foreach (TaxRange<T> tr in _taxRanges)
        {
            totalTaxAmount += CalculateTaxValuePerRange(salary, tr);
        }
        return totalTaxAmount;
    }

    private T CalculateTaxValuePerRange(T salary, TaxRange<T> taxRange)
    {
        dynamic calculatedTax = 0;
        if ((dynamic)salary - taxRange.UpperLimit >= 0)
        {
            calculatedTax = ((dynamic)taxRange.UpperLimit - taxRange.BottomLimit) * taxRange.TaxRate;
        }
        else if ((dynamic)salary - taxRange.BottomLimit >= 0)
        {
            calculatedTax = ((dynamic)salary - taxRange.BottomLimit) * taxRange.TaxRate;
        }

        return calculatedTax;
    }
}

var taxRanges2 = new List<TaxRange<double>>
                                        {
    new TaxRange<double>(0, 5070, .10),
    new TaxRange<double>(5070, 8660, .14),
    new TaxRange<double>(8660, 14070, .23),
    new TaxRange<double>(14070, 21240, .30),
    new TaxRange<double>(21240, 40230, 0.33),
    new TaxRange<double>(40230, double.MaxValue, .45)
};

var taxCalculator2 = new TaxCalculator2<double>(taxRanges2);
Console.WriteLine(taxCalculator2.CalculateTax(50000));

Na koniec deserek, czyli podatek dochodowych w Polsce

W pewnym uproszczeniu (mamy ulgi, kwotę wolną od podatku, ZUS, składkę rentową, składkę zdrowotną) skala naszego podatku dochodowego wygląda następująco :

Progi podatkowe	Podatek
do kwoty 85 528zł	18%
powyżej 85 528zł	32%

50,000 ILS (Izraelskich Szekli) jest to równowartość 44,022 PLN na dzień 03 października 2011 roku. Definicja progów podatkowych w Polsce wygląda następująco.

var polishTaxRanges = new List<TaxRange<double>>
{
    new TaxRange<double>(0, 85528, .18),
    new TaxRange<double>(85528, double.MaxValue, .32)
};

Podsumowując, z moich obliczeń wynika, że dla kwoty 44200 PLN w Polsce płacimy niższy podatek dochodowy niż ludzie mieszkający w Izraelu. Niestety nie świadczy to o tym, że płacimy niskie podatki.

var taxCalculator = new TaxCalculator();
var taxCalculator2 = new TaxCalculator2<double>(taxRanges2);
var taxCalculator3 = new TaxCalculator2<double>(polishTaxRanges);

Console.WriteLine("Tax for Izraeli salary 50,000 ILS is {0} PLN", taxCalculator.CalculateTax(50000) * .88m);
Console.WriteLine("Tax for Izraeli salary 50,000 ILS is {0} PLN", taxCalculator2.CalculateTax(50000) * 0.88);
Console.WriteLine("Tax for Polish salary 44,200 PLN is {0} PLN",taxCalculator3.CalculateTax(44200));

Hope this helps.

Blokowanie w SQL Server dla początkujących

2011-09-27T20:17:00.006+02:00

Jak ujarzmić MS SQL Server?

Silnik baz danych MS SQL Server to takie niewdzięczne stworzenie w świecie .NET Framework. Relacyjne bazy danych są często w pogardzie u części programistów, postrzegane jako zło konieczne. Niektórzy tworzą NoSQL movement, inni proponują, żeby przenieść bazę danych do pamięci operacyjnej lub chociaż do chumry, usunąć relacje i wcisnąć ten cały data management w obiekty. Oczywiście, na dzisiaj (rok 2011, miesiąc Wrzesień) wielu nieszczęśliwych z tego powodu developerów musi zmagać się z SQL Server'em. Właśnie o pewnym aspekcie tych wysiłków chciałem pokrótce napisać.
Wyróżniłbym kilka klas problemów z którymi zmagają się na codzień programiści baz danych

Indeksowanie tabel i widoków
Blokowanie
Analiza dużej ilości zapytań (tzw. trace)
Porównywanie danych
Analiza wydajności zapytań
Śledzenie i rejestrowanie zapytań generowanych przez aplikację

Zapewne można wyróżnić jeszcze kilka kategorii, aczkolwiek proszę o wyrozumiałość, gdyż nic więcej nie przyszło mi do głowy. W tym poście skupię się na zagadnieniach związanych z blokowaniem zapytań i narzędziach które mogą pomóc w rozwiązowaniu problemów spowodowanych przez blokady.

Blokowanie na ekranie

Blokowanie zapytań jest zjawiskiem częstym na platformie SQL Server, wynika ona z architektury tego silnika bazodanowego i domyślnego ustawienia poziomu izolacji tranzakcji na READ COMMITED. Praktycznie każde zapytanie generuje blokady (różnego rodzaju), zatem rozumienie mechanizmu blokad w SQL Serverze jest dosyć istotne. Istnieje kilka prostych procedur składowanych, które mogą nam dostarczyć potrzebnych informacji na temat blokowanych procesów, zapytań.

LockSampleDb

Zacznę od utworzenia bazy danych LockSampleDb, która posłuży nam za poligon eksperymentalny do monitorowania blokad.

CREATE DATABASE LockSampleDb
GO
Use LockSampleDb
GO
CREATE TABLE dbo.LockSample
(
 Id Int,
 Name Varchar(20)
)
GO
  --Works only in SQL Server 2008 and higher
 DECLARE @i Int = 1
 WHILE @i < 1000
 BEGIN
 INSERT INTO LockSample(Id,Name)
    VALUES (@i, 'Row '+CAST(@i AS VARCHAR)) 
    SET @i += 1
 END
GO

Otwórz SQL Server Management Studio i uruchom poniższe zapytanie w jednym oknie.

--Query Window 1
Use LockSampleDb
GO
BEGIN TRAN
 
 UPDATE LockSample
 SET Name = 'Row Updated'
 WHERE Id = 40
 --ROLLBACK TRAN

A w drugi uruchom poniższe zapytanie.

Use LockSampleDb
GO
--Query Window 2 
SELECT * FROM  LockSample WHERE Id = 40

SELECT powinien ładnie zawisnąć, ponieważ próbuje odczytać wiersz, który jest już aktualizowany przez pierwsze zapytanie (tranzakcja jest otwarta, ponieważ nie została uruchomiona instrukcja COMMIT TRAN lub ROLLBACK TRAN).W tym momencie możemy zadziałać na kilka sposobów (SPID procesu zablokowanego to 82, blokującego SPIP to 75, SPID - Server Process Identifier).

Activity monitor dla leniwych

Najprostszym narzędziem do analizy zablokowanych zapytań jest SQL Server Management Studio Activity Monitor (aka Activity Monitor). Wyświetli on wszystkie procesy SQL Server'a (nie mylić z sqlservr.exe) i w kolumnie Blocked By znajdziemy winowajcę (w SQL Server 2008 klikamy prawym na instancję SQL Servera i wybieramy z menu Activity Monitor).

Kolumna 'Blocked By' wyświetliła SPID procesu blokującego ( w naszym przypadku 75). Wyświetlając Details dla procesu SPID=75 możemy zobaczyć ostatnie zapytanie wykonane na tym procesie, które może powodować blokadę. Podkreślam, może powodować, jest to po prostu ostatnie zapytanie wykonane dla tego procesu.

sp_who

sp_who jest procedurą systemową, jest ona częścią silnika bazodanowego. Po wywołaniu prezentuje ona listę "procesów" SQL Servera z informacjami o użytkowniku w kontekście którego uruchamiane są polecenia. Dla nas istotną informacją jest kolumn SPID (identyfikator procesu)oraz blk (numer SPID procesu który blokuje dany proces). Na poniższym obrazku widać, że proces SPID=82 jest blokowany przez proces SPID=75. Czasami może być tak, że wiele procesów będzie blokowanych, a my szukamy tylko jednego. Z poziomu aplikacji trudno nam będzie ustalić jaki jest SPID danego połączenia, ale z pomocą może przyjść nieudokumentowana procedura sp_who2 która wyświetla dodatkowe informacje o procesie (np. ProgramName).

sp_blocker_pss08 czyli kombajn

sp_blocker_pss08 to procedura dostarczona przez Microsoft do rozwiązaywania problemów z blokowanie. Rezultatem uruchomienia tej procedury są informacje o blokadach, rodzajach blokad, procesach na poziomie instancji SQL Server'a.

sp_blocker_pss08 ma trzy rodzaje skryptów tworzących procedurę, w zależności od wersji SQL Servera, więc nie bądź zaskoczony błędami przy uruchomieniu Microsoft'owych skryptów.

Oczywiście, zawsze można skorzystać po prostu z starej, dobrej sp_lock, niestety jest ona oznaczona jako deprecated w BOL (Books Online).

sp_lock (deprecated)

W dalszym poszukiwaniu winowajcy, możemy skorzystać z procedury systemowej sp_lock. Umożliwia ona wylistowanie blokad dla danego procesu lub dla wszystkich procesów SQL Server na instancji. Ponieważ wiemy, że proces SPID=75 blokuje zapytanie SELECT. Możemy pokusić się o wywołanie sp_lock w poniższy sposób.

EXEC sp_lock 75

Widać, że na proces 75 założył Exclusive Lock na wierszu. Rozszyfrowując ObjId używając funkcji Object_Name docieramy do tabelki LockSample.

SELECT OBJECT_NAME(2105058535)

Można pójśc o krok dalej i znaleźć wiersz, na którym "zawisł" SELECT. Wystarczy użyć nieudokumentowanego polecenia DBCC PAGE. Odczytujemy file_id=1, page_id=78 i row_id=39 z columny Resource.

DBCC TRACEON(3604) 
DBCC PAGE (LockSampleDB, 1, 78,3)

I otrzymamy dump całej strony bazy danych na której znajduje się nasz problematyczny wiersz i lokalizujemy dane w tym wierszu.

Pomocne mogą okazać się Dynamic Management Views (DMV's, np. sys.dm_tran_locks.

SELECT * FROM sys.dm_tran_locks WHERE request_session_id = 75

Zaprezentowałem kilka sposobów lokalizowania problemów z blokowaniem zapytań. Zachęcam do eksperymentów z blokowaniem, polecam laboratoria PSS Service Center Labs - 2005 dostępne na stronie Microsoft.

Hope this helps.

PowerShell - antywzorzec kopiuj/wklej

2011-09-26T19:25:00.002+02:00

Dlaczego lubię Add-Type

Pisząc skrypty w PowerShell'u, szczególnie takie jednorazowego użycia kuszącą opcją jest skorzystanie z cmdlet'u Add-Type. Umożliwia on rejestrację typu(-ów) danych zaimplementowanego w C#,VB.NET lub JScript i wykorzystanie go w skrypcie PowerShell'u. W moim przypadku gdy próbowałem użyć typów danych z .NET Framework w skrypcie otrzymałem następujący wyjątek.

Multiple ambiguous overloads found for ... and the argument count: ...

Runtime Powershell'a z jakiegoś powodu nie mógł dopasować odpowiedniej sygnatury metody z typem przekazywanych parametrów. Zamiast spędzić kolejne pół godziny nad hackowaniem kodu, użyłem magicznego cmdlet'u Add-Type.

Copy/Paste anti-pattern

Skopiowałem istniejący kod w C#, wypisałem referencje do zależnych assembly i wszystko zadziałało bez problemu.

$referencedAssemblies = ( 
 "System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089",
    "System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
    )

$sourceCodeInCSharp = @"
using System.Xml.Linq;

namespace XmlTest
{
    public class XmlGenerator
    {
        public void SaveFile(string filePath)
        {
            XDocument document = new XDocument();
            XElement rootElement = new XElement("root",
                new XElement("children",
                    new[]{
                new XElement("child1", "Child1Value"),
                new XElement("child2", "Child2Value")
            }));
            document.Add(rootElement);
            document.Save(filePath);
        }
    }
}
"@


if ([Type]::GetType("XmlTest.XmlGenerator") -eq $null) 
{
 Add-Type -ReferencedAssemblies $referencedAssemblies -TypeDefinition $sourceCodeInCSharp -Language CSharpVersion3
}

$generator = New-Object XmlTest.XmlGenerator;
$generator.SaveFile("test.xml");

Wynik działania skryptu jest następujący

<?xml version="1.0" encoding="utf-8"?>
<root>
  <children>
    <child1>Child1Value</child1>
    <child2>Child2Value</child2>
  </children>
</root>

Zatem, jeżeli nie lubisz Powershell'a, nie masz ochoty lub potrzeby kowertowania kodu z C#/VB.NET etc do PS to zachęcam z zapoznaniem sie z poleceniem Add-Type, które umożliwia także generowanie typów z plików kodu źródłowego.

Hope this helps.

Statystyczny programista .NET - A.D. 2011

2011-09-12T08:52:00.003+02:00

Co powinien umieć programista .NET w 2011 roku?

Skupiając się w ostatnich dwóch latach na poznawaniu arkanów SharePoint'a i rozwijaniu własnych zainteresowań, prawie kompletnie zaniedbałem wgryzanie się w coraz to nowe technologie pojawiające się na platformie .NET. Ostatni raz poszukiwałem pracy 4 lata temu, z czystej ludzkiej ciekawości postanowiłem sprawdzić na jakie umiejętności w obrębie technlogii .NET teraz jest zapotrzebowanie na polskim rynku pracy. Oczywiście w tym poście dopuszczę się wszelakich nadużyć i uogólnień, zatem z góry proszę o wybaczenie. Moim celem jest ustalenie jakie umiejętności definiują statystycznego "polskiego" programistę .NET.

Do analizy rynku pracy dla programistów .NET wybrałem mało naukową metodę. Postanowiłem przeglądać ogłoszenia o pracę (jobpilot.pl, pracuj.pl) w liczbie 40-stu i wypisywać (oraz zliczać) nazwy technologii, które pojawiają się w treści ogłoszenia.

Statystyczny koder powinien

Programować w C# z zamkniętymi oczami
Równie dobrze posługiwać się T-SQL'em
Biegle operować ASP.NET WebFoms
i w sumie tyle

Opcja "Nice to have"

XML (XSLT, XML)
Web Services
WCF
JavaScript
ASP.NET MVC
SharePoint
Design Patterns
UML (tutaj byłem zaskoczony)
Source control (SVN, TFS)

Jeśli chcemy być bardziej niszowi to

WPF/Silverlight
SCRUM (trochę słabo, że to jest nisza)
Reporting Services
Oracle
Workflow Foundation
Domain Driven Design

Zaskoczył mnie prawie kompletny brak wymagań dotyczących TDD, Agile (SCRUM, Kanban), technologii okienkowych (WinForms, WPF). Certyfikacje Microsoft też nie wydają się, żeby miały jakiekolwiek znaczenie dla przyszłych pracodawców (1/40). Ogólnie Web rządzi na całego, muszę się zacząć uczyć JavaScript'u :)

Moje pierwsze dwa lata pracy zawodowej to było programowanie w VB.NET, ale w Polsce na szczęście ten język jest równie popularny jak Esperanto. A tutaj bardziej tabelkowe ujęcie zagadnienia.

Excel file. Interaktywną wersja raportu można znaleźć tutaj.

IMHO, dobry programista .NET powinien znać/umieć/rozumieć

C# (.NET 4.0, LINQ)
Design patterns
Domain Driven Design
TDD, (x)Unit, Mocking frameworks
Visual Studio (zaawansowany)
Programowanie SQL Server
Metodologia Agile (chociaż jedno Scrum, Kanban, XP)
SOA
XML stack (XSL, XSD, XML)
Jedno repozytorium kodu np. SVN, Git, Team Foundation System
Być WEB (JavaScript, CSS, HTML basics, Accessibility e.g. WCAG) lub Windows Client (WPF)

IMHO, "Nice to have"

Algorytmy w ramach zainteresowań
User Interface Design
HTML/CSS

Podsumowując, polski rynek pracy dla programistów .NET jest dosyć spolaryzowany. Dominują aplikacje web'owe z backend-em opartym na Microsoft SQL Server . W sumie nic nowego, tylko okienek żal.

Hope this helps.

WPF DataGrid w służbie metadanych

2011-09-09T20:12:00.003+02:00

DataGrid i ja

Z programowaniem okienek w Windows rozstałem się na drugim roku studiów. Moje życie zawodowe tak się ułożyło, że nigdy później nie tknąłem Win32 API, MFC, WinForms,a tym bardziej WPF'a. W noworocznym postanowieniu ustaliłem, że spróbuję opanować chociaż podstawy Windows Presentation Foundation. W ramach realizacji postanowień, moja uwaga skupiła się na problemie prezentacji danych w postaci tabelarycznej w WPF.

W .NET Framework 3.5 do dyspozycji programisty WPF był WPF Toolkit, w którego skład wchodził DataGrid. W .NET Framework 4.0 kontrolka DataGrid wróciła z wygnania na codeplex.com i została włączona do Windows Presentation Foundation.

Ku mojemy zaskoczeniu DataGrid wykazał się dosyć rozbudowaną funkcjonalnością. Scenariusz, który chciałem zrealizować można zoobrazować w następujący sposób. Mamy listę piesków (dogs) i kotków (cats), wyświetlając listy tych zwierzaków nie chciałem deklaratywnie definiować każdego atrybutu w WPF'owym XAML'u. Chciałem wypracować bardziej dynamiczne podejście (cały kod projektu jest dostępny tutaj). Klasy kotków i piesków wyglądają jak poniżej.

public abstract class AnimalBase
{
    public string NickName { get; set; }

    public DateTime DateOfBirth { get; set; }
}

public class Dog : AnimalBase
{
    public string FavouriteFood { get; set; }

    public string BarkingSong { get; set; }
}

public class Cat : AnimalBase
{
    public string HasStripes { get; set; }

    public string MiaowTune { get; set; }
}

Dodajmy klasę AnimalPlanet która wygeneruje nam trochę testowych danych, a przy okazji przyda się do zademonstrowania deklaratywnego tworzenia instancji obiektów w XAML'u.

<usercontrol.resources>
   <wpfdatagrid:animalplanet x:key="Animals"></wpfdatagrid:animalplanet>
</usercontrol.resources>

public class AnimalPlanet
{
    private List<Cat> _cats;
    private List<Dog> _dogs;

    public AnimalPlanet()
    {
        _cats = new List<Cat>();
        _dogs = new List<Dog>();

        _cats.Add(new Cat
        {
            NickName = "Dachowiec", 
            DateOfBirth = DateTime.Now.AddMonths(-13).Date, 
            HasStripes = true,  
            MiaowTune = "DODA, Nie daj sie"
        });
        _cats.Add(new Cat 
        { 
            NickName = "Szczesciarz", 
            DateOfBirth = DateTime.Now.AddYears(-5).Date, 
            HasStripes = false, 
            MiaowTune = "DODA, Katharsis" 
        });
        
        _dogs.Add(new Dog 
        { 
            NickName = "Burek", 
            DateOfBirth = DateTime.Now.AddYears(-7).Date, 
            FavouriteFood = "Burito", 
            BarkingSong = "Feel, Jak aniola glos" 
        });
    }


    public List<Cat> Cats { get { return _cats; } }

    public List<Dog> Dogs { get { return _dogs; } }
}

Wersja deklaratywna

Pierwsza wersja deklaratywna listy kotków i piesków powoduje, że musimy deklarować nagłówki, powtarzać deklaracje kolumn itd. Oczywiście posługiwanie XAML'em jest preferowaną metodą w budowaniu WPF'owego UI, aczkolwiek ja chciałem rozwiązać ten w sumie prosty problem w trochę inny sposób.

DeclarativeDataGrid.xaml

<UserControl x:Class="WPFDataGrid.DeclarativeDataGrid"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:Animals="clr-namespace:WPFDataGrid.Domain.Animals">
    
    <UserControl.Resources>
        <Animals:AnimalPlanet x:Key="Animals"></Animals:AnimalPlanet>
    </UserControl.Resources>

    <Grid DataContext="{StaticResource ResourceKey=Animals}">
        <Grid.RowDefinitions>
            <RowDefinition />
            <RowDefinition Height="30" />
            <RowDefinition />
        </Grid.RowDefinitions>
        
        <StackPanel Grid.Row="0">
            <TextBlock FontWeight="Bold">Dogs</TextBlock>
            <DataGrid ItemsSource="{Binding Dogs}" AutoGenerateColumns="False" HorizontalAlignment="Left" CanUserAddRows="False">
                <DataGrid.Columns>
                    <DataGridTextColumn Header="Nickname" Binding="{Binding NickName}" />
                    <DataGridTextColumn Header="Date of birth" Binding="{Binding DateOfBirth}" />
                    <DataGridTextColumn Header="Favourite Food" Binding="{Binding FavouriteFood}" />
                    <DataGridTextColumn Header="Barking Song" Binding="{Binding BarkingSong}" />
                </DataGrid.Columns>
            </DataGrid>
        </StackPanel>

        <StackPanel Grid.Row="2">
            <TextBlock FontWeight="Bold">Cats</TextBlock>
            <DataGrid ItemsSource="{Binding Cats}" AutoGenerateColumns="False" HorizontalAlignment="Left" CanUserAddRows="False">
                <DataGrid.Columns>
                    <DataGridTextColumn Header="Nickname" Binding="{Binding NickName}" />
                    <DataGridTextColumn Header="Date of birth" Binding="{Binding DateOfBirth}" />
                    <DataGridCheckBoxColumn Header="Has Stripes" IsThreeState="True" Binding="{Binding HasStripes}" />
                    <DataGridTextColumn Header="Miaow Tune" Binding="{Binding MiaowTune}" />
                </DataGrid.Columns>
            </DataGrid>
        </StackPanel>
    </Grid>
</UserControl>

Atrybuty na ratunek

W rozwiązaniu deklaratywnym każda kolumna DataGrid musiała mieć odpowiednik w XAML'u. Jeżeli mamy takich tabelek 10 to praktycznym rozwiązaniem może być generowanie kolumn tabeli na podstawie metadanych obiektów. Do definiowania metadanych użyłem atrybutów .NET. Atrybut VisibleItem dostarcza informacji o tym, które z właściwości (property) danej klasy należy wyświetlać w DataGrid. DisplayName definiuje nagłówek kolumny wyświetlającej dane. Poniżej definicja klasy VisibleItemAttribute, które określa, że ten atrybut może być stosowany do właściwości klas i dla danej właściwości może występować jednokrotnie.

[AttributeUsage(AttributeTargets.Property, AllowMultiple = false)]
public class VisibleItemAttribute : Attribute
{
    public VisibleItemAttribute(string displayName)
    {
        DisplayName = displayName;
    }

    public string DisplayName { get; set; }
}

Po wprowadzeniu atrybutu VisibleItem klasa AnimalBase wygląda następująco.

public abstract class AnimalBase
{
    [VisibleItem("Nickname")]
    public string NickName { get; set; }

    [VisibleItem("Date Of Birth")]
    public DateTime DateOfBirth { get; set; }
}

XAML nowej wersji DataGrida został znacząco uproszczony, aczkolwiek code-behind klasy znacząco sie rozrósł, gdyż cała logika odczytywania metadanych obiektów została tam zaimplementowana.

MetadataGrid.xaml

<UserControl x:Class="WPFDataGrid.MetadataGrid"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Grid >
        <Grid.RowDefinitions>
            <RowDefinition />
        </Grid.RowDefinitions>

        <StackPanel Grid.Row="0">
            <TextBlock FontWeight="Bold" Text="{Binding Title}" />
            <DataGrid Name="dgMetadata" AutoGenerateColumns="False" HorizontalAlignment="Left" CanUserAddRows="False" />
        </StackPanel>
    </Grid>
</UserControl>

MetadataGrid.xaml.cs

Metoda BuildColumnsFromMetadata generuje kolumny DataGrid'a w zależności od obecności atrybutu VisibleItem oraz typu danej właściwości obiektu.

public partial class MetadataGrid : UserControl
{
    public string Title { get; set; }

    private IList _itemsSource;

    public IList ItemsSource
    {
        get { return _itemsSource; }
        set
        {
            _itemsSource = value;
            BuildColumnsFromMetadata(_itemsSource);
            dgMetadata.ItemsSource = _itemsSource;
        }
    }

    public MetadataGrid()
    {
        InitializeComponent();
        DataContext = this;
    }

    private void BuildColumnsFromMetadata(IList data)
    {
        dgMetadata.Columns.Clear();
        if (data.Count > 0)
        {
            object firstElement = data[0];

            PropertyInfo[] properties = firstElement.GetType().GetProperties();
            foreach (PropertyInfo property in properties)
            {
                object[] visibleAttributes = property.GetCustomAttributes(typeof(VisibleItemAttribute), false);
                if (visibleAttributes.Length > 0)
                {
                    VisibleItemAttribute itemAttribute = (VisibleItemAttribute)visibleAttributes[0];
                    if (property.PropertyType.Name.Equals(typeof(bool).Name))
                    {
                        var checkBoxColumn = new DataGridCheckBoxColumn();
                        checkBoxColumn.Binding = new Binding(property.Name);
                        checkBoxColumn.Header = itemAttribute.DisplayName;
                        checkBoxColumn.IsThreeState = true;
                        dgMetadata.Columns.Add(checkBoxColumn);
                    }
                    else
                    {
                        var textColumn = new DataGridTextColumn();
                        textColumn.Binding = new Binding(property.Name);
                        textColumn.Header = itemAttribute.DisplayName;
                        dgMetadata.Columns.Add(textColumn);
                    }
                }
            }
        }
    }
}

Dodatkowo można byłoby dodać atrybuty grupowania, sortowania oraz rozszerzyć VisibleItem o właściwość kolejności kolumn i zaimplementować ich obsługę.

Hope this helps.

Jak można zapełnić cały dysk i wyjść z tego cało?

2011-08-31T20:14:00.004+02:00

Ignorancja to prosta droga do problemów

Pracując na wirtualnej maszynie i po raz kolejny ratując mój SharePoint'owy świat od zagłady, spostrzegłem, że na dysku C zostało mi 10 MB. Byłem zaskoczony, ale cóż mogę zrobić. Usunąłem niepotrzebne pliki na dysku i zyskałem 400MB, poczułem ulgę. Po 20 minutach znowu zabrakło mi miejsca na dysku C, zacząłem wiec myśleć (uff ...w końcu).

Uruchomiłem Process Monitor'a (z SysInternals Suite), ustawiłem filtr na operacje zapisu do plik

zacząłem przeglądać trace'a i ...

.... zobaczyłem, że na dysku E generowane jest dużo plików z informacją o Assembly Binding (Assembly Binder Log Entry). Spowodowane było to włączeniem logowania binding'u przez Fusion Log Viewer (Fuslogvw.exe), które zapomniałem wyłączyć (jak włączyć logowanie pisałem tutaj).

Widzę, że ewidentnie to na dysku E generują się te pliku logu, ale "może" (to już jest lamerstwo z mojej strony) też coś na dysku C było zapisywane. Wyłączyłem logowanie i zrestartowałem wszystki procesy i serwisy korzystającego z CLR.NET, aby zaprzestać generowaniu plików z assembly biding.

Szczęśliwy wróciłem do pracy i znowu po jakim czasie skończyło się miejsc na dysku C. Tym razem sięgnąłem po narzędzie zwane WinDirStat. To cudo niemieckiej technologi, narysowało mi fajne mapki (TreeMap), przeszukało mi wszystkie pliki na dysku, przypisało kategorie na podstawie rozszerzenia pliku, i znalazło duży plik logu bazy danych (.ldf) i page file'a.

Najbardziej podobał mi się TreeMap, który w zależności od rozmiaru pliku rysuje proporcjonalny kwadracik. Np. na czerwono widać plik o rozszerzeniu *.sys, a na zielono i żółto kolejno pliki baz danych *.mdf i *.ldf. Taka mapka umożliwia bardzo szybkie zlokalizowanie przerośniętego pliku i określenie, jakiego typu pliki zajmują najwięcej miejsca na dysku.

Na wirtualnej maszynie nie robię backup'ów baz danych, a domyślnie bazy kontentowe SharePoint'a są ustawione na Full recovery model. Zatem transakcyjny log rośnie do dowolnych rozmiarów zanim nie zostanie przeprowadzony Full backup bazy lub chociaż backup logu. Zmiana recovery model na Simple i shrink pliku logu transakcyjnego rozwiązało problem ciągłego przyrostu i zmiejszyło rozmiar pliku *.ldf.

Page file'a zwalczyłem w następujący sposób (Manage Computer->Advanced system settings->Advanced tab->Performance->Advanced tab->Change button.

Nie polecam takich ustawień Page File'a na produkcyjnym serwerze, ale mi potrzebne było miejsce na dysku.

Hope this help.

12 zasad kulturalnego programisty SharePoint'a (Część II - EOM)

2011-08-19T21:49:00.000+02:00

Zasad cdn-astąpił

W poprzednim poście opisałem jak "kulturalny" programista SharePoint'a powinien obchodzić się z feature'ami. Tym razem postaram się opisać kolejne 8 zasad dotyczących WebPartów, Event Reciever'ów, zarządzania zasobami serwera oraz ogólną "czystością" środowiska.

WebPart

Przychodzi taki moment w projekcie, że klientowi nie podoba się dany Webpart i chciałby go usunąć ze swojego portfolio (Wepart Gallery). Usłużny programista usuwa niepotrzbną klasę webparta i wrzuca nową wersję biblioteki na serwer produkcyjny. Problemy, które mogą wyniknąć z takiego podejścia opisuję w postach Test-SPContentDatabase and how to locate MissingWebPart oraz SPLimitedWebPartManager and ErrorWebPart on and off relationship, polecam też KB976218. Użytkownicy zostają z ErrorWebPart'ami wyświetlonymi na stronie i pozostaje im tylko WebPart'owe sepuku. Zatem zasadar nr. 5.

Klasa WebPart'a może zostać usunięta po zlikwidowaniu wszystkich instancji Webpart'a znajdujących się na farmie.

Inną przypadłością deinstalacji WebPart'ów jest pozostawianie plików .dwp w WebPart gallery. Pliki te po usunięciu z katalogu SharePoint'a (12-tki lub 14-tki) pliku dwp oraz biblioteki zawierającej klasę WebPart'a zaśmiecają galerię WebPart'ów. Zatem zasada nr. 6

Proces odinstalowania Webpart'a powinien zawierać usuwanie pliku dwp z WebPart Gallery.

Biblioteka zawierająca klasę WebPart'a musi być podpisana kluczem (strongly-signed) aby jednoznacznie określić wersję danego dll'a. W momencie gdy programista postanowi podbić wersję biblioteki (np. z 1.0.0.0 do 1.1.0.0) wpłynie to na istniejące instancje WebPart'a. Należy wtedy dodać assembly binding redirection do web.config'a i "przekierować" wszystkie instniejące instancje ze starszej wersji na nową oraz dodać nowy wiersz do SafeControls dla 1.1.0.0 i utrzymać stary dla wersji 1.0.0.0. Jest to potrzebne do momentu wyświetlenia przez UI po raz pierwszy instacji WebPart'a, od tego momentu korzysta on z wersji 1.1.0.0. Po pewnym czasie można zatem usunąć SafeControls dla 1.0.0.0, oczywiście jeżeli wszystkie WebParty zostały wyświetlone. Uwaga na boku, bug (opisany tutaj) związany z Assembly BindingRedirect element (solution manifest.xml) został naprawiony dopiero w June CU 2011 dla SharePoint'a 2010. Zatem zasada nr. 7

Nowe wersje biblioteki WebPart'a muszą być obsłużone przez wpisy BindingRedirect w Web.config'u.

Event Receiver

System wymaga ciągłych zmian, nasze feature'y rejestrują najdziwniejsze event receivery. Instalujemy komponenty od zewnętrznych dostawców, one też dodają event receivery aby obsługiwać możliwie najwięcej zdarzeń. OK, a jeżli nie jest już nam potrzebny dany Event Receiver, to trzeba go odpiąć od każdego zarejestrowanego zdarzenia, i kropka ( a jak nie to znowu KB976218). Zasada nr 8.

Klasę Event Receiver'a można usunąć tylko po odrejestrowaniu wszystkich referencji do obsługiwanych zdarzeń.

Rozmaitości

W developmencie SharePoint'a zmiany trzeba dobrze zaplanować i przetestować. Szczególnie jeżeli nadgorliwy programista chce przeprowadzić intensywny "refactoring", aby naprawić całe zło tego świata. Zmiany nazw feature'ów, katalogów, plików, assembly, zmiany wersji assembly, usuwanie elementów, to przykłady refactoringu który może rzucić cię na kolana, jeżeli nie zrobisz tego prawidłowo. Na pocieszenie mogę powiedzieć, że SharePoint 2010 oferuje mechanizmy do np. przenoszenia plików w obrębie katalogu 14\Template\Features\ (patrz MapFile) w ramach upgrade'u instancji feature'a. Zasada nr 9.

Z refactoringiem w SharePoint jak z ogniem, czyli ostrożnie.

Kolejnym wdzięcznym tematem w programowaniu SharePoint są modyfikacje Web.config. Przypominam, że Web.config to nie smietnik, dodane wpisy należy usuwać gdy są już niepotrzebne. Należy też nauczyć się obsługi klasy SPWebConfigModification lub chociaż XPath'a, żeby nie dodawać np. duplikatów. Polecam feature'a do modyfikowania Web.config'a opisanego w tym poscie. Zasada nr 10.

Web.config trzymamy w należytym stanie. Dodajemy elementy i usuwamy kiedy są już nie potrzebne, zawsze używając SharePoint API.

Rozszerzając funkcjonalność SharePoint'a często korzystamy z obiektów SPWeb, SPSite. Obiekty te konsumują znaczne ilości pamięci operacyjnej. Na farmie SharePoint'a pamięć należy szanować, dlatego wszystkich programistów SharePoint'a zachęcam do uważnego wczytania się w artykuł 'Introduction to Using Disposable SharePoint Objects'. Po prostu 'Don't do evil' i nie produkuj memory leak'ów. Zresztą, nasz rodzimy SharePoint MVP Gutek o tym pisał np tutaj. Zasada nr. 11.

Programując w SharePoint szanuj nie tylko zieleń, ale i pamięć.

Na rynku dostępnych jest dużo produktów partnerów Microsoft'u oferujących rozszerzenie funkcjonalności SharePoint'a. Może się zdarzyć, że wasz klient przymusi was do korzystania z takiego rozwiązania Out-of-the-box. Może ponieść to za sobą pewne konsekwencje, szczególnie przy instalowaniu nowych wersji, lub przy migracji na nową wersję SharePoint'a. Vendor oprogramowania może w dowolnej wersji naruszyć wstęczną kompatybilność (np. poprzez usunięcie feature'a), trzeba na to bardzo uważać i patrzeć mu na ręce analizując dostarczone pliki solution (WSP'y). Jest to o tyle istone, że rozwiązywanie potencjalnych problemów może spaść na biednego developer'a. Zatem zasada nr. 12.

Jeżeli używasz komponentów 3rd-party to zaprzyjaźnij się z zespołem wsparcia tego produktu.

Mam nadzieję, że ta lista "zasad" okaże się przydatna w uniknięciu chociaż części problemów z utrzymywaniem środowiska produkcyjnego opartego na platformie SharePoint.

Hope this helps.

12 zasad kulturalnego programisty SharePoint'a (Część I)

2011-08-18T22:37:00.003+02:00

Trauma i terapia w jednym

Migracja z MOSS'a 2007 do SharePoint'a 2010 to dla mnie bardzo osobisty temat. Od roku z krótszymi lub dłuższymi przerwami zajmuję się zagadnieniami związanymi z migracją. Przechodzenia na nowszą wersję SharePoint'a mogłoby być znacznie przyjemniejszym tematem, gdyby każdy był "kulturalnym" programistą SharePoint'a. Co to znaczy "kulturalny" programista SharePointa? Jest to taki jegomość, który po sobie zawsze zostawia porządek, a w szególności kod napisany przez tego jegomościa zawsze po sobie posprząta i nie rozrabia. Okazuje się, że na platformie SharePoint bardzo łatwo można zostawić po sobie bałagan. Jako część terapii post-migracyjnej postanowiłem napisać 12 zasad "kulturalnego" obchodzenia się z SharePoint'em. Przestrzeganie ich grawantuje dłuższe weekendy z rodziną i więcej czasu na łowienie ryb oraz szeroko rozumiane zdrowie psychiczne.

Feature

Wszystko zawsze zaczyna się od niewinnego feature'a. W sumie SharePoint powinien nazywać się FeaturePoint. Feature'y to podstawa każdego komponentu w SharePoint'cie, zatem zrozumienie ich cyklu życia jest bardzo ważne. Feature instalujemy raz dla całej farmy, aktywujemy wielokrotnie (nazwę to instancją feature'a), to samo z deaktywacją (usunięcie instancji feature'a), i na koniec odinstalowujemy (ewentualnie upgrade'ujemy ale to inna historia). Czyli wszystko jasne. Niestety nie zawsze ten łańcuch zdarzeń musi się wykonać. W praktyce może to wyglądać następująco

CoolFeature jest instalowany
CoolFeature jest aktywowany na Site1, Site2, Site3
CoolFeature jest deaktywowany na Site1, Site2
CoolFeature jest odisntalowany z atrybutem force lub usunięty z pliku solution (.wsp).
I zostaliśmy z osieroconą instancją feature'a na Site3

Z tego przykładu wynika zasada nr.1

Zanim feature może być usunięty z pliku solution lub odinstalowany wszystkie jego instancje muszą być dezaktywowane i jeśli to konieczne odinstalowane. Dotyczy to całej farmy SharePoint'a.

Innym przypadkiem, z który można się zetknąć, jest zmiana Scope'u feature'a. Mamy do wyboru cztery Farm, Web Application, Site (site collection), Web (site). Scenariusz który może wpędzić nas w kłopoty jest następujący.

CoolFeature jest instalowany (Scope=Site)
CoolFeature jest aktywowany na Site1
CoolFeature ma zmieniony Scope na Web
CoolFeature jest instalowany z atrybutem force
CoolFeature jest aktywowany z atrybutem force na Site1
Zostaliśmy z osieroconą instancją feature'a na Site1 ze scope=Site

Problemy, które mogą wyniknąć z posiadania takich "sierot" opisuję w poście 'SharePoint 2010 upgrade failed - Feature upgrade failed for Feature'. Zatem, zasada nr.2.

Scope feature'a może być zmieniony w sytuacji, w której feature zostanie najpierw deaktywowany na całej farmie i odinstalowany.

Programista to taka niespokojna istota, cały czas chciałaby coś zmieniać. Najbardziej lubi zmieniać nazwy, a taką idealną nazwą do zmiany jest nazwa feature'a. Może się to przydażyć gdy zaczniemy np. przenosić kod z Visual Studio 200x do Visual Studio 2010 dla instiejących feature'ów SharePoint'a. Zapewne będziemy chcieli skorzystać z designer'a feature'ów, aczkolwiek może się to skończyć różnie i nazwa feature'a ulegnie zmianie. Jako efekt uboczny, może się zdarzyć, że pozmieniamy ścieżki do plików, których instancje już istnieją na farmach produkcyjnych (np. instancje master page'a którego plik master jest częścią feature'a). Dlatego zasada nr. 3.

Nazwa feature'a może być zmieniona w sytuacji , w której feature zostanie najpierw deaktywowany na całej farmie i odinstalowany.

Feature'y podczas aktywacji mogą tworzyć dużo różnych obiektów (np. instancje list) lub rejestrować np. event receiver'y. W momencie deaktywacji, dobrze napisany feature powinien po sobie posprzątać, jeżeli zostało to uzgodnione z użytkownikami (np. usunięcie instacji listy przy deaktywacji feature'a może być nie do pomyślenia w niektórych przypadkach). Czyli zasada nr. 4

Jeżeli jest to możliwe feature powinien sprzątać po sobie w momencie deaktywacji.

Przy realizacji tych zasad należy kierować się zdrowym rozsądkiem, gdyż czasami z przyczyn obiektywnych nie można deaktywować feature'a. Zatem zasada nr. 0 to zdrowy rozsądek i dużo testów. W części drugiej napiszę o zasadach dotyczących WebPartów i Event Receiver'ów.

Hope this helps.

PowerShell i debuggowanie biblioteki .Net

2011-08-12T19:31:00.003+02:00

"Reużywalność" w PowerShell'u

Pisząc skrypt w PowerShell'u postanowiłem wywołać metodę z zewnętrznej biblioteki wchodzącej w skład rozwijanego przez mój zespól systemu. Zaimportowałem dll'kę za pomocą metody Assembly.LoadFrom , utworzyłem instancję typu danych i uruchomiłem metodę. Oczywiście otrzymałem wyjątek NullReferenceException, który wskazywał na to, że problem pojawił się w metodzie z zewnętrzenej biblioteki. Zastanowiłem się chwilę i stwierdziłem, że nie zaszkodziłoby zdebuggować tej metody. Ku mojemu zaskoczeniu, okazało się, że użycie Visual Studio zadziałało bez zarzutu.

Debuggowanie

Skrypt ładuje bibliotekę ReusableLibrary.dll, nie jest to podpisana biblioteka, znajduje się w tym samym folderze co plik skryptu. Natępnie, tworzona jest instancja klasy NetworkManager i wywołana zostaje metoda SentPackage. Uruchomieniu poniższego skryptu w konsoli PowerShell'a spowodowało zwrócenie informacji o błędzie.

$workingDir = Get-Location
$assemblyPath = [System.IO.Path]::Combine($workingDir,"ReusableLibrary.dll");
[System.Reflection.Assembly]::LoadFrom($assemblyPath);
$netManager = new-object Mulawa.ReusableLibrary.NetworkManager;
# Causes method to throw NullReferenceException
$netManager.SentPackage("");

trap  [Exception]
{
	write-error $($_.Exception.GetType().FullName); 
	write-error $($_.Exception.Message); 
}

Błąd NullReferenceException poniżej.

Dysponując kodem źródłowym (cały projekt dostępny jest tutaj) do bibiloteki ReusableLibrary uruchomiłem "jedyne słuszne środowisko developerskie". Skompilowałem ResuableLibrary.dll w trybie DEBUG i skopiowałem ddl'kę do katalogu w którym znajdowal się skrypt SentNetworkPackage.ps1. Uruchomiłem ponownie sesję PowerShell'a. Odpaliłem skrypt, tak żeby process konsoli PowerShell'a załadowala dll'kę do AppDomain.

W Visual Studio wybrałem z menu Debug->Attach to Process.

W dialogu "Attach to Process" zlokalizowałem proces Powershell.exe i kliknąłem "Attach".

Wybierając opcję Debug->Windows->Modules można sprawdzić, że symbole (pliki pdb) assembly ReusableLibrary.dll załadowały się poprawnie. Potwierdz, to też wypełniona czerwona kropka breakpoint'a.

W tym momencie możemy uruchomić ponownie skrypt powershell i przystopić do zlokalizowania źródła błędu.

Do edycji skryptów PowerShell'owych użyłem darmowej wersji edytora PowerGUI, który wspiera intellisense, umożliwia debuggowanie czy wstawianie snippetów, ma także wbudowaną wyszukiwarkę skryptów opublikowanych online. Ogólnie polecam.

Jeśli nie GAC to jak?

Jeszcze dwa słowa o ładowaniu bibliotek zewnętrznych w Powershell'u. W przykładzie użyłem metody Assembly.LoadFrom, żeby wczytać bibliotekę (niepodpisana) z lokalnego folderu. Aczkolwiek biblioteka może być podpisana i znajdować się w GAC'u. Wtedy do załadowania możemy wykorzystać metodę Assembly.Load.

[System.Reflection.Assembly]::Load("ReusableLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=7b7ae4b98f14b79d");

Jeżeli Assembly nie jest podpisane i znajduje się w katalogu aplikacji (dla powershell.exe domyślnie to jest SystemDrive\Windows\System32\WindowsPowerShell\v1.0) to wystarczy wywołać Assembly.Load w następujący sposób wykorzystując tylko assembly "simple name".

[System.Reflection.Assembly]::Load("ReusableLibrary");

Popularną metodą wczytywanie bibliotek w PowerShellu jest używanie Assembly.LoadWithPartialName. Ta metoda od .NET Framework 2.0 jest oznaczona jako obsolete, choć jej popularność nie słabnie. Metoda LoadWithPartialName próbuje załadować bibilotekę z katalogu aplikacjia lub z GAC'a pobrać ostatnią wersję biblioteki.

[System.Reflection.Assembly]::LoadWithPartialName("ReusableLibrary");

Hope this helps.

Why SharePoint 2010 parallel content database upgrade can make your life difficult?

2011-08-11T20:15:00.007+02:00

Parallel means faster upgrade

I've been faced with the upgrade of ~200 content databases (~2TB) from MOSS 2007 to SharePoint 2010. Content databases will be hosted on four different SP2010 farms, and the method chosen for the content upgrade was attach-database. This method is using Mount-SPContentDatabase command to attach and upgrade particular database. If upgrade fails for some reason you can restart it by using Upgrade-SPContentDatabase (it worked pretty well for me). Single database can take a significant time to upgrade (e.g. 50GB database took 4h), but the migration time depends on the number of factors (e.g. hardware, network latency, SharePoint data characteristics, disk space available).

The first attempt to tackle the task was by doing sequential upgrade (I just forgot that I can do it in a parallel way, good for me :)). After fixing problems with the content described here and here, I got to the point where I was able to upgrade all content databases without any failures (single error causes upgrade being marked as failed). These were the happy times.

However, content migration was taking to much time, so as being proactive I picked parallel upgrade approach. My inner voices were sceptic, however reading Microsoft documentation made me more confident.

You can attach and upgrade multiple databases at a time to speed up the upgrade process overall. The maximum number of parallel upgrades depends on your hardware. .... Faster upgrade times for your overall environment.

I didn't get lucky enough

Hurray...., I said to myself. I've opended four poweshell sessions on the single front-end server and run my batch files full of Mount-SPContentDatabase calls. I was upgrading four content database at the same time. To my surprise, I've received a bunch of errors during this upgrade:

Error Type	Error Message
Feature upgrade failure	Feature upgrade incomplete for Feature 'Fields' (Id: 'ca7bd552-10b1-4563-85b9-5ed1d39c962a') in Site '[SiteURLHere]'. Exception: A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
Database schema upgrade failure	Action 4.0.138.0 of Microsoft.SharePoint.Upgrade.SPContentDatabaseSequence failed. Exception: A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The specified network name is no longer available.)
Upgrade failure	This upgrade session has been stopped. Possible causes include the process being terminated abruptly or the OS has rebooted. Please restart the upgrade again.
Upgrade completed successfully	Content database is being shown on Check upgrade status page (http://CentralAdminUrl/_admin/UpgradeStatus.aspx) as migrated, however it's not. This can be verified on the Review database status page (http://CentralAdminUrl/_admin/DatabaseStatus.aspx). When accessing SharePoint sites from not-upgraded content database through API you can get the following error: Microsoft.SharePoint.Upgrade.SPUpgradeCompatibilityException: There is a compatibility range mismatch between the Web server and database "Content database name", and connections to the data have been blocked to due to this incompatibility. This can happen when a content database has not been upgraded to be within the compatibility range of the Web server, or if the database has been upgraded to a higher level than the web server. The Web server and the database must be upgraded to the same version and build level to return to compatibility range

So, does parallel upgrade sucks?

I was unpleasantly surprised to see random TCP stack errors, database schema upgrade failures appearing on random content databases. I suspected that my fellow "parallel upgrade" was causing all the hassle. I've restored content databases that have experienced failures to the MOSS 2007 version. I rerun upgrade sequentially (only one content database being upgraded on the SharePoint farm) and all errors where gone.

I'm not saying "parallel upgrade" is the ultimate evil. It just need to be handled carefully. Performance of the SQL Server IO subsystem, network latency and memory pressure on front-end, back-end servers needs to be monitored. And if need, hardware or system settings will have to be adjusted.

Or you can just stick to the sequential upgrade to be on the safe side during the "migration weekend". At least this will not increase the risk getting yourself into trouble you won't have time to solve.

Hope this helps.

BackgroundWorker kontra Dispatcher

2011-08-05T22:00:00.013+02:00

Co robić gdy użytkownik jest niecierpliwy?

Pracując nad nową wersją Replication Explorer'a postanowiłem ulepszyć UX (User Expirience) dialogu do łączenia się z serwerem (Dystrybutorem replikacji). W aktualnej wersji programu, w momencie gdy użytkownik wciśnie przycisk 'Connect' cały UI przestaje odpowiadać do momentu połączenia z Dystrybutorem. Nie można anulować akcji łączenia, trzeba czekać 30 sekund żeby komunikat o niemożności zlokalizowania serwera został wyświetlony itp.

Rozwiązanie problemu "wiszącego" dialogu musi spełniać następujące warunki:

asynchroniczna operacja w prosty sposób musi zwrócić dane do głównego okna programu
przerwanie operacji połączenia powinno być możliwe w każdym momencie,
na czas wykonywania operacji połączenia z serwerem, UI powinno być dalej gotowe na interakcję z użytkownikiem,
w czasie ustanawiania połączenia z Dystrybutorem, UI powinno wyświetlać prostą animację sugerującą, że akcja łącznia trwa,
operacja połączenia w prosty sposób musi przekazać informację o ewentualnym błędzie,

AsyncDialog - najprościej wyjaśnić na przykładzie

W ramach testów różnych rozwiązań zaimplemntowałem przykładową aplikację AsyncDialog (źródła dostępne są tutaj). AsyncDialog pobiera informacje o wersji buildu SQL Servera i wyświetla je w głównym oknie.

W oknie ConnectDialog użytkownik moze pobierać informacje o SQL Serverze za pomocą czterech mechanizmów.

Dispatcher On Complete -wykorzystuje Dispatcher'a i właściwości klasy DispatcherOperation.
Simple Dispatcher - prezentuje najprostsze wywołanie Dispatcher'a.
Background worker - używa klasy BackgroundWorker, która umożliwia uruchomienie animacji w czasie połączenia
Thread Pool - do wykonania asynchronicznej operacji wykorzystuje metodę
ThreadPool.QueueUserWorkItem.

Poniżej klasy pomocnicze wykorzystywane przez AsyncDialog do pobrania danych z instacji MS SQL Servera.

public class SqlServerMetaMan
{
    private readonly string _serverName;

    public SqlServerMetaMan(string serverName)
    {
        _serverName = serverName;
    }

    public ServerInfo GetSqlServerVersion()
    {
        var connectionStringBuilder = new SqlConnectionStringBuilder();
        connectionStringBuilder.InitialCatalog = "master";
        connectionStringBuilder.DataSource = _serverName;
        connectionStringBuilder.IntegratedSecurity = true;
        using(var connection = new SqlConnection(connectionStringBuilder.ConnectionString))
        {
            connection.Open();
            return new ServerInfo{Name = connection.DataSource
              , Version = connection.ServerVersion};
        }
    }
}

public class ServerInfo
{
    public string Name { get; set; }
    public string Version { get; set; }
}

Poniżej przykładowa animacja obrazka przedstawiającego ster, która wykonuje obrót obrazka o 360 stopni. Kod źródłowy był inspirowany artykułem 'Beginner's WPF Animation Tutorial'. Animacja jest uruchamiana przed nawiązaniem połączenia do serwera i jest zatrzymywana po otrzymaniu danych lub anulowaniu akcji.

private void StartAnimation()
{
    TimeSpan animationDuration = TimeSpan.FromSeconds(5);
    DoubleAnimation animation = new DoubleAnimation(360, 0, new Duration(animationDuration));
    RotateTransform rotateTransform = new RotateTransform();
    progressIcon.RenderTransform = rotateTransform;
    progressIcon.RenderTransformOrigin = new Point(0.5, 0.5);
    animation.RepeatBehavior = RepeatBehavior.Forever;
    rotateTransform.BeginAnimation(RotateTransform.AngleProperty, animation);
}

Asynchronicznie do dzieła

Istnieje co najmniej kilka opcji do uruchamiania operacji asynchronicznych na WPF. Jako że nie miałem z nimi żadnego szczególnego doświadczenia, zacząłem od Dispatcher'a, który sprawiał wrażenie najprostszego w implementacji. Jest to klasa, która jest bazową dla praktycznie wszystkich obiektów wizulanych WPF'a, aczkolwiek instacja Dispatcher'a jest tylko jedna (singleton). Z braku podstawowej wiedzy o WPF'ie oczekiwałem, że jakikolwiek kod uruchomiony za pomocą Dispatcher'a uruchomi się na oddzielnym wątku. Tak oczywiście nie jest, ponieważ delegaty przekazywane do metod Invoke i BeginInvoke są kolejkowane i uruchamiane w kolejności zgodnej z podanym priorytetem przez jeden-jedyny wątek UI (architektura WPF jest też oparta na STA czy Single-Threaded Apartment, tak samo jak Win32 i Windows Forms). Poniżej przykładowy kod wywołania metody Dispatcher.BeginInvoke.

private void CallUsingDispatcher()
{
    Dispatcher.BeginInvoke(
        new Action(DispatcherDisplayServerInfo),
        DispatcherPriority.Normal);
}

private void DispatcherDisplayServerInfo()
{
    ServerInfo serverInfo = GetSqlServerVersion(tbServerName.Text);
    OwnerWindow.DataContext = serverInfo;
    this.Close();
}

W momencie wywołania metody GetSqlServerVersion i próby połączenia do SQL Servera całe UI "zastygnie" w oczekiwaniu na ustanowienie komunikacji z serwerem. Jest to oczywiście zachowanie niepożądane i dlatego w moim senariuszu Dispatcher nie może być brany pod uwagę.

Niespełnione warunki:

nie można anulować operacji w czasie jej wykonywania,
UI przestaje odpowiadać na czas trwania operacji połączenia,
nie można obsłużyć animacji w czasie wykonania operacji.

Elastyczny BackgroundWorker

Nie tracąc nadziei sprawdziłem następną klasę o nazwie BackgroundWorker. Umożliwia ona asynchroniczne uruchamianie operacji na odzielnym wątku, anulowanie akcji (właściwość WorkerSupportsCancellation), przekazanie informacji o błędzie oraz przekazywanie informacji o postępie prac. Aczkolwiek, nie wszystko złoto co się świeci, interakcję z WPF'owym UI możemy uzyskać poprzez obiekt wyżej wspomnianego
Dispatcher'a. Inaczej otrzymamy następujący komunikat:

InvalidOperationException : The calling thread cannot access this object because a different thread owns it.

Poniżej fragmenty implementacji scenariusza wykorzystującego klasę BackgroundWorker'a.

private void CallUsingBackgroundWorker()
{
    worker = new BackgroundWorker();
    worker.WorkerSupportsCancellation = true;
    worker.DoWork += WorkerDoWork;
    worker.RunWorkerCompleted += WorkerRunCompleted;
    worker.RunWorkerAsync(tbServerName.Text);
}
        
private void WorkerDoWork(object sender, DoWorkEventArgs e)
{
    string serverName = (string) e.Argument;
    BackgroundWorker backgroundWorker = (BackgroundWorker) sender;
    try
    {
        ServerInfo serverInfo = GetSqlServerVersion(serverName);
        e.Result = serverInfo;
        Dispatcher.BeginInvoke(new Action(() =>
            {
                OwnerWindow.Title += "Background Worker update";
            }), DispatcherPriority.Normal
            );

                
    }
    catch (Exception)
    {
        if (backgroundWorker.CancellationPending)
        {
            //Suppress exception if user submitted cancellation
            e.Cancel = true;
        }
        else
        {
            throw;    
        }
                
    }
}

private void WorkerRunCompleted(object sender, RunWorkerCompletedEventArgs e)
{
    StopAnimation();
    if(e.Error != null && !e.Cancelled)
    {
        MessageBox.Show(e.Error.Message, "Error occured");
    }
    else if(e.Cancelled)
    {
        MessageBox.Show("Connection attempt cancelled by the user", "User action");
    }
    else if (e.Result != null)
    {
        OwnerWindow.DataContext = e.Result as ServerInfo;
        this.Close();
    }
}

ThreadPool do pomocy

Z czystej ciekawości postanowiłem sprawdzić standardowe klasy wykorzystywane w .NET-towych aplikacjach wielowątkowych. Oczywiście, stara dobra, metdoa ThreadPool.QueueUserWorkItem spisała się dobrze. Nie zablokowała wątku UI, pozwoliła przekazać parametr z UI (nazwę serwera), aczkolwiek z przekazywaniem informacji o błędach było już gorzej.

private void CallUsingThreadPool()
{
    ThreadPool.QueueUserWorkItem(UserWorkItemCallback, 
        tbServerName.Text);
}

private void UserWorkItemCallback(object state)
{
    string serverName = (string) state;
    ServerInfo serverInfo = GetSqlServerVersion(serverName);

    Dispatcher.BeginInvoke(new Action(() =>
    {
        this.StopAnimation();
        OwnerWindow.Title += "UserWorkItem Callback update";
        OwnerWindow.DataContext = serverInfo;
        this.Close();
    }), DispatcherPriority.Normal);
}

Niespełnione warunki:

nie można w prosty sposób anulować operacji
nie można przekazać informacji o błędach które wystąpiły podczas wykonania operacji połączenia

And the winner is

Rozwiązanie, które wybrałem do implementacji dialogu połącznia opiera się na wykorzystaniu klasy BackgroundWorker. Dostarcza ona proste mechanizmy do obsługi przerywania akcji, przekazywania błędów i wyników do interfejsu użytkownika.

Hope this helps.

Programista i jego Troubleshooting Toolkit (Część II) - .NET

2011-07-27T22:25:00.002+02:00

Rozwiązywanie problemów na platformie .NET

W kolejnym poście skupię się na temacie rozwiązywania problemów na platformie .NET z którymi borykają się programiści. Jest to zagadnienie bliskie memu sercu, ponieważ jako etatowy "detektyw .NET" wielokrotnie byłem zmuszony do korzystania z większości z tych narzędzi, szczególnie gdy zawiodło mnie bezmyślne wyszukanie w Google.

support.microsoft.com - powrót do korzeni

http://support.microsoft.com/ - postanowiłem zacząć od tej mało popularnej wśród programistów strony, na której Microsoft publikuje poprawki, artykuły techniczne oraz wszelakie rozwiązania problemów. Ta strona może być o tyle istotna w procesie poszukiwania rozwiązania, że support.microsoft.com zawiera rozwiązania i informacje które zostały już wielokrotnie sprawdzone przez inżynierów Microsoft w akcji.

Artykuły w Microsoft'owym KB są wielokrotnie zatwierdzane i sprawdzane zanim ujrzą światło dzienne, tym zasadniczo różnią się od blogów, artykułów i wypowiedzi na forach etc. W moim odczuciu wyszukiwarki nie zawsze pozycjonują wysoko strony z rozwiązaniami z support.microsoft.com, dlatego zawsze gdy rozwiązanie nie jest oczywiste warto sprawdzić to u ŹRÓDŁA. Można też pójść w kierunku bardziej ortodoksyjnym i założyć konto na kbalertz.com. Usługa ta umożliwia otrzymywanie powiadomień o świeżo opublikowanych artykułach dla technologii, które wybierzemy w swoim profilu (np. .NET Framework, SQL Server 2008 R2 etc).

Fusion Log Viewer - assembly binding

Fusion Log Viewer (FUSLOGVW) - jest częścią Windows SDK i jest to bardzo użyteczne narzędzie gdy nie jesteśmy w stanie ustalić jakich assembly program nie może właściwie załadować i skąd je próbuje pobrać. Domyślnie Fusion Log Viewer loguje nieudane ładowania assembly. Aczkolwiek po zmianach w rejestrze poprzez dodanie HKLM\Software\Microsoft\Fusion\ForceLog i ustawieniu wartości na 1, otrzymamy pełny log udanych i nieudanych tzw. assembly bindings.

Po zmianach w rejestrze możemy śledzić próby załadowania assembly przez aplikacje uruchamiane na .NET CLR. Poniżej prezentuję prostą aplikację, która próbuje wczytać assembly o nieistniejącej nazwie.

using System.Reflection;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            AssemblyName assemblyName = new AssemblyName();
            assemblyName.Name = "FakeAssemblyName";
            Assembly loadedAssembly = Assembly.Load(assemblyName);
        }
    }
}

Log Fusion viewer wyświetli nieudaną próbę w następujący sposób. Można przejrzeć plik logu dla wiersza oznaczonego FakeAssemblyName (patrz poniżej).

Tesktowy log dokładnie prezentuje, w jakich katalogach assembly resolver poszukuje nieszczęsnego FakeAssemblyName.dll.

*** Assembly Binder Log Entry  (2011-07-25 @ 19:23:19) ***

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable  c:\users\...\ConsoleApplication1\ConsoleApplication1\bin\Debug\ConsoleApplication1.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = MaxPC\Max
LOG: DisplayName = FakeAssemblyName
 (Partial)
WRN: Partial binding information was supplied for an assembly:
WRN: Assembly Name: FakeAssemblyName | Domain ID: 1
WRN: A partial bind occurs when only part of the assembly display name is provided.
WRN: This might result in the binder loading an incorrect assembly.
WRN: It is recommended to provide a fully specified textual identity for the assembly,
WRN: that consists of the simple name, version, culture, and public key token.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
LOG: Appbase = file:///c:/users/.../ConsoleApplication1/ConsoleApplication1/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = ConsoleApplication1.exe
Calling assembly : ConsoleApplication1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///c:/users/.../ConsoleApplication1/ConsoleApplication1/bin/Debug/FakeAssemblyName.DLL.
LOG: Attempting download of new URL file:///c:/users/.../ConsoleApplication1/ConsoleApplication1/bin/Debug/FakeAssemblyName/FakeAssemblyName.DLL.
LOG: Attempting download of new URL file:///c:/users/.../ConsoleApplication1/ConsoleApplication1/bin/Debug/FakeAssemblyName.EXE.
LOG: Attempting download of new URL file:///c:/users/.../ConsoleApplication1/ConsoleApplication1/bin/Debug/FakeAssemblyName/FakeAssemblyName.EXE.
LOG: All probing URLs attempted and failed.

Jak widać Log Fusion Viewer to ciekawe narzędzie, które może pomóc w rozwikłaniu skomplikowanych problemów z ładowaniem assembly.

IL Diassembler - metadata

IL Diassembler ( ILDASM) - jest to program dystrybuowany razem z Windows SDK lub z Visual Studio. Umożliwia on zapisanie lub przeglądanie kodu IL (Intermediate Language) dla danego assembly (dll lub exe). Częściowo jego funkcjonalność pokrywa się z ILSpy'em o którym piszę poniżej, jego przewagą w pracy z IL'em może być interfejs konsolowy oraz bardziej wyrafinowany sposób eksportu IL'a. Opcją którą zdarzyło mi się używać było przeglądanie Manifestu assembly, który zawiera m.in referencje do innych assembly, klucz publiczny, ustawienia corflags dotyczące architektury procesora który może wykonywać daną aplikację (w Visual Studio możemy ustawić podczas kompilacji x64, x86, any CPU).

Lista referencji do zewnętrznych assembly z ich tokenami klucza publicznego.

ILSpy - dekompilacja

ILSpy - to darmowy odpowiednik .NET Reflector'a. Jest on oczywiście bardziej wyrafinowanym dekompilatorem niż IL Diassembler. Niestety nie ma takiej ilości pluginów jak .NET Reflector, jest też trochę wolniejszy od swojego płatnego odpowiednika, nie integruje się z Visual Studio i nie daje możliwości debuggowania dekompilowanego assembly. Aczkolwiek parafrazując staropolskie przysłowie, darowanemu programowi się w pluginy nie zagląda. Dekompilatory dobrze wpisują się w scenariusz gdy musimy rozwijać system napisany przez zewnętrznego dostawcę (np. SharePoint, Microsoft CRM), ale nie mamy dostępu do kodu źródłowego. Mamy szczęście w momencie gdy dostawca nie użył obfuskatora, gdyż wtedy żaden dekompilator nam nie pomoże. ILSpy umożliwia konwersję kodu CIL (Common Intermediate Language) do kodu C#, pozwala także podejrzeć kod IL.

Inną sytuacją kiedy ILSpy może okazać się przydatny jest weryfikacja, czy kod źródłowy, który mamy w systemie kontroli wersji zgadza się z kodem assembly, które wykonuje się na danym środowisku serwerowym. Niejednokrotnie musiałem dekompilować assembly na jakimś serwerze, aby tylko sprawdzić czy przypadkiem ktoś nie wrzucił starej/swojej/nowszej wersji danego assembly. W końcu, ILSpy daje nam takie możliwość weryfikacji kodu źródłowego, więc dlaczego z tego nie skorzystać. Alternatywą dla ILSpy'a może być JustDecompile, aczkolwiek ostrzegam, ostatnia beta którą uruchomiłem, rzuciła przy starcie pięknym czerwono-białym wyjątkiem i na tym się skończyło.

Możliwość załadowania i dekompilacji assembly bezpośrednio z GAC'a.

.NET Memory Profiler - CPU i pamięć

MemProfiler - staram się opisywać narzędzia, które są darmowe i ogólnodostępne, aczkolwiek dla MemProfiler'a postanowiłem zrobić wyjątek. Jest to rozbudowany profiler dla aplikacji opartych o platformę .NET. Muszę się przyznać, że przynajmniej w dwóch przypadkach wycieków pamięci udało mi się namierzyć problematyczny kod źródłowy tylko dzięki błyskotliwości tego narzędzia. MemProfiler pozwala wykonywać snapshot'y pamięci i później analizować różnice w ilości obiektów zaalokowanych na stercie, instancje obiektów na których nie została wywołana metoda Dispose (Dispose Tracker) itd. Ogólnie polecam zapoznanie się z tym narzędziem, jeżeli zgłosi się do was szef, że proces na serwerze produkcyjnym zajmuje teraz 2GB, a przed releasem zajmował 300 MB ;).

Diagram pokazujący ilość zaalokowanej pamięci na stercie .NET i pamięci niezarządzanej (unmanaged memory).

Na koniec - zestaw hardkorowca czyli Hang, Crash, Dump

Czasami jest tak, że trzeba wykazać się niestandardowym myśleniem. Szczególnie gdy wszystkie znane metody zawiodły. Przykłady takich przypadków to:

Niespodziewane crush procesu, usługi czy IIS'a (np. w3wp.exe)
Wieszanie się procesów
Losowe OutOfMemoryException

W takich momentach należy użyć trochę bardziej wyrafinowanych narzędzi, część z nich wchodzi w skład pakietu Debugging Tools for Windows. Możemy rozpocząć z Debug Diagnostic Tool v1.1 i spróbować przeanalizować działanie naszej aplikacji pod kątem jednego z kilku możliwych problemów (Crash, Memory Leak lub IIS Hang). W końcu dostępna już jest wersja tego narzędzia dla systemów 64 bitowych. Jeżeli nasza analiza nie przyniesie oczekiwanych rezultatów, proponuje pójść ścieżką dokładnie opisaną przez Tess Ferrandez w swojej serii postów .NET Debugging Demos.

Podstawa to WinDbg (dostępny w ramach Debugging Tools for Windows)
Adplus - skrypt napisany w vbscript (dostępny w ramach Debugging Tools for Windows), przydatny przy generowania różnego rodzajów zrzutów pamięci (memory dump) dla danego procesu.
SOS (Sun of strike) - rozszerzenie do debuggowania .NET-towych aplikacji, dla .NET 4 dostępny w %systemDirve%\Microsoft.NET\Framework\v4.0.30319\SOS.dll

Poza tym, lekcje debuggowania u Tess Fernandez to sama przyjemność i satysfakcja z dłubania na poziomie adresów w pamięci. Polecam.

Kilka linków do aplikacji uzupełniających tą listę

Visual Studio Performance Tools - niestety nie wszyscy mogą sobie pozwolić na Visual Studio 2010 Premium lub Ultimate, aczkolwiek na pewno warto przyjrzeć się tym narzędziom.
Performance Analysis of Logs (PAL) Tool - zainstaluj PAL'a i wymagane dodatkowe oprogramowanie (np. Chart Controls), zmień ustawienia regionalne na United States i bez szczegółowej wiedzy na temat performance counterów zbieraj informacje na temat np. aplikacji ASP.NET lub SQL Server'a i wielu innych produktów Microsoft'u. Na stronie projektu możemy znaleźć kilka przydatnych how-to.
CLR Profiler - profiler Microsoft'u, trudniejszy w obsłudze niż MemProfiler czy inne komercyjne profilery YourKit .NET Profiler czy Ants .NET Profiler, aczkolwiek ma jedną niezaprzeczalną zaletę, jest darmowy.

Hope this helps.

Nie ignoruj bluescreen'a

2011-07-22T19:37:00.004+02:00

Analiza crush dump'a - podstway

Niedawno obejrzałem dosyć stary już webcast Windows Hang and Crash Dump Analysis, w którym Mark Russinovich (człowiek od Sysinternals Suite) udowodnił mi, że nie trzeba być geniuszem, żeby wykonać analizę crush dump'a (bluescreen przeważnie produkuje memory dumpa). Czytelników spragnionych szczegółów i dokładniejszych wyjaśnień odsyłam do obejrzenia w całości tego ciekawego webcast'u.

Bluescreen - zdarzy się, ale kto by się przejmował

Na szczęście na codzień w pracy nie muszę zajmować się środowiskiem serwerowym, zatem większość bluescreen'ów otrzymałem na moich stacjach roboczych (w pracy, w domu). Czasami efektem bluescreen'u może być niespodziewany restart. Niestety nigdy nie wpadłem na pomysł, żeby przeprowadzić bardziej wnikliwą analizę tego zjawiska. Podczas crash'u memory dump najpierw zapisywany jest do page file'a, a później generowany jest memory dump (mini-dumpy są zawsze generowany z datą w nazwie pliku, u mnie lądują w folderze C:\Windows\Minidump\ ). W Windows 7 Microsoft zostawił tylko możliwość generowania zrzutów Kernel-memory lub Small memory dump, w sumie zrzut 8GB pamięci na dysk trochę by musiał trwać i wymagałby dodatkowego miejsca na dysku. (Aby dostać się do ustawień rodzaju zrzutu pamięci wybierz prawym Computer później Properties -> Advanced System settings -> Zakładka Advanced ->Wybierz dla Startup and Recovery przycisk Settings. ).

Jeżeli mamy do dyspozycji Wirtualną Maszynę to można sobie wygenerować bluescreena narzędziem NotMyFault (autor oczywiście Mark Russinovich). Na własne ryzyko, zabawa uszkodzonym driverem zawsze wiąże się z możliwością uszkodzenia np. danych. Przykład wygenerowania bluescreena na Windows Server 2008 R2 zamieszczam poniżej na potrzeby demo. Widać że na załączonym obrazku, że system jeszcze generuje crash-dumpa dla kernel-memory (zajmuję to trochę czasu bo to nie jest mini-dump i 256kb).

Jeżeli nie zdąrzyliśmy zarejestrować nazwy problematycznego drivera z bluescreen'a (jeżeli jest dostępny w używanej przez nas wersji Windows) to polecam sciągnięcie Debugging Tools for Windows i odpalenie WinDbg. Zanim zaczenie się analizę memory dump'a warto ustawić ścieżkę do Microsoft Symbols Server aby pobrać pliki symboli pdb dla systemu Windows. Jeżeli lokalnie będziemy składować pliki w katalogu c:\symbols to dialog File->Symbol File Path (Ctrl+S) powinien wyglądać następująco.

SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

Po uporaniu się z symbolami, możemy załadować memory dump'a (lub mini-dump'a) i "zabrać się" do analizy.

Po załadowaniu pliku i uruchomienieniu w WinDbg poniżeszj komendy powoduje dostarczenie bardziej dokładnych informacji o driverze który spowodował całe zamieszanie.

!analyze -v

Na powyższym obrazku widać problematyczny driver o nazwie myfault.sys. Można oczywiście uniknąć uruchamiania WinDbg i skorzystać ze strony Instant Online Crash Analysis i wrzucić swój mini-dump do analizy tego narzędzia.

Po zlokalizowaniu drivera (myfault.sys) trzeba niestety użyć Google'a aby wybadać co z tym fantem zrobić i określić przez które oprogramowanie z naszego systemu jest używany (u mnie kiedyś szwankował 3rd party firewall).