SSMScripter - "Go to definition" dla SQL Management Studio 2012

Tak się złożyło, że ostatnio dużo czasu w pracy spędzam nad MS SQL z wykorzystaniem SQL Management Studio 2012 i czuję mały niedosyt. Nie mówię, że edytor jest zły czy coś, ale przeglądanie informacji w oknie "Object Explorer" przy ~100 procedurach składowanych, ~50 funkcjach i 3-4 wyzwalaczach na każdą z tabel nie należy do przyjemności (nie wspominając już o straconym czasie). Tym bardziej jeżeli wchodzi się w głąb zależności pomiędzy obiektami, szaleństwo. Może gubią mnie moje przyzwyczajenia z Visual Studio i komendą "Go to definition" (F12), nie wiem. Wiem na pewno, że łącząc się bezpośrednio z serwerem MS SQL to okienko "Navigate To" niewiele pomaga. Szybciej jest z SQL Search, ale to też nie do końca to. Mimo swoich nieocenionych możliwości dalej trzeba używać "Modify..." z "Object Explorer". Istnieje natomiast takie cudo jak SSMSBoost posiadające odpowiednią funkcjonalność. Niestety nie mogłem zainstalować tego w pracy, ale skoro oni mogli to ja też mogę. Postanowiłem się nieco zabawić i napisać własny plugin do Management Studio.

Tak powstał SSMScripter. Prosty dodatek umożliwiający skryptowanie obiektów bezpośrednio z edytora tekstu do nowego okna z poziomu menu kontekstowego lub właśnie skrótu F12.

Co ważne dodatek nie wywołuje standardowych metod skryptujących w jakie wyposażone jest Management Studio tylko robi to po swojemu wyciągając informacje z tabel systemowych, tzn:

1. Sprawdź tekst pod myszką
2. Znajdź w tekście potencjalny obiekt
3. Spróbuj dowiedzieć się o nim jak najwięcej (typ, schema, nazwa itp)
4. Wyciągnij z bazy jego zawartość i otwórz w nowym oknie

Proste, szybkie i nawet działa. Wszystko co potrzebne do uruchomienia dodatku znajdziecie na stronie z projektem:

https://github.com/mkoscielniak/SSMScripter

PS. jeżeli po skopiowaniu plików w odpowiednie miejsce w Management Studio 2012 nic się nie zmieniło, najprawdopodobniej oznacza to, że Windows jest za bardzo troskliwy i trzeba odblokować SSMScripter.dll w właściwościach pliku ;-)

VS2012 w świecie Embedded i .NET 3.9 CF

Tworząc na platformę Windows Embedded Compact (Windows CE) oraz Windows Embedded Handheld (Windows Mobile) programista .NET nie ma zbyt dużego wyboru. Komplet Visual Studio 2008 i .NET 2/3.5 CF jest standardem. Co prawda VS2008 to całkiem solidny kombajn z którym można żyć w zgodzie (zresztą robię to codziennie :)). Nie zmienia to jednak faktu, że nowsze wersje są po prostu lepsze.
Po 5 latach zaniedbywania programistów w końcu coś drgnęło. Microsoft zapowiedział wydanie Windows Embedded Compact 2013 w pierwszym kwartale przyszłego roku (zresztą nazwa 2013 jest dość wymowna ;)). Informacja nie była by taka elektryzująca gdyby nie fakt, iż wraz z system udostępnione zostanie wsparcie dla VS2012 oraz "nowy" .NET 3.9. Jako programista tego segmentu mogę powiedzieć jedno... W końcu!
Ciekawi mnie tylko, jak to wszytko będzie wyglądało. Jak wiele z elementów VS2012 będzie można wykorzystać, żeby usprawnić codzienną pracę. Oprócz kwestii podstawowych jak edytor formatek, kompilacja, debugowanie itp. będzie wsparcie dla TFS i narzędzi AML. Fajnie, ale ani z pierwszego, ani z drugich nie korzystam. Cóż trzeba poczekać, szczegółów jest niewiele.
Inaczej ma się sprawa z .NET 3.9 CF. Z udostępnionych informacji wynika, że API się nie zmieni. Tzn, kod z 3.5 będzie można bezboleśnie (jeszcze zobaczymy jak to będzie) przenieść na nowszą wersję. Bardziej znaczące są zmiany pod spodem. Wymieniane są 3 główne. Mają bezpośrednio wpłynąć na wydajność platformy. A wszystko to wzorowane na elementach Windows Phone. Otrzymamy zatem:

• Lepszy GC
• Wsparcie dla wielu rdzeni
• Sharing Server - współdzielenie bibliotek pomiędzy różnymi aplikacjami

Pomimo całego mojego entuzjazmu martwi mnie jeden fakt. Jeżeli urządzenie miało preinstalowany .NET 2.0 CF to zawsze mogłem wziąć plik CAB od wersji 3.5 i zainstalować nowszą wersję. Czy teraz nie będzie inaczej? Czy .NET 3.9 CF nie będzie bardziej związany z samym systemem? Czy będzie go można zainstalować na CE 5 lub 6. Do tego jeszcze kwestia czy w VS2012 będzie można pisać pod .NET 3.5 CF? Jak na razie, mam więcej pytań niż odpowiedzi...

Debugowanie usług windows w Visual Studio

Jak wiadomo debuger wielkim przyjacielem programisty jest, ale nie zawsze istnieje możliwość odpalenia go od tak sobie wciskając F5. W przypadku usług (serwisów) windows otrzymamy komunikat:

---------------------------
Błąd uruchomienia usługi systemu Windows
---------------------------
Nie można uruchomić usługi z wiersza polecenia lub z debugera.
Usługa systemu Windows musi być najpierw zainstalowana (przy użyciu pliku installutil.exe),
a następnie uruchomiona za pomocą Eksploratora serwera, 
Narzędzi administracyjnych usług systemu Windows lub polecenia NET START.
---------------------------
OK   
---------------------------

Pozostaje pytanie co z tym fantem zrobić? Jak na razie spotkałem się z kilkoma różnymi sposobami, np:

• Wymuszenie odpalenia debugera poprzez System.Diagnostics.Debugger.Launch()
• Stosowanie pętli oczekującej na podpięcie debugera System.Diagnostics.Debugger.IsAttached

Nie są one jednak wygodne ponieważ w każdym przypadku wymuszają chwilowe dodawanie kodu, kompilację warunkową lub parametry lini komend sterujące przebiegiem uruchomienia serwisu. Jaki jest więc złoty środek? Otóż istnieje możliwość sprawdzenia czy uruchomiony proces umożliwia użytkownikowi interakcję. Służy do tego właściwość Environment.UserInteractive. Dzięki niej wystarczy prosty warunek w punkcie wejścia do aplikacji aby rozdzielić przebieg raz a skutecznie. Czyli:

• Zmieniamy rodzaj aplikacji na konsolową (wartość Output Type, zakładki Application, w Properties danego projektu) dzięki czemu zyskujemy wgląd w konsolę
• Dodajemy kod umożliwiający odpalenie implementacji OnStart i OnStop przeciążonych po ServiceBase:
  

  public partial class Service1 : ServiceBase
  {
      public Service1()
      {
          InitializeComponent();
      }
  
      internal void Start(string[] args)
      {
          OnStart(args);
      }
  
      internal void Stop()
      {
          OnStop();
      }
  
      protected override void OnStart(string[] args)
      {
          //...
      }
  
      protected override void OnStop()
      {
          //...
      }
  }
  

• Podmieniamy standardową metodę Main na:
  

  static void Main(string[] args)
  {
      Service1 svc = new Service1();
  
      if (Environment.UserInteractive)
      {
          Console.WriteLine("Starting...");
          svc.Start(args);
          Console.WriteLine("Started");
          Console.ReadLine();
          Console.WriteLine("Stopping...");
          svc.Stop();
          Console.WriteLine("Stopped");
      }
      else
      {
          ServiceBase[] ServicesToRun;
          ServicesToRun = new ServiceBase[] 
          { 
              svc
          };
          ServiceBase.Run(ServicesToRun);
      }
  }
  

W ten sposób, kiedy wciśniemy F5 uruchomiony zostanie debugger z całym jego dobrodziejstwem. Natomiast po zainstalowaniu i uruchomieniu serwisu z poziomu services.msc odpali się druga klasyczna dla usług nitka kodu. Wilk syty i owca cała ;)

PS. Równie dobrze, zamiast konsoli można przygotować aplikację okienkową, nie ma tutaj ograniczeń, idea pozostaje niezmieniona.

Konsola zarządzania

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

NHibernate 3 i QueryOver API

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

Fluent Validation i dziedziczenie

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

Operacje asynchroniczne, czyli C# 5.0

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