Można pisać już dość rozbudowane aplikacje w C# i nie zastanawiać się nad tym co to są metadane czy manifest pakietu, ponieważ taka wiedza na ogół (zwłaszcza na początku) nie jest potrzebna.
Lecz chcąc "wyryć C# na blachę od dechy do dechy", trzeba znać wszystko!
Na początku sam miałem problemy z rozróżnieniem metadanych od manifestu. Wiedziałem że oba niosą jakieś wiadomości opisujące pakiet (czyli to co wypluwa kompilator np .dll lub .exe) ale co konkretnie?
Lecz chcąc "wyryć C# na blachę od dechy do dechy", trzeba znać wszystko!
Na początku sam miałem problemy z rozróżnieniem metadanych od manifestu. Wiedziałem że oba niosą jakieś wiadomości opisujące pakiet (czyli to co wypluwa kompilator np .dll lub .exe) ale co konkretnie?
Metadane
Metadane opisują w szczegółowy sposób cechy każdego "typu" zamieszczonego w pliku binarnym. Jeśli mamy np klasę o nazwie SportowySamochód, to metadane będą zawierać takie informacje jak:
- klasa bazowa klasy SportowySamochód (np Samochód)
- interfejsy implementowane przez klasę (jeśli jakieś są)
- pełny opis każdej składowej obsługiwanej przez typ SportowySamochód (pola, funkcje, właściwości)
Metadane zawsze znajdują się w pakiecie i są automatycznie generowane przez kompilator.
Manifest
Manifest pakietu to inaczej własne metadane. Stąd bierze się pewna nieścisłość ponieważ to także są metadane... tylko że własne. Oznacza to tyle że zawiera bardziej "osobiste" informacje takie jak:
- bieżąca wersja pakietu (numer wersji)
- nazwa modułu
- informacje o kulturze (służące do lokalizacji plików tekstowych i graficznych np jeśli tworzymy aplikację wielojęzyczną)
- listę wszystkich innych pakietów niezbędnych do poprawnego działania bieżącego
- informacje o prawach autorskich
Po co komu metadane?
Tobie :) Chociażby do korzystania z funkcji IntelliSense (automatyczne podpowiadanie składni bardzo przyspieszające kodowanie). Także kompilator JIT (Just In Time) korzysta z metadanych podczas tłumaczenia kodu pośredniego CIL (lub IL, czy MSIL jak kto woli) na kod maszynowy dla danej architektury.
Podglądanie metadanych prostej aplikacji C#
Spróbujemy podejrzeć teraz metadane w VisualStudio2010 najprostrzej aplikacji:
Poprostu stworzony został nowy projekt konsolowej aplikacji i dodane zostały linijki zaczynające się od Console.
Poprostu stworzony został nowy projekt konsolowej aplikacji i dodane zostały linijki zaczynające się od Console.
using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace ConsoleApplication1 { class Program { static void Main(string[] args) { Console.WriteLine("Simple program just to compile package."); Console.ReadLine(); } } }
Po skompilowaniu projektu należy odpalić narzędzie ildasm. W tym celu w VisualStudio na górnej belce klikamy kolejno Tools -> ILDasm lub Tools -> Visual Studio Command Prompt i wpisujemy ildasm i naciskamy Enter.
W nowo otwartym oknie klikamy File -> Open i wybieramy skompilowany plik .exe. Naszym oczom ukaże się taki widok:
Jak na chwilę obecną nie wiele zobaczymy ponieważ nasz program jest tak prosty że nie zawiera wielu metadanych. Aby kompilator wygenerował więcej metadanych należało by stworzyć jakiś obiekt i dodać do niego parę metod czy właściwości. Można natomiast prześledzić kod CIL glównej metody Main klikając na nią dwukrotnie na wygenerowanym drzewie.
Niestety ildasm pozwala jedynie na przeglądanie czystego kodu CIL zamiast C# lub Visual Basic. Aby podejrzeć zdeasemblowany kod w naszym zarządzanym języku trzeba sięgnąć po inne narzędzie, np Reflector. 30-dniową wersję trial można pobrać ze strony:
http://www.reflector.net/
Brak komentarzy:
Prześlij komentarz