Zamieszczam więc niniejszym skromny instruktarz, który być może kogoś zainspiruje, do kodu kontrolki obecnie dostępu nie posiadam, przedstawię więc bardziej ideę jako propozycje alternatywy dla typowego myślenia o edycji właściwości naszych obiektów.

1. Co to jest refleksja?

Dla tych co wiedzą – przypomnienie (bądź akapit do przeskrolowania), dla pozostałych – kilka podstawowych informacji.

Refleksja to mechanizm pozwalający na pozyskiwanie informacji o klasach, czy kodzie skompilowanych już klas (na przykład właśnie wykonywanego programu, czy też odczytanych przez niego binarek).

W celu użycia refleksji w projekcie .NETowym należy użyć przestrzeń nazw System.Reflection. Dzięki temu będziemy mieli dostęp do podstawowych klas refleksji czyli: Type, MethodInfo, ProprtyInfo, EventInfo, FieldInfo, ConstructorInfo… Każda odpowiada jednemu z elementów tworzących klasy.

Żeby pobrać informacje dotyczące obiektu danej klasy wywołać należy na nim metodę .GetType() dziedziczoną z bazowej klasy Object.

2. Skąd wiemy co wyświetlać?

Metod na pozyskanie interesującej nas informacji jest co najmniej kilka. Możemy pozyskać informacje o klasie wczytując plik binarny i w nim szukając, możemy szukać po nazwie klasy i jej przestrzeni nazw, ale zdecydowanie najłatwiejszym sposobem jest wywołanie wspomnianej powyżej metody GetType() na obiekcie, który nas interesuje.

Co wyświetlać? O tym decydujemy już wyłącznie my! Powinniśmy jednak coś założyć, w tym przykładzie wyświetlać chciałbym wszystkie publiczne Property obiektów.

Skoro już wiemy jak pobrać typ obiektu oraz wiemy co będziemy wyświetlać pozostaje wyłącznie pobrać listę, nie jest to nic trudnego, wystarczy wywołać metodę GetProperties() klasy Type, która zwraca tablicę obiektów PropertyInfo danego typu. Stworzymy więc taki kod:

var type = ob.GetType();
var properties = type.GetProperties();

kod ten nie spełnia jednak naszego założenia, bowiem zwrócone zostaną wszystkie publiczne properties (domyślne działanie nie zwraca prywatnych właściwości!) łącznie z tymi statycznymi (chcemy tylko właściwości obiektu). W celu pozyskania odpowiedniej listy użyć należy przeładowania metody GetProperties wraz z argumentem w postaci wartości enuma BindingFlags (dopuszczając bitowe dodawanie wielu wartości)

var type = ob.GetType();
var properties = type.GetProperties(BindingFlags.Public | BindingFlags.Instance);

Lista gotowa!

3. A co jeżeli jakiegoś pola NIE chcę wyświetlać?

Nie, nie trzeba w takim przypadku robić dziwnych warunków czy aby dane property jest jednym z wykluczonych, czy nie, dużo bardziej uniwersalnym sposobem jest użycie atrybutu. Można działać w 2 strony – stworzyć atrybut informujący o tym, że dane pole powinno być wyświetlane, bądź atrybut informujący o tym, że jego edycja nie jest potrzebna. Pokażę drugie rozwiązanie, jako bardziej ogólne i bardziej do mnie przemawiające, poza tym pozwalające w dalszej drodze edytować wartości obiektów nie należących do danego projektu.

Najpierw klasa atrybutu:

public class HiddenValueAttribute : Attribute
{
}

Po czym umieszczamy atrybut przy Property, którego nie chcemy widzieć:

[HiddenValue]
public string HiddenName { get set }

a teraz modyfikacja naszej metody pobierającej listę do wyświetlenia (dodajemy również jej nazwę):

public IEnumerable<PropertyInfo> GetPropertiesToDisplay(object ob)

{
var type = ob.GetType();
var properties = type.GetProperties(BindingFlags.Public | BindingFlags.Instance);
var returnValue = from PropertyInfo p in properties where p.GetCustomAttributes(typeof(HiddenValueAttribute), true).Length == 0 select p;
}

Jak widać dodana została linijka wyszukująca tylko te PropertyInfo, które wśród swoich atrybutów nie mają tego o typie HiddenValueAttribute, w celu tym użyta zostało użyte zapytanie LINQ wywołujące metodę GetCustomAttributes, która zwraca tablicę atrybutów spełniających warunki. Warunki podawane w argumentach to typ atrybutu (opcjonalny parametr, w drugim przeładowaniu metody nie występuje) oraz czy brać pod uwagę dziedziczone atrybuty.

4. Jak wyświetlać?

Przechodzimy teraz do najistotniejszego punktu – wyświetlanie. Założymy, że wyświetlamy kontrolki na obiekcie klasy Panel o nazwie… panel!

Metoda wyświetlająca kosztować będzie nas najwięcej pracy – tutaj generalnie przewidzieć będziemy musieli wszystkie potencjalnie wyświetlane typy oraz obsługę każdego z nich.

Ale powoli.

Zacznijmy od organizacji naszego panelu, proponuję wyświetlać wartości w wierszach, w każdym etykieta z nazwą i odpowiednia kontrolka dla wartości – taka para dla każdej Property naszego obiektu. Czyli na przykład:

private void CreateControlsForProps(IEnumerable<PropertyInfo> properties, object ob)
{
foreach (var prop in properties)
{
Panel row = new Panel();
row.Dock = DockStyle.Top;
row.Height = 36;

this.panel.Controls.Add(row);
row.Controls.Add(this.GetLabelForProperty(prop));

if (prop.PropertyType == typeof(String))
{
row.Controls.Add(this.GetInputForString(prop));
}
else if (prop.PropertyType == typeof(Int32))
{
row.Controls.Add(this.GetInputForNumber(prop));
}
else if (prop.PropertyType == typeof(Color))
{
row.Controls.Add(this.GetInputForColor(prop));
}
else if (prop.PropertyType.IsEnum)
{
row.Controls.Add(this.GetInputForEnum(prop));
}
else
{
row.Controls.Add(new Label()
{
Text = „Niestety, typu „ + prop.PropertyType.Name + ” jeszcze nie obsługujemy.”,
Left = row.Controls[0].Right + 15,
AutoSize = true,
Anchor = Anchor | AnchorStyles.Right
});
}
}
}

Tak przygotowany kod wystarczy „tylko” uzupełnić o metody tworzące odpowiednie kontrolki dla wprowadzania wartości i etykiety. Podam przykład dla klasy String, dla pozostałych typów odsyłam to pokładów własnej inwencji (nie jest to nic trudnego!):

private Control GetInputForString(PropertyInfo prop)
{
TextBox tb = new TextBox();tb.Left = 75;
tb.Anchor = tb.Anchor | AnchorStyles.Right;
return tb;
}

i dla etykiet:

private Control GetLabelForProperty(PropertyInfo prop)
{
Label l = new Label();
l.Text = prop.Name;
return l;
}

5. A co z wartościami?!

Bardzo dobre pytanie… jak widać… nic. Ale przecież nie po to tworzymy naszą kontrolkę do wyświetlania wartości, żeby wartości nie wyświetlać…

Dlatego konieczna będzie mała modyfikacja powyższego kodu. Zacznijmy od podstaw – jak w ogóle pobrać wartość Property obiektu, którego typu nie znamy z początku, zresztą sami przecież nie wiemy co to za Property (więc rzutowanie, czy wpisywanie nazwy Property po kropce nie jest możliwe)? Nic trudnego, w naszym kodzie mamy już obiekt opisujący Property, potrzebujemy jeszcze obiekt typu, którego dane Property dotyczy – a potem już tylko wywołanie metody GetValue:

prop.GetValue(ob, null);

W naszym kodzie więc potrzebujemy obiektu, którego wartość chcemy pobierać, modyfikacje będą więc następujące:

Metoda tworząca kontrolkę do edycji/wyświetlania wartości:

private Control GetInputForString(PropertyInfo prop, object ob)
{
TextBox tb = new TextBox();
tb.Text = (String)prop.GetValue(ob, null);tb.Left = 75;
tb.Anchor = tb.Anchor | AnchorStyles.Right;
return tb;
}

I co za tym idzie uzupełnienie wywołań w głównej pętli wyświetlającej nasze wartości:

row.Controls.Add(this.GetInputForString(prop, ob));

i podobnie dla wszystkich pozostałych metod dotyczących Property.

6. Ale opis jest brzydki…

Fakt, opisy w tym momencie stanowią nazwy pól w klasie – brak spacji, często niewłaściwy język i skrótowe nazwy niewiele mówią potencjalnemu użytkownikowi. Tutaj z pomocą znowu przyjść nam mogą atrybuty.

Zacznijmy więc od zadeklarowania odpowiedniego (powinien zawierać przeładowany konstruktor oraz musi zawierać Property dla wyświetlanej wartości):

public class VisualDisplayAttribute : Attribute
{
public string VisualDisplay { get; set; }

public VisualDisplayAttribute(string VisualDisplay)
: base()
{
this.VisualDisplay = VisualDisplay;
}
}

Następnie niewygodne Property „ozdabiamy” takim atrybutem:

[VisualDisplay("Tło")]
public Color Background { get; set; }

I modyfikujemy tworzenie etykiety:

private Control GetLabelForProperty(PropertyInfo prop)
{
Label l = new Label();
var attributes = prop.GetCustomAttributes(typeof(VisualDisplayAttribute), true);
if (attributes.Length > 0)
{
l.Text = ((VisualDisplayAttribute)attributes[0]).VisualDisplay;
}
else
{
l.Text = prop.Name;
}
return l;
}

7. Czy można zrobić pola tylko do odczytu? Albo obowiązkowe?

Jak najbardziej – proponowane rozwiązanie to odpowiedni zestaw atrybutów. Np. nowy atrybut ReadOnlyValueAttribute, którego posiadanie przez Property badamy w identyczny sposób jak dla wcześniejszych przykładów i w przypadku znalezienia ustawiamy np. wartość enabled tworzonej kontrolki na false.

Dzięki odpowiedniemu zestawowi atrybutów możemy praktycznie dowolnie sterować całą naszą kontrolką – od możliwości edycji danej wartości, po kolor tła kontrolki, czy jej kontenera – granicą jest chyba tylko nasza wyobraźnia. Faktem jest, że pewne rzeczy dużo łatwiej było by zaprojektować w „tradycyjny” sposób, ustawiając kontrolki w designerze, niż odczytywać wartości z atrybutów pól klasy, po czym przeliczać je na wartości, które „ręcznie” trzeba ustawić w kontrolkach, granicę opłacalności wyznaczyć musimy sobie sami.

8. Zaraz, zaraz… miała być edycja!

I nikt o niej nie zapomniał. Jak łatwo zauważyć – wartości co prawda odczytujemy… ale ich już nie zmieniamy… metod jest kilka, ale wszystkie wymagają jednego – zapamiętania lub pozyskania obiektu PropertyInfo oraz obiektu, który wyświetlamy / edytujemy. Kiedy już owe obiekty mamy, wystarczy nam… jak zwykle jedna linijka… a dokładniej wywołanie metody SetValue klasy PropertyInfo

Zmodyfikujmy raz jeszcze nasz kod – do pól Tag paneli przypiszemy odpowiednie informacje (dla obiektu panel naturalny będzie obiekt na panelu wyświetlany, dla panelu wiersza – PropertyInfo, którego wiersz dotyczy):

private void CreateControlsForProps(IEnumerable<PropertyInfo> properties, object ob)
{
this.panel.Tag = ob;
foreach (var prop in properties)
{
Panel row = new Panel();
row.Tag = prop;
…

Dodajmy obsługę zdarzenia zmiany wartości kontrolki edytującej Property, na przykład:

private Control GetInputForString(PropertyInfo prop, object ob)
{
TextBox tb = new TextBox();
tb.Text = (String)prop.GetValue(ob, null);
tb.Left = 75;
tb.TextChanged += new EventHandler(tb_TextChanged);
return tb;
}

void tb_TextChanged(object sender, EventArgs e)
{
TextBox tb = sender as TextBox;
PropertyInfo prop = tb.Parent.Tag as PropertyInfo;
object ob = tb.Parent.Parent.Tag;

prop.SetValue(ob, tb.Text, null);
}

Gotowe!

Zdaję sobie sprawę, że posługiwanie się polem Tag bywa mętne i trochę utrudnia analizę kodu następcom, ale zostało użyte raczej jako przykład niż wzór – osobiście proponowałbym np. podziedziczyć po panelu i stworzyć klasę panelu wiersza z odpowiednim, dedykowanym Property dla PropertyIfno itp. Takie rozwiązanie będzie dużo bardziej czytelne no i nikt nam wtedy wartości nie nadpisze, gdy stwierdzi, że fajnie by było dla niego przechować coś w Tagu

9.Przecież refleksja jest wolna!

Tak, refleksja działa wolniej niż pobierania i ustawianie wartości „normalnymi” odwołaniami do właściwości obiektów, jednak stworzenie i wyświetlenie jednej kontrolki zajmuje nieporównanie więcej czasu… więc nie stanowi to w tym przypadku żadnego argumentu, ani nie powinno nas to napełniać obawami.

10. Plus i minus, to jedyne co słyszę – czyli kiedy stosować?

Zdecydowanym plusem takiego rozwiązania jest jego elastyczność, można wyświetlić w ten sposób wszystko. Dosłownie. Wystarczy spojrzeć na Visualowe komponenty do edycji obiektów – PropertyGrid’y, które mają bardzo szerokie możliwości, a działają na dokładnie takiej samej zasadzie. Będzie to rozwiązanie szczególnie cenne, kiedy klasy wyświetlane zmieniają się co chwila, albo interfejs powstaje w celu edycji danych, których jeszcze nie znamy.

Kolejnym plusem jest modna „reusability”, jeżeli stworzymy dobrze taką kontrolkę oraz zestaw atrybutów użycie ich w kolejnym projekcie będzie dziecinnie proste – w końcu nie mamy żadnych odwołań do klas encji biznesowych, czy jakichkolwiek innych klas, które chcemy wyświetlać.

Oczywiście są i minusy…
M.in. dużo cięższe debugowanie wymuszone przez użytą refleksję.

Brak możliwości podejrzenia jak wygląda kontrolka w trybie design, jedyna możliwość to uruchomienie aplikacji na przykładowych danych.

Monotonność interfejsu i dużo trudniejsze modyfikacje wyglądu kontrolek pod konkretne Propery. Bez napracowania się nad atrybutami i ich interpretacją każde użycie kontrolki do wyświetlania danych wyglądać będzie identycznie.

Można zadać sobie pytanie po co tak się męczyć? przecież są wspomniane już PropertyGrid’y, są dobre do edycji danych Gridy. Ciężko temu argumentowi zaprzeczyć, to prawda. Tym niemniej tych gridów nie zmodyfikujemy, nie powiemy im co mają wyświetlać, a co nie w tak łatwy sposób itp. To rozwiązanie da nam pełną dowolność, której być może będziemy potrzebować.

Po pierwsze należy ściągnąć i zainstalować pakiet ADO.NET z http://sqlite.phxsoftware.com/ (lub skorzystać z innego ;))

Po drugie do projektu dodajemy referencję do System.Data.SQLite z pakietu ADO.NET (kopiujemy do katalogu System.Data.SQLite.dll)

Po trzecie dodajemy do projektu plik *.config (opis na http://msdn.microsoft.com/en-us/library/ms184658%28VS.80%29.aspx) oraz w pliku *.config wpisujemy:

Po czwarte należy wyposażyć się w jakiegoś managera bazy danych, polecam wtyczkę do przeglądarki firefox http://code.google.com/p/sqlite-manager/

Po piąte wyklikujemy prostą bazę danych

Po szóste – gotowe ; )

Teraz test naszej bazy:

      DbProviderFactory fact = DbProviderFactories.GetFactory("System.Data.SQLite");
      using (DbConnection cnn = fact.CreateConnection())
      {
        cnn.ConnectionString = "Data Source=test.db3";
        cnn.Open();
      }

Jeśli nie dostaliśmy żadnego błędu to cała konfiguracja przebiegła pomyślnie.

W aplikacji w sekcji odpowiedzialnej za przechowanie predefiniowanych zmiennych globalnych (jak np. nazwa bazy, string wyświetlany w górnej belce aplikacji etc.) ustawiam sobie zmienną, określającą, czy użytkownik jest zalogowany (domyślnie ustawioną na false) oraz metodę pozwalającą zmienić wartość tej zmiennej:

public class GlobalAppVariables
{
    /// Globalna zmienna, której wartość jest ustwaiona na 1, gdy użytkownik się zaloguje.
    static int _logged = 0;

    /// Dostęp/zmiana wartości globalnej zmiennej _logged
    public static int Logged
    {
      get
      {
        return _logged;
      }
      set
      {
        _logged = value;
      }
    }
}

Samo logowanie polega na wywołaniu metody, która połączy się z bazą, sprawdzi, czy dla podanych parametrów istnieje wpis i na tej podstawie zwróci wynik pozytywny/negatywny, co z kolei pozwoli mi ustawić wartość zmiennej _logged w następujący sposób:

private void button1_Click(object sender, EventArgs e)
{
    object result = Queries.StartSession(this.loginTxt.Text, this.PasswordTxt.Text);
   //Queries to osobna klasa, w której przechowywane są metody odpowiedzialne za operacje na bazie
    if (result != null)
    {
        this.Close(); //zamknięcie okna logowania
        GlobalAppVariables.Logged = 1; // w tej chwili wiem, że już mam zalogowanego użytkownika
    }
    else
    {
       //info o nieudanym logowaniu
    }
}

Jeśli już mam zalogowanego użytkownika, mogę odblokować domyślnie wyłączone opcje, lub zrobić coś innego.
Jeśli nie potrzebujesz wymyślnego systemu logowania skorzystaj z przedstawionego sposobu. Jest on wystarczający dla wielu nieskomplikowanych aplikacji. AVE!

public class ControlGenerator
{
    /// Prywatna zmienna typu Form1
    private Form1 pf;
   //...
}

Następnie, konstruktor klasy musi posiadać takie przypisanie zmienej pf, aby wskazywała ona na referencję instancji mojej Form1 (trochę to może zamieszane, więc kawałek kodu wyjaśni, co miałem na myśli):

public ControlGenerator(Form1 f1)
{
  pf = f1;
}

Tak właśnie wygląda konstruktor, o którym była mowa, a jak to wygląda ‘na żywo’ jest ukazane poniżej.

W formie głównej aplikacji (Form1) po kliknięciu w jeden z przycisków powinny wygenerować się kontrolki, inicjuję więc obiekt klasy ControlGenerator w następujący sposób:

private void button1_Click(object sender, EventArgs e)
{
    ControlGenerator generate = new ControlGenerator(this);
   // właśnie tu do konstruktora przekazuje referencję do Form1 za pomocą this
}

Skoro moje połączenie klasa – forma jest już aktywne, to pora napisać metodę generującą kontrolki. Do owej metody powinna być przekazana informacja jak wiele kontrolek utworzyć. W poniższym przykładzie ograniczę się do wygenerowania TextBoxów z Labelkami zawartymi w GroupBoxie (które mogą być oczywiście dodatkowo osadzone na jakimś panelu, czy czymkolwiek się chce).
Gotowa funkcja prezentuje się następująco:

    public void GenerateRegisterControls(int number, string text)
    {
      int[] textboxes = new int[number];
      string[] labels = { "Imię", "Nazwisko", "PESEL", "Ulica", "Numer budynku",
                              "Miasto", "Kod pocztowy", "Województwo", "Telefon" };
      int i = 0, move = 0;

      //tworzę GroupBoxa, do którego wrzucę tworzone kontrolki (opis metody w następnym listingu)
      GroupBox box = GenerateGroupBoxControl(text); 

      foreach (int element in textboxes)
      {
        TextBox textbox = new TextBox(); //tworzę nowego TextBoxa
        Label label = new Label(); //tworzę nowy Label
        //lokalizacja TextBoxa
        textbox.Location = new System.Drawing.Point(200, 70 + move);
        textbox.Name = "textbox" + i.ToString();
        textbox.Size = new System.Drawing.Size(360, 20 + move); //wymiary TextBoxa
        //Rozmiar czcionki w TextBoxie - funkcja nie zostanie przedstawiona
        //w tym wpisie
        textbox.Font = SetFontForElement(40, textbox.Font);
        textbox.TabIndex = i;
        textbox.Visible = true;
        //automatyczna zmiana rozmiarów TextBoxa przy zmianie rozmiaru okna
        textbox.Anchor = AnchorStyles.Left | AnchorStyles.Top | AnchorStyles.Right;
        textbox.BorderStyle = BorderStyle.FixedSingle; //styl ramki
        //lokalizacja Labela
        label.Location = new System.Drawing.Point(20, 80 + move);
        label.Name = "label" + i.ToString();
        //nazwa Labela wzięta z wcześniej utworzonej tablicy stringów
        label.Text = labels[i];
        label.Font = SetFontForElement(28, label.Font);
        label.Size = new System.Drawing.Size(160, 28);
        label.Visible = true;

        box.Controls.Add(textbox); //dodaję do GroupBoxa utworzone TextBoxy
        box.Controls.Add(label); //dodaję do GroupBoxa utworzone Labele

        i++;
        move += 50;
      }
      //dodaję GroupBoxa z kontrolkami do panelu w kontenerze Form1
      pf.splitContainer1.Panel2.Controls.Add(box);
    }

Jak widać funkcja nie jest specjalnie skomplikowana, a tablicę z nazwami labelek można by przekazać jako parametr – jednak nie ma potrzeby w tym wpisie rozmieniać się na drobne. Tworzenie TextBoxów i Labelek można by dodatkowo zostawić osobnym funkcjom wywołanym w GenerateRegisterControls, jak np. GenerateGroupBoxControl, która wygląda następująco:

    private GroupBox GenerateGroupBoxControl(string text)
    {
      GroupBox box = new GroupBox();

      box.Name = "GroupBoxRegister";
      box.Text = text;
      box.Location = new System.Drawing.Point(1, 9);
      box.Size = new System.Drawing.Size(pf.splitContainer1.Panel2.Width - 20, pf.splitContainer1.Panel2.Height - 20);
      box.Anchor = AnchorStyles.Left | AnchorStyles.Top | AnchorStyles.Right | AnchorStyles.Bottom;

      return box;
    }

Samo wygenerowanie kontrolek po kliknięciu w jeden z przycisków wygląda następująco:

    private void button1_Click(object sender, EventArgs e)
    {
      ControlGenerator generate = new ControlGenerator(this);
      //9 TextBoxów i 9 Labelek, GroupBox będzie opatrzony tekstem Rejestracja
      generate.GenerateRegisterControls(9, "Rejestracja");
    }

Efekt:

Jeśli ktoś dopiero zaczyna swoją przygodę z C#, to informacje, które przedstawiłem z pewnością się przydadzą, albo przynajmniej wskażą drogę poszukiwań w google. AVE!

Ułatwiłoby to logowanie wszystkiego, co zachodzi w aplikacji. Wywołując metodę:

public void CountPrice(int bar, string baz)
{

}

chciałbym otrzymać w logach wpis:

Method’s Foo arguments >> bar: 1, baz: zzz

Najpierw spróbowałem za pomocą metody GetParameters klasy MethodInfo. Zwrócone obiekty typu ParameterInfo zawierają jednak tylko informacje o typach parametrów – nie mają wartości tych parametrów w czasie wykonywania kodu.

Moim celem było stworzenie metody, którą mógłbym użyć do pobrania sformatowanej informacji o parametrach metody – na przykład w celu zalogowania ich. Załóżmy dla prostoty testowania, że nasza metoda Foo będzie zwracała sformatowany napis z jej parametrami i ich wartościami.

Pierwsza wersja:

public class TestClass
{
  public static string Foo(int bar, string baz)
  {
    return LogingHelpers.GetMethodArguments();
  }
}

public class LoggingHelpers
{
  public static string GetMethodArguments()
  {
    //TODO tutaj magia :-)
    return "";
  }
}

Niestety – z taką składnią nie udało mi się. Z kontekstu LoggingHelpers.GetMethodArguments nie da się (lub nadal nie potrafię :-) ) dostać się do parametrów metody wywołującej. Działająca składnia jest nieco inna i odrobinę mniej wygodna:

public class TestClass
{
  public static string Foo(int bar, string baz)
  {
    return GetMethodArguments(() => bar, () => baz);
  }

  public static string NoParameters()
  {
    return GetMethodArguments();
  }
}

public class LoggingHelpers
{
  public static string GetMethodArguments(params Func<object>[] expr)
  {
    //TODO tutaj magia, ujawnione już za chwilę!
    return "";
  }
}

Ale najpierw test z wykorzystaniem NUnit.

    using NUnit.Framework;
    using NUnit.Framework.SyntaxHelpers;

    [TestFixture]
    public class LoggingTests
    {

        [Test]
        public void TwoParametersCorrectlyFormatted
        {
            string parameterNamesAndValues = TestClass.Foo(1, "zzz");
            Assert.That(parameterNamesAndValues, Is.EqualTo("Method's Foo arguments >> bar: 1, baz: zzz");
        }

        [Test]
        public void NoParametersCorrectlyFormatted
        {
            string noParameters = TestClass.NoParameters();
            Assert.That(noParameters, Is.EqualTo("Method's Foo arguments >> No arguments.");
        }
    }

Odpalamy testy, który oczywiście nie przechodzą.

Żeby testy zadziałały, nasza klasa LoggingHelpers wraz z metodą GetMethodParameters może wyglądać tak:

using System;
using System.Diagnostics;
using System.Reflection;
using System.Runtime.CompilerServices;

public class LoggingHelpers
{
    public static string GetMethodParameters(params Func<object>[] expr)
    {
      // Pobieramy nazwę metody.
      string methodname = new StackFrame(1).GetMethod().Name;

      // wstępne formatowanie wynikowego napisu:
      string logmessage = "Method's " + methodname + " arguments >> ";

      // Tablica wyrażeń lambda jest pusta
      if (expr.Length == 0)
      {
        logmessage += "No arguments.";
      }
      else
      {
        try
        {
          // dla każdego Expression
          foreach (var par in expr)
          {
            // Zaawansowane sztuczki. Za pomocą MSIL znajdujemy informacje o Expression
            byte[] il = par.Method.GetMethodBody().GetILAsByteArray();

            // bajty 2-6 oznaczają uchwyt do naszych parametrów
            int fieldHandle = BitConverter.ToInt32(il, 2);

            // pobieramy FieldInfo tego parametru
            FieldInfo field = par.Target.GetType().Module.ResolveField(fieldHandle);

            // Formatujemy ostatecznie napis dla tego parametru.
            // Nazwę parametru uzyskujemy z FieldInfo, natomiast wartość wykonując przekazane Expression.
            logmessage += string.Format("{0}: {1}. ", field.Name, par() ?? "@null");
          }
        }
        catch
        {
        // Ignorujemy błędy - nic nie jest gorsze od doskonale działającej logiki aplikacji, która wywala się na narzędziach do logowania :-)
        // Tego typu try-catch to zła praktyka w aplikacji! W tym miejscu jest to stosowne, ale przestrzegam przed nadużywaniem "zjadania" wyjątków.

          logmessage += " FAILED reading arguments.";
        }
      }
    }
}

Klasa do wykorzystania w aplikacji.

W kolejnej notce pokażę, jak to spiąć z log4net.

Ich dzieło wspólne to właśnie Stack Overflow. System reputacji i nagród za zadawanie mądrych pytań i dawanie pomocnych odpowiedzi świetnie działa – moje trzy pytania na dosyć niszowe tematy prawie natychmiastowo miały odpowiedzi, za to trudno było znaleźć pytanie bez odpowiedzi.

Znalazłem tam masę zbiorów różnego rodzaju sztuczek programistycznych. Dzisiaj lista najciekawszych .NET-owych pytań. To także dosyć dobry materiał do przygotowywania się do testów podczas rekrutacji na wymarzone stanowisko programisty.

• „Ukryte” funkcje języka C#. – Padają tam podstawowe rzeczy np. „yield” lub „using”, ale wiele z nich nie znałem, a teraz wykorzystuję samemu.
• Najbardziej przydatne atrybuty. – Niestety mało kto używa atrybutów z frameworka, a co dopiero wykorzystuje własne w swoim kodzie. System.Obsolete to mój ulubiony ułatwiający refaktoryzację.
• Najbardziej zadziwiające zachowania języka – często spotykane na rozmowach kwalifikacyjnych. Nie cierpię pytań o tego typu szczegóły, ponieważ często ma się ona nijak do naszych umiejętności. Niemniej jednak lepiej zabłysnąć taką wiedzą, nawet jeżeli jej nigdy nie wykorzystamy.
• Zbiór metod rozszerzających – Wątek rewelacja. Mnóstwo świetnych metod rozszerzających, bardzo polecam. Autorzy nawet zrobili z tego gotową bibliotekę.
• Na jakie pytania każdy programista .NET powinien umieć odpowiedzieć? – kolekcja pytań na rozmowy o pracę i do wykorzystania nacodzień.
• Częste pomyłki – każdy programista .NET powinien się z tą listą zapoznać, często zdarza mi się widzieć kod, który podpada pod rzeczy wymienione w tym wątku.
• Najbardziej przydatne darmowe biblioteki do .NET – doskonały zbiór open source narzędzi. Używam wiele z nich – NHibernate, RhinoMocks, log4net, StructureMap, itd. Od nadmiaru wymienionych narzędzi może rozboleć głowa, ale każde jest opatrzone komentarzem, co ułatwia nam decyzję, czego użyć
• Co możemy zrobić w MSIL, czego nie zrobimy w C#. – bardziej zaawansowany temat wykorzystania samego MSIL (języka pośredniego, assemblera .NET) zamiast C#. Możemy sobie nawet zrobić przeładowane metody, które różnią się tylko typem zwracanym. Nawet nie wiem jak by to działało. :-)

Polecam przeglądanie Stack Overflow samemu, baza wiedzy i pomocnych osób jest imponująca.