Droga do .NET 2.0

Microsoft określił termin premiery Visual Studio 2005 (i .NET 2.0): produkt będzie dostępny w listopadzie 2005. Nowa wersja z jednej strony jest "aktualizacją" - z drugiej kolejną ewolucyjną wersją znanej technologii. Nie jest to więc rewolucja na miarę wprowadzenia .NET, choć wiele elementów zmienia się w istotny sposób.

Microsoft określił termin premiery Visual Studio 2005 (i .NET 2.0): produkt będzie dostępny w listopadzie 2005. Nowa wersja z jednej strony jest "aktualizacją" - z drugiej kolejną ewolucyjną wersją znanej technologii. Nie jest to więc rewolucja na miarę wprowadzenia .NET, choć wiele elementów zmienia się w istotny sposób.

We wszystkich kolejnych wersjach Microsoft Windows nadrzędnym zadaniem było zapewnienie "zgodności w dół". I trzeba przyznać, że to się udało całkiem dobrze - praktycznie w Windows 95 działały aplikacje z Windows 3.11, a nawet w XP uda się uruchomić aplikację do DOS-u.

Było to osiągane w różny sposób - DOS działa w oddzielnej swego rodzaju "maszynie" wirtualizacyjnej (tak samo działają Services For Unix, oferujące API Uniksa na platformie Windows). Przy przejściu pomiędzy architekturą 16- a 32-bitową pojawił się tzw. thunk layer - specjalny pośrednik który umożliwiał współdziałanie kodu 16- i 32-bitowego (np. - schowka). Analogiczne rozwiązanie jest stosowane w 64-bitowych wersjach Windows do Itanium.

Inaczej zachowywana jest zgodność API. Kolejne wersje bibliotek muszą implementować dokładnie te same funkcje co wcześniejsze (a nawet - uwzględniać "starsze", błędne działanie). Używając pakietu Compatibility Toolkit, można kontrolować funkcjonowanie poszczególnych API do poszczególnych aplikacji.

Skąd pomysł na .NET

Nie ma różnicy pomiędzy zainstalowanymi plikami pomocy a zasobami w Internecie.

Nie ma różnicy pomiędzy zainstalowanymi plikami pomocy a zasobami w Internecie.

W wypadku technologii COM zachowanie zgodności oznaczało, że każdy kolejny komponent musiał obsługiwać interfejsy z poprzednich wersji. Co powodowało komplikacje dla twórców tych komponentów - a i zdarzało się, iż program instalacyjny podmieniał plik DLL na "starszy". .NET wprowadza tu bardzo istotną zmianę - można równolegle instalować te same składniki w różnych wersjach. Innymi słowy, komponent w wersji 2. nie musi być całkowicie zgodny z wersją 1 - bo aplikacja może mieć "starszą" prywatną wersję. Dzięki temu osiągnięto koniec tzw. piekła DLL. Równocześnie - może obok siebie współistnieć .NET 1.0, 1.1 i 2.0. Co więcej - bez problemu mogą ze sobą współpracować (dzielić kod itp.).

Nie można instalować wielu równoległych wersji Beta .NET 2.0 - ale jest to blokada nakładana na poziomie instalatora.

W 2.0 pojawił się nowy element związany z tzw. instalacją click once, pozwalającą "zainstalować" aplikację podczas pierwszego uruchomienia. Tak naprawdę, shell Windows może uruchomić specjalny plik "manifestu" - dokument, który określa, które elementy stanowią aplikację. Podczas uruchamiania .NET wyszukuje i uruchamia odpowiednie elementy, co powoduje, że aplikacja uruchamia się. Dodatkowo w tym pliku można opisać wymagane uprawnienia i pokazać je użytkownikowi, aby zdecydował, czy można dany "program" uruchomić.

Diagram klas.

Diagram klas.

Warto dodać, że wersjonowanie i manifest dają potężne narzędzie administratorowi: może on samodzielnie określać zasady "powiązania" komponentów oraz aplikacji, które je wykorzystują - gdy na przykład nowy komponent działa niezupełnie prawidłowo.

Drugi problem związany jest z bezpieczeństwem. Kod Win32 ograniczony jest tylko uprawnieniami zalogowanego użytkownika. Jeżeli pobierze kod z Internetu - to może go bez trudu uruchomić. Oczywiście, nie jest trudne utworzenie w pełni izolowanego środowiska (sandbox) w którym uruchomimy kod. Problem pojawi się wtedy, gdy taki kod chce wymienić jakieś informacje z "bazowym" systemem - zapisać plik, wydrukować dokument itp.

W .NET 1.0 wprowadzono mechanizm Code Access Security. Pozwala on określić, jakie prawa ma dany fragment kodu. Aplikacja może podać, jakich praw oczekuje, a .NET (skonfigurowany przez administratora) pozwoli wykonać daną operację lub nie. CAS uwzględnia uprawnienia użytkownika i pochodzenie kodu (jego hash, podpis cyfrowy czy adres, z którego pochodzi). Innymi słowy - jeżeli kod pochodzący z Internetu nie jest uznany za bezpieczny, to nawet użytkownik z uprawnieniami administratora go nie uruchomi.

Załóżmy, że ktoś z zewnątrz pisze aplikację .NET dla pewnej firmy. Ze względów oczywistych nie powinien uzyskać dostępu np. do danych osobowych. Zabezpieczenie na poziomie ACL nie wystarczy, bo z nowej aplikacji będzie korzystał dział kadr, który używa tych danych. Administrator zażądał zatem, żeby aplikacja została podpisana ustalonym kluczem i odpowiednio ustawił uprawnienia: w sieci firmowej aplikacje tak podpisane w ogóle nie mogą sięgać do zasobów kadrowych. To daje pewność, że aplikacja zewnętrzna (nawet złośliwie napisana) na pewno do tych danych nie uzyska dostępu, a inne - niepodpisane czy podpisane innym kluczem - w ogóle nie będą działać.

Konfiguracja tych mechanizmów nie jest prosta. Trudno programiście określić "minimalne" potrzebne prawa, a i administrator nie bardzo wie, co można konfigurować. W .NET 2.0 jest mechanizm, który pozwala "odpytać" gotową aplikację, jakich uprawnień potrzebuje, i ułatwia przygotowanie odpowiedniego skryptu. Może dzięki temu CAS stanie się bardziej popularny - obecnie łatwiej jest uruchamiać aplikacje z pełnymi prawami.

Częścią .NET jest tzw. CLS (Common Language Specification) - wydzielona wspólna specyfikacja będąca standardem IEEE, określająca m. innymi Common Type System - platformę, która pozwala współpracować kodom napisanym w różnych językach programowania.

Na poziomie API Win32 można było wywoływać funkcje - jeżeli zostały w odpowiedni sposób oznaczone jako tzw. eksportowe, a przekazywanie wartości odbywało się w sposób binarny. .NET pozwala na znacznie większą integrację pakietów napisanych w różnych językach dzięki CTS.

Klasa VB.NET może dziedziczyć po klasie C#, można przechwycić wyjątek rzucony przez kod Perl.NET itp. Co więcej - dzięki wspólnemu systemowi typów nie ma tu kosztownego szeregowania (marshaling), znanego z CORBA czy COM.

Warto dodać, że wśród kilkudziesięciu języków programowania działających na platformie .NET można też znaleźć polski akcent: rozwijany jest Nemerle - język, w którym zgrabnie zostały połączone elementy obiektowe i cechy języka funkcyjnego. Microsoft Research przyznał grant na dalszy rozwój tego projektu.

Kompilatory .NET generują tzw. kod zarządzany w języku MSIL (przypominającym asembler), ale na platformie .NET nie ma interpretera kodu - aplikacja jest zawsze kompilowana przed uruchomieniem. W odróżnieniu od tradycyjnych środowisk - odbywa się to po stronie klienta i w sposób odpowiedni do danej sytuacji na komputerze, gdzie kod ma działać. W .NET 2.0 niewiele wiadomo o zmianie sposobu przetwarzania kodu zarządzanego w trakcie kompilacji JIT. Zmodyfikowano sposoby optymalizacji, rozbudowano język MSIL, generalnie przyspieszono działanie kodu .NET. Będą dostępne od razu dwie wersje .NET 2.0 - do architektury 32- i 64-bitowej, funkcjonalnie identyczne. Innymi słowy, dowolna aplikacja .NET będzie działać na platformie 32- i 64-bitowej bez żadnych zmian.

Warto dodać, że kod zarządzany praktycznie wyeliminował tzw. błędy przekroczenia bufora. Przed kompilacją (i uruchomieniem) MSIL zostaje zweryfikowany - sprawdzana jest poprawność typów, ewentualne przekroczenie zakresów, potwierdzane są uprawnienia itp.

Wersje VS.NET

Standardowy edytor XSD w C# Express też wygląda znajomo.

Standardowy edytor XSD w C# Express też wygląda znajomo.

Microsoft zamierza wprowadzić trzy główne wersje VS.NET - Express, przeznaczoną dla początkujących i hobbystów, Professional (pełny pakiet), a także Visual Studio Team System, zawierający dodatkowe elementy ułatwiające pracę w zespole. W ramach Team System dostępne będą także sprofilowane pakiety dostosowane do roli danej osoby w zespole - architekta, programisty, testera itp. Visual Studio Team System jest tworzony tak, żeby można go było dobrze wykorzystać tam, gdzie używa się pewnych elementów Microsoft Solutions Framework (czyli zbioru "rad" dotyczących prowadzenia projektów informatycznych, oferowanego przez Microsoft).

Wiele elementów w tym pakiecie ma uprościć zarządzanie pracą zespołu. Na przykład w Team System można tworzyć tzw. elementy robocze (work items), które określają dany zestaw plików źródłowych (i innych elementów), a następnie łączone są w całościowe rozwiązanie. Z elementami roboczymi można też wiązać błędy czy uwagi betatesterów, a następnie generować raporty pokazujące na przykład, który z programistów jest "źródłem" największej liczby błędów.

W Team Server są także narzędzia do analizy kodu, testowania oraz badania wydajności rozwiązania - wszystko dostępne z poziomu jednego IDE. Kod analizują narzędzia PREfast, do badania poprawności kodu C++, oraz FxCop.

Narzędzie do testowania pozwala tworzyć testy jednostkowe (generowane są specjalne metody oznaczone odpowiednimi atrybutami). Można też uruchomić test pokrycia kodu (pokazujący, które wiersze są wykonywane w trakcie działania programu), a także testy obciążeniowe.

Nie można porównywać wersji Express z wersjami Standard 2003. To nie tylko duży pakiet, pozbawiony pewnych dodatkowych funkcji. Microsoft dodał elementy dostosowane do potrzeb początkujących i tych, którzy programowaniem nie zajmują się zawodowo. Produktów z serii Express Edition będzie można używać z Windows XP Home (będzie można także pisać strony w ASP.NET 2.0).

Dodatkowe tutoriale, "Startup Kits" - to wszystko ma ułatwić oswojenie się z technologią. Prawdopodobnie dodatkowe elementy nie zostaną dołączone do wersji "profesjonalnych" i ten, komu są potrzebne, powinien sięgnąć po wersję Express, która ma zawierać także specjalną dokumentację dla początkujących. Cena produktów z tej wersji wyniesie prawdopodobnie 49 dolarów.

Kolejna wersja VS.NET ("Orcas") ma być związana z platformą Longhorn i obsługiwać m.in. nowe sposoby przechowywania informacji czy XAML podczas projektowania UI.

Warto dodać, że do .NET 2.0 jest specjalna licencja "go live", która pozwala stosować go w aplikacjach produkcyjnych (mimo że ma status beta). Na przykład w czasie pisania tego artykułu kilku dużych dostawców usług internetowych oferowało hosting z ASP.NET 2.0.

Użytkowników starszych wersji VS 2005 na pewno zainteresuje przebieg migracji pomiędzy beta 1 a beta 2. Generalnie nie powinna sprawiać kłopotów - projekty się przenoszą i kompilują. Niestety, API .NET trochę się zmieniło - głównie klasy związane z obsługą XML.

Natomiast znacznie łatwiej jest przenosić projekt pomiędzy VS 2003 a betą 2 niż beta 1. Jeżeli jednak pojawią się problemy, warto skompilować kod "ręcznie", z wiersza poleceń, lub użyć nowego narzędzia Msbuild do kompilacji wsadowej.


Zobacz również