Zine.net online

Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc
w Szukaj

dev2dev

Zrób to sam – SSMS addin (The end)

I to już koniec serii o tworzeniu wtyczki do SSMS. W sześciu merytorycznych wpisach na moim blogu krok po kroku tworzyłem następną swoją wtyczkę do SSMS (stąd jej nazwa NextAddin). Zarysowałem ogólne schematy chyba wszystkich elementów niezbędnych do jej tworzenia. Jednak tworząc ją od początku kolejny raz przekonałem się, jak bardzo “kapryśny” może być ten proces. Dlatego jeszcze raz podkreślę szczególnie ważne sprawy, o których należy pamiętać i co na pewno zaoszczędzi nam sporo zdrowia.

  • Wtyczka powinna mieć opcję do resetowania i odinstalowania menu. Resetowanie menu jest koniczne wtedy, gdy dokonujemy zmian w menu wtyczki i chcemy aby stały się one aktywne. Odinstalowanie menu powinno być stosowane jedynie tuż przed odinstalowaniem wtyczki. Odinstalowanie menu bez odinstalowania wtyczki spowoduje, że menu wróci w następnej sesji SSMS.
  • Wszystkie niebezpieczne miejsca mogące generować wyjątki powinny być obejmowane nawiasami try-catch, w przeciwnym wypadku następne uruchomienie sesji SSMS obędzie się bez wywołania zdarzenia OnConnect wtyczki a co za tym idzie potencjalne (a i zapewne kinetyczne :))nieprawidłowe jej działanie.
  • W nazwach identyfikatorów menu wtyczki nie dodajemy kropek. Oryginalne polecenia SSMS zawierają kropki (np. “Query.Execute”) i chciałoby się zastosować to w naszej wtyczce, ale zawsze się to kończy trudnym do zrozumienia wyjątkiem.
  • Przykładowy kod wtyczki, który opisywałem zawiera zestaw metod przechwytujących różnorakie zdarzenia (opisałem to tutaj), do których są stosowne szkieletowe metody obsługi. Metody te można rozbudować o własny kod debugujący wyświetlający komunikaty w oknie Output Window z SSMS (nie działa w wersji Express, dziwne ale prawdziwe).
  • Mając kilka własnych wtyczek zainstalowanych trzeba mieć świadomość, że wpływają one na działanie naszej wtyczki. Może to być szczególnie dotkliwe, gdy debugujemy wtyczkę i nagle ni stąd ni z owąd dostajemy wyjątek kompletnie niezrozumiały, lub też (co gorsza) Visual Studio pokazuje kody źródłowe innej wtyczki, którą w tym momencie próbuje debugować. W wyniku tego nagle możemy stwierdzić, że mamy otwartych kilka plików o nazwie Connect.cs. Edytując niewłaściwy plik możemy spowodować totalne zawieszenie SSMS i tylko odinstalowanie wtyczek jest tu ratunkiem. Dlatego należy unikać pozostawienia kilku wtyczek w trybie debug. Najlepiej jednak mieć aktualnie włączoną jedną wtyczkę gdy jesteśmy w stanie debugowania jej (czyli tylko tą, nad którą obecnie pracujemy).

I to główne problemy, z którymi się spotkałem. Ale pewnie nie wszystkie. Tak jak zaznaczyłem proces bywa bardzo kapryśny. Pisząc odcinek o Window natrafiłem na problem, że metoda CreateToolWindow2 wywodząca sie z EnvDTE kompletnie nie chciała zwracać referencji do utworzonej wewnątrz niej instancji okna wtyczki. Pomogło dodanie całego projektu obsługi okien z innego (działającego) projektu.

Jest to końcowy wpis o tworzeniu wtyczek, ale nie koniec z wtyczkami do SSMS. Na www.codeplex.com zainicjowałem już projekt zawierający pełny kod źródłowy ramy  do tworzenia wtyczek. Muszę go trochę ogarnąć, uporządkować i skomentować. Jak to się stanie opublikuję go i na blogu podam do niego adres. Czyli ciąg dalszy nastąpi.

Dzięki wszystkim czytelnikom tej serii. Nadzieję, że ktoś się tym jeszcze zainteresuje. Tak więc do zobaczenia na codeplex :)

Linki:

do następnego odcinka serii o tworzeniu wtyczki do SSMS

do poprzedniego odcinka serii o tworzeniu wtyczki do SSMS

Opublikowane 26 października 2009 09:17 przez marekpow

Komentarze:

 

feyd-rauth said:

CreateToolWindow2 ma taki mały błąd, że nie potrafi zwrócić referencji do instancji obiektu, którego definicja klasy znajduje się w innym assembly niż główne zarejestrowanej wtyczki. Ja sam słyszałę o nim już od co najmniej dwóch lat. Wyjścia masz zatem dwa (i niech mnie ktoś poprawi, jeśli się mylę):

1) tak jak zrobiłeś - cały kod trzymać w jednym assembly

2) w konstruktorze wszystkich swoich okienek ustawiać wartość pewnej zmiennej globalnej, a następnie korzystać z niej, a nie z wartości zwracanej przez CreateToolWindow2. Założenie w tym miejscu jest takie, że okna są tworzone jedno po drugim na UI przez użytkownika/managera okien, a nie współbieżnie.

Pozdrawiam.

Pawel

października 26, 2009 10:51
 

dotnetomaniak.pl said:

Dziękujemy za publikację - Trackback z dotnetomaniak.pl

października 26, 2009 11:38
 

marekpow said:

@feyd-rauth:

Ostatecznie w wersji, która mam teraz to działa pomimo, że okienka są w innym assembly. Dziwne, ale działa.

października 26, 2009 12:32
 

mgrzeg said:

Marek, moze nie upiekszaj tego kodu jakos specjalnie, tylko pusc na zywca - nawet jak cos bedzie gorzej wygladalo, to moze znajdzie sie ktos, kto Ci pomoze go upiekszyc... a tak mozesz stracic sporo czasu, zanim puscisz to online i wtedy kod straci swoja aktualnosc... Puszczaj! :)

października 26, 2009 13:35
 

marekpow said:

@mgrzeg:

OK, masz rację. Nie ma na co czekać.

października 26, 2009 13:40
Komentarze anonimowe wyłączone
W oparciu o Community Server (Personal Edition), Telligent Systems