Tworzenie aplikacji zgodnych z .NET Framework zasadniczo różni się od dotychczasowego modelu programowania w Windows.

Pierwsza zauważalna zmiana polega na tym, że aplikacja zgodna z .NET nie odwołuje się bezpośrednio do API Win32. Zamiast tego, musi korzystać ze specjalnych bibliotek - pośredników .NET. Po drugie, aplikacja nie jest kompilowana bezpośrednio do kodu maszynowego, a do specjalnego kodu IL. Dopiero potem, w czasie uruchamiania aplikacji, następuje właściwa kompilacja do kodu wynikowego.

Kompilatory trzy

W .NET są dostępne trzy typy kompilatorów. Podstawowy - zużywa najwięcej zasobów, ale generuje najbardziej optymalny kod wynikowy - jest uruchamiany przed każdym użyciem danego składnika aplikacji. Drugi typ kompilatora tworzy znacznie wolniejszy kod, ale za to zarówno kompilacja, jak i kod wynikowy zużywają mniej zasobów. Trzeci, który najbardziej przypomina tradycyjne, uruchamiany jest w momencie instalacji i prekompiluje całą aplikację. Dzięki temu dany program wczytuje się bardzo szybko, ale zajmuje znacznie więcej miejsca na dysku. Kod IL jest bardzo zwięzły, wydaje się, że nawet bardziej niż p-kod Javy.

Instalując aplikację .NET, klient otrzymuje bardzo rozbudowany pakiet, w którym są zdefiniowane poszczególne komponenty, zależności pomiędzy modułami, określone są operacje, jakie może wykonywać dany moduł. Administrator lub programista szczegółowo określa w niej, jakie operacje może wykonywać kod IL. Wraz z każdą kompilacją sprawdzane jest, czy dany kod w ogóle może działać - w ten sposób przy umiejętnym zarządza- niu siecią można niemal zupełnie wyeliminować działanie wirusów.

Aplikacja może zażądać określonych praw (co ciekawsze, może też samodzielnie wymusić, by pewne prawa nie mogły być jej przydzielone). Uprawnienia mogą być nadawane na podstawie pochodzenia pakietu i jego podpisu elektronicznego. Blokowany może być natomiast dostęp do plików lub interfejsu użytkownika.

W pakiecie beta 1 Visual Studio dostępne są trzy kompilatory zgodne z platformą .NET - C#, Visual Basic.NET, a także C++. Wszystkie języki korzystają ze wspólnego środowiska runtime, co pozwala na ścisłą współpracę fragmentów kodu napisanych w różnych językach. Wspólne są m.in. mechanizmy zarządzania wyjątkami (co znacznie upraszcza obsługę błędów), niektóre typy danych, a także usługi systemowe. Możliwe jest także dziedziczenie interfejsów/klas pomiędzy różnymi językami. W ten sposób z kodu C# można odwoływać się do komponentu w VB, nie uwzględniając faktu, że ten element napisany jest w innym języku. Warto podkreślić, że na poziomie .NET Framework jest dokonywana mocna kontrola typów. Pisząc obiekty COM, zwłaszcza w VB 6.0, można było korzystać z mechanizmów automatycznej konwersji pomiędzy typami danych. .NET wymaga jawnego rzutowania typów.

Nowy Visual Basic

Największa rewolucja dokonała się w języku VB.NET. Chyba po raz pierwszy Microsoft postanowił zrezygnować z pełnej zgodności w dół i dostarczyć nowoczesny, w pełni obiektowy język Visual Basic.

VB.NET pozwala na pełne dziedziczenie. Znikły globalne moduły - każda z funkcji musi znajdować się w określonej przestrzeni nazw. Umożliwia również wykorzystywanie mechanizmów zgłaszania wyjątków. Możliwa jest także deklaracja metod o tej samej nazwie, które różnią się tylko typami parametrów. W klasach VB można jawnie deklarować różne tzw. konstruktory. Język ten pozwala na tworzenie "dzielonych" składowych klasy, które są wspólne dla wszystkich instancji. Uporządkowano także koncepcję interfejsów, co znacznie uprościło ich implementację w klasie pochodnej.

VB.NET umożliwia tworzenie aplikacji wielowątkowych. Dotychczas było to możliwe tylko dzięki deklarowaniu odpowiednich komponentów ActiveX. Pozwala też jawnie uruchamiać pewne obliczenia w różnych wątkach.

Należy jednak jeszcze raz podkreślić, że VB.NET nie jest w 100% zgodny z poprzednią wersją Visual Basic. Znikły instrukcje on error goto, które dotychczas służyły do obsługi błędów. Pierwszy element tablic - zgodnie ze specyfikacją CLS - ma indeks 0. Nie można deklarować łańcuchów o stałej długości. Typy danych odpowiadają definicji w CLS, np. typ integer ma długość 32, a nie 16. Zawsze wymagane są nawiasy otaczające parametry procedury czy funkcji. Zmienił się także sposób odwoływania się do funkcji API Win32. Przenoszenie istniejącej aplikacji do VB.NET nie jest procesem automatycznym!

W środowisku Visual Studio nie występują pliki binarne, definiujące np. niektóre właściwości kontrolek umieszczanych na formatkach. Wszystkie te informacje są zapisane w pliku tekstowym i od programisty zależy, czy chce "rysować" formatkę czy woli zmienić kilka linii kodu.

Dobra wiadomość jest także dla tych, którym niezbyt odpowiadało narzędzie DataReport wbudowane w Visual Basic 6.0 (domyślny generator raportów). W VS.NET ma być zawarta nowa wersja Crystal Reports, specjalnie dostosowana do tego środowiska. Podobnie jak w pozostałych elementach pakietu, do wymiany danych ma być wykorzystany XML. Będzie prawdopodobnie także możliwość samodzielnego kontrolowania zarówno wyświetlania raportów, jak i ich eksportu (raport ma także mieć postać odpowiedniego pliku XML).

C# - nowy język .NET

C# to proponowany przez Microsoft "wzorcowy" język dla platformy .NET. Stanowi "unowocześnione C++", gdzie wiele konstrukcji, które zwykle powodowały problemy, zostało wyeliminowanych.

W C# połączono interfejs i implementację. Nie ma oddzielnych plików nagłówkowych. Nie ma szablonów ani makrodefinicji, jednak można korzystać z kompilacji warunkowej. C# pozwala na deklarowanie funkcji, które są dostępne np. tylko w programie w wersji testowej. W przypadku kompilacji produkcyjnej język ten automatycznie usuwa wszystkie wywołania takiej funkcji.

Podstawową zaletą C# jest to, że wykorzystanie w tym języku zewnętrznych komponentów jest tak samo proste, jak w VB. Po dołączeniu pliku referencji do konkretnego komponentu (jest to jedna linijka kodu), można bez problemu deklarować zmienne, które są instancja- mi zaimportowanego obiektu. W C++ było konieczne stosowanie złożonych tzw. wrapperów (czy to w ATL, czy w MFC) i dodatkowo należało wygenerować pliki nagłówkowe, odpowiadające interfejsowi COM. W C# jest to znacznie prostsze.

W C# wprowadzono nowe w stosunku do C++ mechanizmy, które można wykorzystać podczas tworzenia klas. Oprócz metod czy właściwości, można w nim definiować zdarzenia. Mechanizm obsługi zdarzeń przypomina model nadawca-odbiorca i wykorzystuje delegowanie (delegowanie przypomina wskaźnik do prototypu funkcji w C). W klasie jest definiowany specjalny element odpowiadający za dystrybucję zdarzeń. Klienci rejestrują swoje procedury obsługi, które będą wywoływane w momencie zajścia zdarzenia. W VB.NET nie ma takiego mechanizmu - tam zdarzenie, podobnie jak w VB 6.0, jest "metodą" danej kontrolki, w której umieszczany jest kod obsługi.

Dużym ułatwieniem w C# mogą być indeksatory. W klasie jest definiowana specjalna metoda, która pozwala traktować obiekt danej klasy jak tablicę. W momencie wywołania, do danej metody jest przekazywany indeks.

W C# wprowadzono nową instrukcję sterującą, która pozwala szybko przejrzeć wszystkie elementy kolekcji (w .NET kolekcją jest dowolny obiekt, który implementuje odpowiedni interfejs).

W C# są dostępne typy wyliczeniowe, tak jak w C/C++

Microsoft zdecydował się poddać zarówno platformę .NET, jak i język C# procesowi standaryzacyjnemu. Dokumenty standaryzacyjne wysłały firmy: Hewlett-Packard, Intel i Microsoft. Wysłano też draft C# oraz specyfikację CLI, czyli Common Language Infrastructure.

CLS, kod zarządzalny C++ i ...

Aby pozwolić na współpracę różnych języków, Microsoft zdefiniował Common Language Specification, które określa z jednej strony wymagania wobec kompilatora, z drugiej nakłada pewne wymagania na programistę, których musi się on trzymać podczas projektowania klas czy komponentów. Jeżeli komponent jest w pełni zgodny z CLS, to można być pewnym, że może być bez problemu użyty w dowolnym innym języku .NET. Natomiast jeżeli tak nie jest, nie oznacza to, że nie można z niego skorzystać. Możliwe jest półautomatyczne tłumaczenie interfejsów czy translacja typów.

VC.NET nie jest pakietem RAD, jak C# czy VB.NET. Może jednak generować kod IL i tworzyć kod zarządzalny, działający pod kontrolą .NET. Microsoft wprowadził tzw. Managed Extension, specjalne biblioteki i kilka nowych słów kluczowych, które zapewniają dostęp do usług .NET z poziomu C++. Są to zarówno obiekty umożliwiające np. dostęp do automatycznego odśmiecacza, jak i słowo kluczowe __delegate, pozwalające zdefiniować referencję do metody w obrębie określonej sygnatury.

W wersji beta 1 nie wszystkie konstrukcje mogą być kompilowane do kodu zarządzalnego. Nie jest to możliwe, w przypadku gdy moduł korzysta z wstawek w assemblerze czy instrukcji setjmp/longjmp.

Podstawowym zadaniem Managed Extension jest zapewnienie narzędzia, które pozwoli szybko przenieść istniejące aplikacje w C++ do środowiska .NET. Jednocześnie, dzięki tym rozszerzeniom, możliwy jest dostęp do komponentów C++ (niekoniecznie obiektów COM) z poziomu innych aplikacji .NET. Wystarczy napisać w C++ prosty wrapper, który udostępni na zewnątrz np. interfejs klasy. Warto wspomnieć, że C++ jest jedynym językiem w pakiecie VS.NET, pozwalającym na korzystanie z szablonów, które bardzo ułatwiają realizację złożonych algorytmów. Managed Extension umożliwiają napisanie wydajnego kodu w C++, a następnie utworzenie biblioteki, która co prawda nie będzie w pełni "bezpiecznym" kodem, ale za to będzie bardzo szybko realizować swoje zadania. Rozszerzenia są jedynym sposobem odwoływania się do usług .NET z poziomu zwykłego DLL.

Usługi .NET i współpraca z kodem niezarządzalnym

Warto przyjrzeć się bliżej usługom dostarczanym przez .NET. W zasadzie można patrzeć na biblioteki systemowe .NET jak na pewnego rodzaju "opakowanie" standardowego API Win32. Programista ma do dyspozycji usługi związane z wyświetlaniem grafiki, obsługą interfejsu użytkownika, zarządzaniem wątkami, ogólnymi procedurami wejścia/wyjścia czy wreszcie operacje związane z analizą składni XML, bezpieczeństwem czy przetwarzaniem rozproszonym (przy użyciu SOAP i DCOM). Można także bezpośrednio odwoływać się do Win32 API albo do klasycznych komponentów COM.

W przypadku komponentów COM można wygenerować specjalny wrapper - niewielką bibliotekę DLL, która będzie zawierać metadane, pozwalające na wczesne wiązanie interfejsów z poziomu aplikacji .NET. Można także skorzystać ze specjalnych funkcji usługowych .NET, które pozwalają na wywoływanie dowolnej metody COM za pośrednictwem nazwy (wykorzystywany jest tu częściowo interfejs IDispatch). Jednak należy podkreślić, że jest to znacznie wolniejszy sposób odwoływania się do obiektów COM.

Aby odwołać się bezpośrednio do API Windows, należy w specjalny sposób zadeklarować funkcję, wskazując plik DLL, w którym się ona znajduje. Podobny mechanizm jest dostępny zarówno w C# , jak i w VB. W C++ można także tworzyć kod.

Warto dodać, że możliwa jest również współpraca w drugą stronę - "klasyczne" aplikacje mogą korzystać z komponentów .NET. W tym celu trzeba tylko wygenerować odpowiednie pliki interfejsu COM, a także dodać wpisy w rejestrze, wiążące identyfikator komponentu ze środowiskiem runtime .NET. Od tego momentu programista może nie rozróżniać komponentów COM i komponentów .NET.

Prędkość

Na podstawie wersji beta 1 trudno oceniać prędkość działania kodu wynikowego. Jeśli chodzi o IL, to tak naprawdę kod wynikowy generowany przez kompilatory C# i VB.NET jest dosyć podobny (można go podej- rzeć dzięki dołączonemu do NET.SDK deassembler IL). Natomiast różnice występują w mechanizmach dostarczanych przez języki. C# pozwala na bardziej dokładną optymalizację kodu źródłowego. Algorytm można zapisać na kilka sposobów, znacznie lepiej są rozbudowane metody "dostrajania" kompilowanego kodu do IL. Tak więc odpowiednio napisany kod obliczeniowy w C# jest nieznacznie szybszy niż w VB.NET. Szybsze jest VC++. Jednak tu należy podkreślić, że w przypadku C++ nie określamy, jak w C#, które fragmenty kodu są "niebezpieczne", a raczej jawnie podajemy, że dane moduły są kompilowane do kodu zarządzalnego i korzystają z rozszerzeń Managed Extension.

Podczas testów Visual Studio.NET w zasadzie można było tylko mieć uwagi dotyczące dużych wymagań sprzętowych pakietu i skompilowanych programów. Natomiast pakiet, jako całość, działał dosyć stabilnie.