IntelliTrace - schemat XSD

Home

Swego czasu w postach Własne zdarzenia IntelliTrace! oraz Własne zdarzenia IntelliTrace 2 opisałem jak zmodyfikować plik CollectionPlan.xml zawierający plan działania IntelliTrace (historycznego debuggera) tak, aby zdefiniować swoje własne zdarzenie IntelliTrace (ważny punkt w historii działania programu kiedy IntelliTrace nagrywa stan aplikacji). Ostatnio wróciłem do tego zagadnienia i "bawię się" testując różne możliwości IntelliTrace. Niestety czasami, po zmodyfikowaniu pliku CollectionPlan.xml, przy próbie uruchomienia debuggera otrzymywałem błąd np.:

error VSLG4001: The specified collection plan is invalid: 'C:\CollectionPlan.xml'. More information: The 'type' attribute is invalid - The value 'Object' is invalid according to its datatype 'urn:schemas-microsoft -com:visualstudio:tracelog:ClrType' - The Enumeration constraint failed.

Komunikat jest czytelny, wartość Object dla atrybutu type jest niedozwolona. Metodą prób i błędów można wywnioskować, jakie wartości są poprawne, ale to męczące i niewydajne. Pomyślałem więc, że skoro zawartość pliku CollectionPlan.xml to dokument XML, to musi on być walidowany przy pomocy odpowiedniego schematu XSD. Ale gdzie go szukać? Przejrzałem zawartość katalogu instalacyjnego Visual Studio 2010 i niczego nie znalazłem.

Stwierdziłem więc, że zajrzę do biblioteki Microsoft.VisualStudio.IntelliTrace (pisałem o niej w poście Poznaj swój program), która umożliwia programową analizę logów IntelliTrace, ale nie tylko. Biblioteka ta wykorzystywana jest również przez program IntelliTrace.exe (o tym też pisałem w poście Używanie IntelliTrace poza Visual Studio 2010!), który znajdziemy w katalogu instalacyjnym Visual Studio 2010. Program ten służy do uruchomienia historycznego debuggera i kiedy używamy IntelliTrace z poziomu Visual Studio, to korzystamy właśnie z tego programu. Skoro tak to doszedłem do wniosku, że walidacja konfiguracji i schemat XSD znajdują się właśnie w tej bibliotece.

Okazało się to strzałem w dziesiątkę. Bibliotekę załadowałem do .NET Reflector'a. Najpierw zlokalizowałem w zasobach komunikat z błędem. Następnie sprawdziłem gdzie jest używany i znalazłem tylko jedno takie miejsce, a stamtąd już szybko doszedłem do wywołania metody public static XmlSchema GenerateXmlSchema(). Niestety okazało się, że nie mogę jej wywołać z własnego kodu, ponieważ znajduje się w klasie internal class ConfigMessagePacker. Skopiowałem więc jej kod (ok. 1200 linii) do swojego programu i po chwili miałem już XSD.

Krótko o instalowaniu ServicedComponent

Home

W dwóch poprzednich artykułach na temat zarządzanych komponentów COM+ pisałem, że instaluje się je przy użyciu narzędzia regsvcs.exe. Tak oczywiście jest, ale ostatnio ku swojemu zaskoczeniu zauważyłem, że jest to opcjonalne. Jeśli nie zainstalujemy takiego komponentu z poziomu konsoli (np.: regsvcs.exe MyComponent.dll) to zostanie on zainstalowany automatycznie przy pierwszym wywołaniu jego konstruktora.

[assembly: ApplicationName("MyComponent")]
[assembly: ApplicationActivation(ActivationOption.Server)]
[assembly: System.Reflection.AssemblyKeyFile("MyComponent.snk")]
[assembly: ApplicationAccessControl(false)]
public class MyComponent: ServicedComponent
{
  ...
}

...

//Jeśli komponent nie został wcześniej zainstalowany to zostanie zainstalowany w tym momencie
using (MyComponent cmp = new MyComponent())
{
  ...
}

Jeszcze o ServicedComponent

Home

W tym poście wrócę do tematu aplikacji modelu COM+ napisanych w kodzie zarządzanym, który to poruszyłem w poprzednim artykule. Tym razem chciałbym zwrócić uwagę na problem wersjonowanie takich komponentów. Upraszczając, chodzi o różnicę pomiędzy katalogiem, z jakiego komponent został zainstalowany w systemie, a katalogiem, w którym znajduje się biblioteka z komponentem jakiej używa dana aplikacja. W szczególności mogą to być inne katalogi np.: c:\Install oraz c:\bin.

W takim przypadku łatwo może dość do sytuacji, w której binaria w obu lokalizacjach będą się różnić. Objawy będą różne w zależności od trybu aktywacji (pisałem o nich poprzednio).W przypadku Aplikacji biblioteki tak długo jak w obu katalogach będą znajdować się biblioteki skompilowane dla tego samego środowiska (32 lub 64 bitowego) nie będzie żadnego problemu (poza bałaganem). Co ciekawe znaczenie ma tylko liczba bitów, wersje bibliotek mogą być inne, różna może być nawet liczba udostępnianych przez komponent metod. Natomiast w przypadku kiedy w jednym katalogu będzie wersja 32 bitowa, a w drugim 64 bitowa przy próbie skorzystania z komponentu dostaniemy wyjątek ComException o treści Klasa niezarejestrowana....

W trybie Aplikacji serwerowej liczba bitów nie ma znaczenia. Znaczenie ma jednak zawartość bibliotek w obu lokalizacjach. Jeśli będzie różna debugowanie nie będzie możliwe. Jeśli zmieni się interfejs, na przykład do biblioteki zostanie dodana nowa metoda, ale nowa wersja nie zostanie zainstalowana, to przy próbie jej użycia pojawi się wyjątek.

Generalnie problem dotyczy też natywnych komponentów COM+ (piekło COM+) ale z takimi komponentami nie pracowałem dlatego nie znam szczegółów.

Debugowanie ServicedComponent

Home

ServicedComponent to klasa umożliwiająca tworzenie zarządzanych komponentów/klas, które mogą być użyte w aplikacjach COM+ oraz mogą korzystać z usług COM+. Jedną z takich usług jest na przykład pula obiektów, czyli coś podobnego do puli połączeń z tą różnicą, że możemy w niej umieścić instancje naszej własnej klasy.

Aby stworzyć taką specjalną klasę należy wydziedziczyć ją ze wspomnianej klasy ServicedComponent. Do tej pory nie miałem okazji z niej korzystać, dlatego napotkałem pewne kłopy przy debugowaniu takich zarządzanych komponentów COM+ (dalej będę używał po prostu pojęcia komponent).

Należy zacząć od tego, że są dwa tryby aktywacji komponentów COM+ (zarządzanych lub nie). W pierwszym (tzw. Aplikacja biblioteki/Library application) komponent aktywowany jest w procesie aplikacji, która z niego korzysta. W drugim trybie natomiast (tzw. Aplikacja serwera/Server application) aktywacja przeprowadzana jest przez dedykowany proces. Tworząc taki komponent możemy określić tryb aktywacji przy pomocy atrybutu ApplicationActivationAttribute. Tryb ten można również zmienić już po zainstalowaniu komponentu (przy pomocy narzędzia regsvcs.exe) w konsoli zarządzania w przystawce Usługi składowe (ang. Component services). Znajdziemy ją w lokalizacji C:\Windows\System32\comexp.msc.

Debugowanie takiego zarządzanego komponentu różni się w zależności od trybu aktywacji. Zacznijmy od pierwszego przypadku czyli tzw. Aplikacji biblioteki. Tutaj sprawa generalnie jest prosta. Skoro komponent aktywowany jest w procesie aplikacji, która z niego korzysta to wystarczy postawić pułapkę w odpowiednim miejscu np.: w kodzie komponentu i tyle. Jest jedno ale. To nie zadziała jeśli aplikacja korzystająca z komponentu została skompilowana na platformę .NET 4.0. Komponent będzie zwracał poprawne wyniki ale jak do tej pory nie udało mi się zmusić VS 2010 do zatrzymania się na pułapce ustawionej w kodzie komponentu albo przejść do tego kodu przy pomocy F11. Jeśli zmienimy platformę na przykład na .NET 3.5 to problem z debugowaniem nie wystąpi.

Trzeba również wiedzieć, że w przypadku tego trybu aktywacji, jeśli mamy zainstalowany komponent 32 bitowy, to proces, który chce z niego skorzystać również musi być 32 bitowy. Analogicznie dla 64 bitów. Informację o błędzie dostaniemy już przy próbie wywołania konstruktora komponentu.

W przypadku trybu "serwerowego" komponent aktywowany jest w innym procesie, więc wersja platformy czy nawet liczba bitów nie mają znaczenia (również przy debugowaniu). Z drugiej strony mamy inny problem ponieważ musimy doczepić się do tego procesu aby go zdebugować czyli skorzystać z funkcji Debug->Attach to Process.... Interesujący nas proces nazywa się dllhost.exe. Kłopot w tym, że na liście może znajdować się kilka procesów o tej nazwie. Pierwsze przybliżenie uzyskamy zawężając listę do tych procesów, które w kolumnie Type mają wartość Managed.... W przypadku gdy jest ich kilka można skorzystać z programu Process Explorer i sprawdzić identyfikator procesu, który korzysta z biblioteki z naszym komponentem.

W jednym z kolejnych postów wrócę jeszcze do tematu i napisze o problemach z wersjonowaniem omawianych komponentów.

Londyn - metro (wskazówki)

Home

W ostatnim poście dotyczącym metra w Londynie obiecałem, że dam kilka wskazówek o tym jak z niego korzystać (o innych środkach transportu nie napiszę bo nie używam). Nie będzie to jakaś wiedza tajemna, ale kiedy jest się po raz pierwszy w Londynie, to nie wszystko jest oczywiste.

• Nie opłaca się kupować biletów za gotówkę. Tak zakupiony bilet dla pierwszej strefy, w porównaniu do biletu elektronicznego, może być nawet 2 razy droższy. Dla dalszych stref różnica jest mniejsza, ale na przykład większość atrakcji turystycznych znajduje się w pierwszej strefie.
• Osobiście korzystam z karty Oyster czyli odpowiednika Warszawskiej Karty Miejskiej z tą jednak różnicą, że Oyster oferuje więcej możliwości. Na taką kartę można załadować bilet okresowy, ale również określoną sumę pieniędzy do wydania na przejazdy tzw. pay as you go. Z metra korzystam raz na jakiś czas więc jest to dla mnie idealne rozwiązanie.
• Kartę Oyster kupujemy (ładujemy) w automatach biletowych ustawionych w metrze lub w kasach. Przy zakupie zostanie pobrany zwrotny depozyt wysokosci 5 funtów.
• Nie na każdej stacji znajdziemy kasy biletowe, automaty natomiast tak.
• Ważne!!!Korzystając z karty Oyster trzeba koniecznie pamiętać żeby zbliżyć kartę do czytnika (oznaczone sa charakterystycznymi żółtymi kółkami) przy wejściu ale i przy wyjściu z metra. W innym wypadku zostaniemy obciążeni dodatkową opłatą (nie wiem ile dokładnie). W większości wypadków nie ma z tym problemu ponieważ nie przejdziemy przez barierki bez ważnego biletu. Niestety na niektórych stacjach nie ma barierek. Czasami zdarzy się również, że barierki są otwarte ale wtedy też trzeba pamiętać o czytniku.
• Po zarejestrowaniu karty Oyster na tej stronie będziemy mogli śledzić historię naszych podróży oraz doładować kartę on-line. Jeśli chcemy kupić bilet okresowy na czas dłuższy niż tydzień rejestracja jest wymagana.
• Ważne!!! Jeśli mamy kartę pay as you go to mamy zagwarantowane, że danego dnia nie wydamy na przejazdy więcej niż koszt biletu dziennego. Szczegóły można znaleźć tutaj.
• Warto korzystać ze strony Transport for London. Znajdziemy tam bardzo dobrą wyszukiwarkę połączeń oraz informacje o planowanych remontach poszczególnych linii. Generalnie remonty przeprowadzane są w weekendy.
• Nie wszystkie stacje metra mają windę.
• Na stacjach metrach można znaleźć broszurki z planem metra - bardzo przydatne.
• Jeśli ktoś źle znosi wysokie temperaturę lub duchotę, to schodząc do metra (szczególnie korzystając z linii głębinowych) warto zaopatrzyć się w butelkę wody.
• Szczegółowy cennik znajdziemy tutaj

Linki do poprzednich postów z serii na temat życia w Londynie:

• Początek
• Ceny jedzenia
• Pogotowie
• Przechodzenie przez ulicę
• Kosze na śmieci
• Metro (trochę narzekania)
• Zamieszki