Pierwszy program i podstawy IDE

Nowe środowisko programistyczne jest zawsze pewnym wyzwaniem zarówno dla początkującego programisty, który nie wie "gdzie zacząć", jak i zaawansowanego, który ma już swoje przyzwyczajenia wyniesione z poprzednich wersji. Obu przyda się podstawowy przegląd środowiska, pokazujący jak szybko napisać nową aplikację.

Aby poznać nowe środowisko programistyczne, najlepiej zacząć coś w nim pisać. W tym celu zaczniemy od napisania prostej aplikacji, żeby zapoznać się z Visual Studio i wiedzieć, w jaki sposób wykonać operacje niezbędne do utworzenia aplikacji. Tworzony będzie prosty kalkulator - z dwoma polami na wprowadzane liczby, polem na wynik oraz przyciskami dodawania i dzielenia. Taka aplikacja zostanie napisana zarówno jako WinForms, czyli przeznaczona do Windows, jak i Web Forms - program ASP.NET do uruchamiania na serwerze WWW i obsługiwany z poziomu przeglądarki.

Podstawowym elementem, z którym pracuje programista, jest tzw. projekt, czyli struktura, zawierająca to, co niezbędne do budowy danego pliku .exe czy .dll - mogą to być pliki z kodem (C#/VB.NET/J#/inne), graficzne, inne zasoby itp.

Jest wiele predefiniowanych projektów - ich liczba zależy od tego, co zostało wybrane podczas instalacji pakietu, a także od tego, czy np. zostały doinstalowane biblioteki lub rozszerzenia. VS.NET 2005 to nie tylko pakiet do "programowania" - ale też np. środowisko do tworzenia rozwiązań Business Intelligence w SQL 2005 czy diagramów przepływów w BizTalk 2006.

Trzeba jednak pamiętać, że projekty Web w VS 2005 dostępne są w oddzielnym menu (a nie jak w VS 2003 - razem z innymi).

Aby w VS pracować z projektem, trzeba go dodać do tzw. rozwiązania (pliku .sln). Rozwiązanie to zbiór projektów oraz konfiguracji - określającej m.in., jak kompilować je wszystkie razem. Nawet gdy chcemy pracować z jednym projektem, trzeba go dodać do rozwiązania, dokładniej - gdy w Eksploratorze Windows dwa razy kliknie się projekt albo z poziomu IDE otworzy plik .csproj czy .vbproj, to VS albo otworzy ostatnie "znane" rozwiązanie zawierające dany projekt, albo utworzy nowe i doda do niego otwierany właśnie projekt.

Projekt zawiera różne elementy - kod źródłowy, pliki XML, pliki graficzne, nawet dokumentację. Każdy z nich może mieć przypisaną akcję, która jest wykonywana w momencie budowania pliku wynikowego - w wypadku pliku źródłowego polega ona na kompilacji do tzw. plików .obj, potem łączonych w plik .exe czy .dll.

Warto podkreślić, że część składników w rozwiązaniu nie jest gotowym kodem, tylko wzorcem, na podstawie którego powstaje kod. Na przykład w wypadku DataSet (obiektu "przechowującego" dane) na podstawie pliku .xsd powstaje plik .cs zawierający odpowiedni kod.

W wypadku form obok kodu znajduje się plik .resx zawierający dodatkowe zasoby (np. - rysunki), które następnie są osadzane w generowanym pliku.

W IDE określane jest narzędzie, które na podstawie takiego pliku generuje coś, co można skompilować (w wypadku standardowych składników projektów odbywa się to automatycznie).

W .NET 2.0 pojawiła się bardzo ciekawa koncepcja tzw. partial classes, czyli klas częściowych. Definicja jednego obiektu może być rozbita na wiele różnych plików źródłowych, dzięki czemu na przykład forma to trzy pliki: .Designer.cs - zawierający kod generowany na podstawie tego, co użytkownik wykonuje za pomocą graficznych narzędzi do projektowania form, plik .resx (z zasobami) oraz plik .cs, który zawiera kod napisany przez developera (obsługa zdarzeń, dodatkowe składowe klasy itp). Aby zobaczyć te trzy pliki, trzeba włączyć opcję Show All Files (na pasku w Solution Explorer).

W .NET 1.1 narzędzia do graficznego projektowania interfejsu aplikacji po prostu oznaczały w pliku źródłowym blok kodu, którego (domyślnie) użytkownik miał nie dotykać. Czasem jednak coś zmieniał, a to mogło powodować późniejsze problemy z funkcjonowaniem tych narzędzi. W dodatku można było coś zmienić omyłkowo i w rezultacie dalsze projektowanie przestawało być możliwe. Klasy częściowe w .NET 2.0 przed tym zabezpieczają - to, co automatycznie generuje środowisko, znajduje się w innym pliku niż to, co pisze programista. Warto dodać, że z tego mechanizmu korzystają wszystkie narzędzia - do tworzenia obiektów DataSet, do projektowania form Windows, narzędzia związanie z DSI (Dynamic System Initiative - mechanizm pozwalający generować gotowe konfiguracje systemów serwerowych, aby administrator otrzymał gotowy przepis na wdrożenie aplikacji klasy Enterprise) czy to, co generują rozszerzenia budowane na podstawie języków DSL (Domain Specific Language - wyspecjalizowane języki przeznaczone do rozwiązywania określonych zagadnień, które w VS.NET 2005 często mają postać np. projektanta diagramów, na podstawie którego powstaje później kod).

Ponadto klasy częściowe pozwalają, aby kod towarzyszył temu, co projektujemy graficznie - możemy dodawać funkcje do generowanych DataSet itp. bez obawy, że znikną, gdy będziemy regenerować kod na podstawie jakiegoś diagramu.

Pomiędzy projektami należącymi do jednego rozwiązania mogą być tworzone tzw. referencje, czyli wskaźniki określające, że dany projekt korzysta z klas czy funkcji znajdujących się w innym projekcie. Często na przykład oddziela się kod związany z interfejsem użytkownika od kodu obsługującego dane (czy generalnie - logiki biznesowej). Dodanie referencji pozwala wywołać ten kod z poziomu modułu odpowiadającego za UI.

Referencje można dodawać tylko do projektów, które generują .dll - a nie .exe (choć to jest ograniczenie IDE, a nie .NET - można na przykład dodać referencję do skompilowanego już pliku .exe). Można dodawać referencje do bibliotek systemowych czy innych plików .dll zawierających skompilowany kod .NET 2.0. Jeżeli natomiast przy użyciu kreatora dodamy kontrolkę czy np. mechanizmy związywania z danymi, to do referencji od razu zostanie dodana odpowiednia biblioteka systemowa.