.NET Framework

 

 

Wstęp

 

.NET?

 

.NET jest platformą programowania podobną do Javy. Zasadniczą część tego stanowi wirtualna maszyna, która zamienia powstały po kompilatorze intermediate language (IL) na kod maszynowy. Kompilatory języków wysokiego poziomu dla C#, VB.NET i C++ są dostarczane dla zamiany kodu źródłowego na IL. C# jest bardzo podobny do Javy. Zawarta jest też wielka biblioteka klas, które zawierają całą funkcjonalność, która jest najbardziej potrzebna–programowania GUI Windowsa (Windows Forms), dostęp do bazy danych (ADO.NET), rozwój web (ASP.NET), Web services, XML itp..

 

 

Wersje .NET

 

 

.NET 1.1- 2003.

 

.NET 2.0- 2005.

 

.NET 3.0

 

.NET 3.5

 

.NET 4.0

 

 

Operacyjne systemy, na których działa .NET Framework

 

 

ASP.NET tylko jest wsparte na XP i Windows 2000/2003 i nowszych.

 

IIS nie jest wsparte naWindows XP Home Edition i nie może hostować ASP.NET. Jednak ASP.NET Web Matrix działa zamiast IIS na XP Home Edition.

 

.NET Compact Framework jest wersją .NET Framework dla urządzeń mobilnych, działających na Windows CE lub Windows Mobile.

 

Projekt Mono ma wersję .NET Framework, która działa na Linux.

 

 

Narzędzia dla rozwoju aplikacji .NET

 

 

Narzędzia .NET:

 

.NET Framework SDK zawiera kompilatory wiersza polecenia dla C++, C# i VB.NET i inne narzędzia do programowania.

 

SharpDevelop darmowe IDE dla C# i VB.NET.

 

Microsoft Visual Studio Express są wersjami ograniczonymi Visual Studio.

 

Microsoft Visual Studio Standard 2005.

 

Microsoft VIsual Studio Professional 2005

 

Microsoft Visual Studio Team Edition for Software Developers 2005 with MSDN Premium i Team Suite są edycjami najdroższymi.

 

 

CLI a CLR

 

 

Wspólna Infrastruktura Języka (Common Language Infrastructure, CLI) jest określeniem podstaw .NET framework, ktore zawierają:

 

– Wspólny System Typów (Common Type System, CTS)- wymóg, które ustala jak agent czasu urchomienia określa używa i zarządza typami (klasami).

 

– metadane

 

– Środowisko Wirtualnego Wykonania (Virtual Execution Environment, VES) i jego użycie dla

 

Intermediate Language (IL)

 

i wsparcie wielu języków programowania przez podzestaw cech, czyli

 

– Wspólna specyfikacja języka (Common Language Specification, CLS)

 

CLI jest dokumentowany przez ECMA.

 

Wspólne Środowisko Uruchomienia Języka (Common Language Runtime, CLR) jest podstawową implementacją CLI przez Microsoft. Microsoft też ma dzielone źródło implementacji zw. jako ROTOR dla celów edukacyjnych, a także .NET Compact Framework dla urządzeń mobilnych. Implementacje CLI nie-Microsoft CLI zawierają Mono and DotGNU Portable.NET.

 

Każde CLI zawiera:

 

– środowisko wykonania (VES)- środowisko, w którym typy są wykonywane

 

– system typów (CTS)- zestaw klas do użytkowania

 

– język pośredni (IL)- język, którego rozumie wirtualna maszyna

 

– specyfikacja języka (CLS)- wymogi dotyczące języków

 

– metadane- dane do opisu danych właściwych

 

Przykłady CLI:

 

– CLR z .NET Framework Microsoftu

 

– Mono dla Linuxa

 

– DotGNU Portable.NET dla Linuxa

 

 

2.2 What is IL?

 

 

IL = Intermediate Language, też znany jako MSIL (Microsoft Intermediate Language) lub CIL (Common Intermediate Language). Cały kod źródłowy .NET (jakiegokolwiek jezyka) jest kompilowany do IL podczas programowania. IL jest potem konwertowany do kodu maszynowego w miejscu, gdzie dany software jest instalowany lub (częściej) w czasie uruchomienia przez kompilator Just-In-Time (JIT).

 

 

C#

 

 

C# jest nowym językiem zaprojektowanym przez Micorsoft dla pracy z .NET framework. C# jest prostym, nowoczesnym, OO i bezpiecznego typu jezykiem pochodzącym z C i C++. Łączy wysoką wydajność Visual Basic i surową siłę C++.

 

 

Termin zarządzany w kontekście .NET

 

 

Termin zarządzany jest powodem zamieszania. Jest używany w różnych miejscach w .NET, znacząc co innego.

 

Zarządzany kod– .NET framework dostarcza kilka zasadnicznych usług czasu uruchomienia dla programów, które działają na tej platformie- np. obsługa wyjątku i bezpieczeństwo. Aby te usługi działały, dany kod musi dostarczać minimalnego poziomu informacji dla agenta czasu uruchomienia. Taki kod jest zw. zarządzanym kodem.

 

Zarządzane dane– To są dane, które są alokowane i uwalniane przez zbieracza śmieci agenta czasu uruchomienia .NET.

 

Zarządzane klasy– To zazwyczaj odnosi się w kontekście Managed Extensions (ME) dla C++. Kiedy używamy ME C++, klasa może być oznaczona słowem kluczowym __gc. Jak ta nazwa sugeruje, tzn., że pamięć dla instancji klasy jest zarządzana przez zbieracza śmieci, ale to też znaczy jeszcze więcej. Klasa staje się częścią społeczności .NET z korzyściami i ograniczeniami, jakie to pociąga za sobą. Przykładem korzyści jest należyte współdziałanie z klasami napisanymi w innych jezykach–np. zarządzana klasa C++ może dziedziczyć z klasy VB. Przykładem ograniczenia jest to, że zarządzana klasa może tylko dziedziczyć z klasy podstawowej.

 

 

Zestaw składowy

 

 

Zestaw składowy jest czasami opisywany jako logiczny .EXE lub .DLL i dlatego może być samodzielną aplikacją (z punktem wejścia main) lub niesamodzielną biblioteką. Zestaw składowy składa się z jednego lub więcej plików (pików dll, exe, html itp.) i reprezentuje grupę zasobów, definicje typów i implementacje tych typów. Zestaw składowy może też zawierać odniesienia do innych zestawów składowych. Te zasoby, typy i odniesienia są opisane w bloku danych zw. manifestem. Ten manifest jest częścią zestawu składowego, w ten sposób czyniąc dany zestaw składowy samoopisującym.

 

 

Zestaw składowy

 

bezpieczeństwo wersjowanie część tożsamości typu

 

================================================================

 

Dane właściwe

 

————————————————————————————————————-

 

aplikacja (.exe) biblioteka (.dll) zasób (html) odniesienie do innego zestawu

 

————————————————————————————————————-

 

Manifest (metadane opisujące dane właściwe)

 

 

Zestaw składowy zawiera:

 

.exe

 

.dll

 

.dll

 

.dll

 

.dll

 

.html

 

.html

 

.jpg

 

.png

 

odniesienie do zestawu 2

 

odniesienie do zestawu 3

 

 

Dlatego jego manifest będzie zawierał opis tego:

 

1 plik wykonywalny

 

3 biblioteki

 

2 pliki zasobu html

 

2 pliki zasobu grafiki w dwóch różnych formatach

 

 

Tożsamość typu = Zestaw składowy + Nazwa typu (przestrzeń nazwy)

 

 

Ważnym aspektem zestawów składowych jest to, że one są częścią tożsamości typu. Tożsamość typu jest zestawem składowym, który mieści to razem z nazwą typu. Tzn., że np. jeśli zestaw składowy A eksportuje typ zw. T i zestaw składowy B eksportuje typ zw. T, agent czasu uruchomienia .NET widzi je jako dwa kompletnie różne typy, bo pochodzą z różnych zestawów składowych. Co więcej nie mieszajmy zestawów składowych i przestrzeni nazw–przestrzenie nazw są po prostu hierarchicznym sposobem organizowania nazw typów. Dla agenta czasu uruchomienia nazwy typów są nazwami typów bez względu na to, czy przestrzenie nazw są użyte do organizowania tych nazw. To jest zestaw składowy plus nazwa typu (bez względu na to czy nazwa typu należy do przestrzeni nazwy), które unikalnie identyfikują typ dla agenta czasu uruchomienia.

 

Zestawy składowe są też ważne w .NET w odniesieniu do bezpieczeństwa–wiele ograniczeń bezpieczeństwa jest wymuszanych w granicach zestawu składowego.

 

Ostatecznie zestawy składowe są jednostką wersjowania w .NET.

 

 

Tworzenie zestawu składowego

 

 

Najprostszą drogą dla wytwarzania zestawu składowego jest bezpośrednio z kompilatora .NET. Np. następujący program C#:

 

public class CTest

 

{

 

public CTest()

 

{

 

System.Console.WriteLine( “Hello from CTest” );

 

}

 

}

 

może być skompilowany w bibliotekę zestawu składowego (dll) tak:

 

csc /t:library ctest.cs

 

Możemy wobec tego przejrzeć zawartość zestawu składowego przez uruchomienie narzędzia “IL Disassembler”, które jest z .NET SDK.

 

Alternatywnie możemy skompilować nasze źródło na moduły i potem połączyć te moduły w zestaw składowy przy użyciu assembly linker (al.exe). Dla kompilatora C# przełącznik /target:module jest użyty dla generacji modułu zamiast zestawu składowego.

 

csc /target:module ctest.cs

 

 

moduł1 moduł2 moduł3

 

——————————————————————————————————–

 

assembly linker

 

——————————————————————————————————–

 

Zestaw składowy

 

 

Opis szczegółowy części kodu:

 

public class CTest

 

{

 

public CTest() { System.Console.WriteLine( “Hello from CTest” ); }

 

}

 

 

public class CTest

 

określnik dostępności kodu chodzi o klasę nazwa klasy

 

public CTest() { System.Console.WriteLine( “Hello from CTest” ); }

 

określnik dostępności kodu chodzi o klasę Metoda Argumenty

 

csc /t:library ctest.cs

 

kompilator przełącznik (tworzenie biblioteki) klasa

 

csc /target:module ctest.cs

 

kompilator przełącznik (tworzenie modułu) klasa

 

 

Kod generowany automatycznie przez Visual Studio (dla Windows application):

 

 

using System;

 

using System.Collections.Generic;

 

using System.Windows.Forms;

 

 

namespace Example1

 

{

 

static class Program

 

{

 

///<summary>

 

///The main entry point for the application

 

///</summary>

 

[STAThread]

 

static void Main()

 

{

 

Application.EnableVisualStyles();

 

Application.SetCompatibleTextRenderingDefault(false);

 

Application.Run(new Form1());

 

}

 

}

 

}

 

Puste okno bez funkcjonalności.

 

 

solution

 

——————————————————————————————————

 

projekt (application) projekt (application) projekt (application)

 

——————————————————————————————————-

 

klasa1 klasa2 klasa3 klasa1 klasa2 klasa1 klasa2 klasa3 klasa4

 

 

np.

 

samochód

 

——————————————————————————————————–

 

układ hamulcowy układ sterowania układ napędowy

 

——————————————————————————————————–

 

pedał tarcze linki kierownica linki tłoki świece wał wtryski

 

 

 

Zestaw składowy typu private a zestaw składowy typu shared

 

 

Terminy ‘private’ i ‘shared’ odnoszą się do tego jak zestaw składowy jest stosowany, a nie są to jakiekolwiek wewnętrzne atrybuty zestawu składowego.

 

Zestaw składowy typu private jest normalnie używany przez pojedynczą aplikację i jest przechowywany w katalogu aplikacji lub podkatalogu. Zestaw składowy typu shared jest przeznaczony do użytku przez wiele aplikacji i jest normalnie przechowywany w global assembly cache (GAC), co jest centralnym repozytorium dla zestawów składowych. Zestawy składowe typu shared mogą też być przechowywane poza GAC, w którym to przypadku każda aplikacja musi być wskazana do swojej lokacji przez wpis codebase w pliku konfiguracyjnym aplikacji. Zasadniczą korzyścią stosowania zestawów składowych dla GAC jest to, że GAC może wspierać wiele wersji tego samego zestawu składowego obok siebie.

 

Zestawy składowe stosowane dla GAC muszą być strong-named. Poza GAC strong-naming jest opcjonalny.

 

aplikacja

 

—————————————————————————————————–

 

zestaw składowy typu private

 

 

 

aplikacja aplikacja aplikacja

 

wpis w codebase wpis codebase wpis w codebase

 

—————————————————————————————————–

 

zestaw składowy typu shared zestaw składowy typu shared

 

strong-named strong-named

 

 

 

aplikacja aplikacja aplikacja

 

—————————————————————————————————-

 

GAC

 

—————————————————————————————————–

 

zestaw składowy typu shared zestaw składowy typu shared

 

 

Odnajdywanie zestawów składowych przez inne zestawy składowe

 

 

Dokonuje się to przez ścieżki katalogów. Jest kilka czynników, które mogą wpływać na tę ścieżkę (taki jak host AppDomain i pliki konfiguracyjne aplikacji), ale dla zestawów składowych weakly named ścieżka poszukiwania jest normalnym katalogiem aplikacji i jego podkatalogów. Dla zestawów składowych strongly named, ścieżka poszukiwania jest GAC, a potem jest ścieżka zestawu składowego typu private.

 

 

Działanie wersjowania zestawu składowego

 

 

Zestaw składowy ma numer wersji składający się z czterech części np. 1.0.350.1. To jest zwykle interpretowane jako Major.Minor.Build.Revision, ale to jest tylko konwencja. CLR nie stosuje żadnych ograniczeń wersji na zestawy składowe weakly named, więc wersja zestawu składowego nie ma rzeczywistego znaczenia.

 

Dla zestawów składowych strongly named, wersja odniesionego (referred, czyli do którego jest odniesienie) zestawu składowego jest przechowywana w odnoszącym się (referring, czyli który odnosi się) zestawie składowym i domyślnie tylko ta dokładnie wersja będzie załadowana w czasie uruchomienia. Jeśli dokładnie ta wersji nie jest dostępna, odnoszący (referring) zestaw składowy nie załaduje innego zestawu składowego z inną wersją.

 

Jest możliwe nadpisać to zachowanie w pliku config dla odnoszącego (który ma odniesienie) zestawu składowego–odniesienia do pojedynczej wersji lub zakresu wersji odniesionego zestawu składowego mogą być przekierowane do konkretnej wersji. Np. wersja1.0.0.0 do 2.0.0.0 może być przekierowana do wersji 3.0.125.3. Jednak nie ma żadnego sposobu do określenia zakresu wersji, do których można by przekierować się.

 

Pliki publisher policy oferują alternatywny mechanizm dla przekierowania do różnych wersji zastosowanych zestawów składowych do GAC–plik publisher policy pozwala dla publisher zestawu składowego na przekierowanie wszystkich aplikacji do nowej wersji zestawu składowego za pomocą jednej operacji, raczej niż przymus modyfikowania wszystkich plików konfiguracyjnych tej aplikacji.

 

Ograniczenia w version policy dla zestawów składowych strongly named może powodować problemy, kiedy dostarczamy łat lub ‘hot fixes’ dla konkretnych zestawów składowych w aplikacji. Aby uniknąć przymusu zmian w pliku config lub plikach publisher policy razem z hot fix, to ma sens dla ponownego użycia wersji tego samego zestawu składowego dla hot fix. Jeśli chcemy, zestawy składowe mogą być rozróżniane przez zamienienie wersji pliku danego zestawu składowego, który nie jest użyty w ogóle przez CLR dla stosowania version policy.

 

Wersjowanie zestawów składowych strongly named stosuje się czy zestawy składowe są stosowane privately czy do GAC.

 

 

Rozwijanie aplikacji, które automatycznie aktualizują się z Web

 

 

Dla .NET 2.x używamy ClickOnce.

 

 

Domena aplikacji (application domain)

 

 

AppDomain może być traktowany jako proces typu lightweight. Wiele AppDomains może istnieć w przetwarzaniu procesów Win32. Podstawowym celem AppDomain ma być izolowanie aplikacji jedna od drugiej a zatem to jest szczególnie użyteczne w hostowaniu scenariuszy takich jak ASP.NET. AppDomain może być zniszczona przez hosta bez wpływu na inne AppDomains w danym procesie. Procesy Win32 dostarczają izolacji przez posiadanie odrębnych przestrzeni adresowych w pamięci. To jest efektywne, ale drogie. Ale środowisko uruchomienia .NET wymusza izolację AppDomain przez trzymanie kontroli nad użyciem pamięci–cała pamięć w AppDomain jest zarządzana przez agenta czasu uruchomienia .NET, więc ten agent uruchomienia może zapewnić, że AppDomains nie mają dostępu do swoich kawałków pamięci.

 

Win32

 

———————————————————————————————–

 

adres pamięci 1 adres pamięci adres pamięci 3

 

| | |

 

Proces Proces Proces

 

 

.NET

 

———————————————————————————————–

 

AppDomain AppDomain AppDomain

 

| | |

 

Proces Proces Proces

 

 

Jednym nieoczywistym użyciem AppDomains jest wyładowanie typów. W rzeczywistości jedynym sposobem na wyładowanie typu .NET ma być zniszczenie AppDomain, do której jest załadowany. To jest szczególnie użyteczne, jeśli tworzymy i niszczymy typy na bieżąco z pomocą reflection. Jest to zdolność do dostarczenia informacji o typie w czasie uruchomienia, przeważnie aby klient mógł odnaleźć członków (metody, pola właściwości, zdarzenia i zagnieżdżone typy typu). To pozwala też, aby te członki mogły być odnoszone w czasie uruchomienia i to pozwala na określenie nowych typów, które mogą być zapisane na dysku.

 

 

 

Tworzenie AppDomain

 

 

AppDomains są zazwyczaj tworzone przez hosty. Przykładami hostów są Windows Shell, ASP.NET i IE. Kiedy uruchamiamy aplikację .NET z wiersza polecenia, tym hostem jest Shell. Shell tworzy nową AppDomain dla każdej aplikacji.

 

AppDomains mogą być też wyraźnie tworzone przez aplikacje .NET. Oto jest sampl C#, który tworzy AppDomain, tworzy instancje obiektu wewnątrz tego i potem wykonuje jedną z metod obiektu:

 

using System;

 

using System.Runtime.Remoting;

 

using System.Reflection;

 

 

public class CAppDomainInfo : MarshalByRefObject

 

{

 

public string GetName() { return AppDomain.CurrentDomain.FriendlyName; }

 

}

 

 

public class App

 

{

 

public static int Main()

 

{

 

AppDomain ad = AppDomain.CreateDomain( “Andy’s new domain” );

 

CAppDomainInfo adInfo = (CAppDomainInfo)ad.CreateInstanceAndUnwrap(

 

Assembly.GetCallingAssembly().GetName().Name, “CAppDomainInfo” );

 

Console.WriteLine( “Created AppDomain name = ” + adInfo.GetName() );

 

return 0;

 

}

 

}

 

 

Pisanie własnego hosta .NET

 

 

Np. patrzymy na źródło dla dm.net moniker zaprojektowany przez Jason Whittington i Don Box. Są też sample kodu w .NET SDK zw. CorHost.

 

 

Zbieracz śmieci

 

 

Zbieranie śmieci jest strategią zarządzania stertą, gdzie komponent agenta czasu uruchomienia bierze odpowiedzialność za zarządzanie czasem życia pamięci używanej przez obiekty. Nie tylko .NET i Java mają to, ale i inne języki i środowiska uruchomienia.

 

 

Obiekty nie są zawsze niszczone natychmiast, kiedy ostatnie odniesienie znika

 

 

Zbieracz śmieci nie oferuje żadnych gwarancji w sprawie czasu, kiedy obiekt bedzie zniszczony i pamięć odzyskana.

 

 

Agent czasu uruchomienia .NET nie oferuje deterministycznej destrukcji

 

 

Nie oferuje deterministyczne destrukcji z powodu algorytmu zbieracza śmieci. Pracuje on co pewien czas przechodząc przez listę wszystkich obiektów, które są aktualnie odnoszone przez aplikację. Wszystkie te obiekty, których nie znajdzie podczas tego przeszukiwania, są gotowe do zniszczenia a ich pamięć do odzyskania. Implikacja tego algorytmu jest taka, że agent czasu uruchomienia nie jest informowany natychmiast, kiedy ostatnie odniesienie do obiektu zostaje usunięte–to tylko dowiaduje się podczas następnego przeszukania sterty.

 

Co wiecej ten typ algorytmu działa najlepiej przez wykonanie szukania zbieracza śmieci tak rzadko jak to tylko możliwe. Normalnie zużycie sterty jest inicjatorem do wymiecenia zbioru ze śmieci.

 

Aplikacja

 

——————————————————————————————————–

 

| | | |

 

obiekt1 obiekt2 obiekt3 obiekt4 obiekt5

 

———————————————————————————————————->

 

Zbieracz śmieci zabiera obiekt2 po przejściu listy obiektów

 

 

Czy brak deterministycznej destrukcji jest problemem?

 

 

To zapewne wpływa na projekt komponentu. Jeśli mamy obiekty, które utrzymują drogie i rzadkie zasoby (np. database locks), musimy dostarczać pewnego sposobu na kazanie obiektowi uwolnić dany zasób, kiedy jest zrobione, co należy. Microsoft zaleca nam dostarczanie metody zw. Dispose() dla tego celu. Jednak to powoduje problemy dla dystrybuuowanych obiektów–w dystrybuowanym systemie, który wywołuje metodę Dispose() pewna forma mechanizmu obliczanie odniesień (reference-counting) lub zarządzanie posiadaniem (ownership-management) jest potrzebna do obsługi dystrybuowanych obiektów–na nieszczęście agent czasu uruchomienia nie oferuje żadnej pomocy co do tego.

 

 

Czy trzeba implementować Finalize (finalizowanie) w naszej klasie? Czy trzeba implementować IDisposable?

 

 

To zagadnienie jest nieco bardziej skompliowane niż to się wydaje. Są naprawdę dwie kategorie klasy, które wymagają deterministycznej destrukcji–pierwsza kategoria manipuluje niezarządzanymi typami bezpośrednio, gdy ta druga kategoria manipuluje zarządzanymi typami, który wymagają deterministycznej destrukcji. Przykładem pierwszej kategorii jest klasa z członkiem IntPtr reprezentującym handler pliku SO. Przykładem drugiej kategorii jest klasa z członkiem System.IO.FileStream.

 

Dla tej pierwszej kategorii to ma sens implementować IDisposable i nadpisać Finalize. To pozwala użytkownikowi obiektu na zrobienie właściwej rzeczy (‘do the right thing’) przez wywołanie Dispose, ale też dostarcza wycofania z uwolnienia niezarządzanego zasobu w Finalizer, jeśli wywołujący kod zawiedzie w swoich obowiązkach. Jednak ten logic nie stosuje się do drugiej kategorii klasy z tylko zarządzanymi zasobami. W tym wypadku implementacja Finalize jest bezcelowa, bo obiekty zarządzanych członków nie mogą być dostępne w Finalizer. To jest ponieważ nie ma gwarancji, że wykonanie Finalizera jest nakazane. Tak więc tylko metoda Dispose powinna być implementowana. Jeśli myślimy o tym, to w rzeczywistości nie ma sensu wywoływać Dispose na obiekty członków z Finalizera w każdym przypadku, bo Finalizer obiektu członka zrobi wymagane czyszczenie.

 

Pewni programiści argumentują, że implementowanie Finalizera jest zawsze złym pomysłem, bo to ukrywa błąd w naszym kodzie (brak wywołania Dispose). Mniej radykalnym podejściem jest implementacja Finalize, ale zawarcie Debug.Assert na początku, w ten sposób sygnalizując problem w budowaniu dla programisty, ale pozwalając na to, aby czyszczenie pojawiało się w wersjach budowań.

 

 

Kontrola na algorytmem zbieracza śmieci

 

 

Mamy niewielką kontrolę. Np. klasa System.GC ujawnia metodę Collect, która zmusza zbieracza śmieci do zbierania natychmiast wszystkich nieodniesionych obiektów.

 

Także jest ustawienie gcConcurrent, które może być określone przez plik konfiguracyjny aplikacji. To określa, czy lub nie zbieracz śmieci wykonuje pewne swoje działania na oddzielnym wątku. To ustawienie tylko odnosi się do maszyn wieloprocesorowych i domyślnie jest ustawione na true.

 

 

Wiedza, co zbieracz śmieci robi

 

 

Wiele interesujących statystyk jest ujawnianych z agenta czasu uruchomienia .NET przez liczniki wykonania ‘.NET CLR xxx‘. Używamy Performance Monitor, aby to widzieć.

 

 

Co to jest problem lapsed listener?

 

 

Lapsed listener problem jest jednym z powodów wyciekania w aplikacjach .NET. To dzieje się, kiedy subskrybent (lub słuchacz, czyli listener) podpisuje zdarzenia dla publishera, ale nie kończy z tym. Ten błąd bez skończenia znaczy, że publisher utrzymuje odniesienie do subskrybenta (słuchacza) tak długo jak publisher żyje. Dla pewnych publisherów to może trwać cały czas trwania aplikacji.

 

Ta sytuacja powoduje dwa problemy. Wyciekanie obiektu subskrybenta. Innym problemem jest obniżenie wykonania z powodu wysyłania zbytecznych powiadomień przez publishera do subskrybentów, które są ‘zombie’.

 

Jest przynajmniej kilka rozwiązań tego problemu. Najlepiej jest upewnić się, że subskrybent zakończył subskrypcję z publisherem, typowo przez dodanie metody Unsubscribe() dla tego subskrybenta. Innym rozwiązaniem jest zmiana publishera dla użycia słabych odnisień w swojej liście subskrybenta.

 

 

Kiedy używamy GC.KeepAlive

 

 

To jest bardzo niewyczuwalne, ale agent czasu uruchomienia może decydować, że dany obiekt jest śmieciem wcześniej, niż tego oczekujemy. Obiekt może stać się śmieciem, gdy metoda jest wykonywana na tym obiekcie, co jest przeciw oczekiwaniom programistów, bo taki obiekt musi istnieć.

 

Np. mamy kod i rozwijamy go do pełnej aplikacji:

 

using System;

 

using System.Runtime.InteropServices;

 

 

class Win32

 

{

 

[DllImport(“kernel32.dll”)]

 

public static extern IntPtr CreateEvent( IntPtr lpEventAttributes,

 

bool bManualReset,bool bInitialState, string lpName);

 

 

[DllImport(“kernel32.dll”, SetLastError=true)]

 

public static extern bool CloseHandle(IntPtr hObject);

 

 

[DllImport(“kernel32.dll”)]

 

public static extern bool SetEvent(IntPtr hEvent);

 

}

 

 

class EventUser

 

{

 

public EventUser()

 

{

 

hEvent = Win32.CreateEvent( IntPtr.Zero, false, false, null );

 

}

 

 

~EventUser()

 

{

 

Win32.CloseHandle( hEvent );

 

Console.WriteLine(“EventUser finalized”);

 

}

 

 

public void UseEvent()

 

{

 

UseEventInStatic( this.hEvent );

 

}

 

 

static void UseEventInStatic( IntPtr hEvent )

 

{

 

//GC.Collect();

 

bool bSuccess = Win32.SetEvent( hEvent );

 

Console.WriteLine( “SetEvent ” + (bSuccess ? “succeeded” : “FAILED!”) );

 

}

 

 

IntPtr hEvent;

 

}

 

 

class App

 

{

 

static void Main(string[] args)

 

{

 

EventUser eventUser = new EventUser();

 

eventUser.UseEvent();

 

}

 

}

 

Jeśli uruchomimy ten kod, prawdopodobnie będzie działał jak trzeba i dostaniemy takie dane wyjściowe:

 

SetEvent succeeded

 

EventDemo finalized

 

Jednak jeśli odkomentujemy wywołanie GC.Collect() w metodzie UseEventInStatic(), otrzymamy takie dane wyjściowe:

 

EventDemo finalized

 

SetEvent FAILED!

 

(Trzeba użyć release build, aby odtworzyć ten problem.)

 

Co się tu stało? W punkcie, gdzie metoda UseEvent() wywołuje UseEventInStatic(), kopia jest wzięta pola (zmiennej) hEvent i nie ma żadnych innych odniesień do obiektu EventUser gdziekolwiek w tym kodzie. Tak więc jak długo mamy do czynienia z agentem czasu uruchomienia, obiekt EventUser jest śmieciem i może być zabrany. Normalnie zbieranie nie zdarzy się natychmiast, więc pozbędziemy się tego, ale wcześniej czy później zbieranie zdarzy się w złym czasie i nasza aplikacja nie uda się.

 

Rozwiązaniem tego jest dodanie wywołania do GC.KeepAlive(this) na koniec metody UseEvent.

 

 

Serializacja

 

 

Serializacja jest procesem konwertowania obiektu na strumień bajtów. Deserializacja jest procesem odwrotnym, czyli tworzeniem obiektu ze strumienia bajtów. Serializacja/deserializacja jest głównie używana do transportu obiektów (np. podczas remoting) lub do trwania obiektów (np. dla pliku lub bazy danych).

 

 

.NET Framework ma wbudowane wsparcie dla serializacji

 

 

Są dwa oddzielne mechanizmy dostarczane przez bibliotekę klasy .NET–XmlSerializer i SoapFormatter/BinaryFormatter. Microsoft używa XmlSerializer dla Web Services i SoapFormatter/BinaryFormatter dla remoting. Oba są dostępne do użycia w naszym własnym kodzie.

 

 

Czy w trakcie serializacji instancji naszej klasy powinniśmy używać XmlSerializer, SoapFormatter lub BinaryFormatter?

 

 

To zależy. XmlSerializer ma ostre ogarniczenia takie jak wymaganie, że klasa docelowa ma konstruktora bezparametrowego i tylko właściwości i pola public read/write mogą być serializowane. Jednak po stronie plusów XmlSerializer ma dobre wsparcie dla dostosowania dokumentu XML, który jest produkowany lub konsumowany. Cechy XmlSerializer znaczą, że to jest najbardziej odpowiednie dla pracy między platformami lub dla konstruowania obiektów z istniejących dokumentów XML.

 

SoapFormatter i BinaryFormatter mają mniejsze ograniczenia niż XmlSerializer. One mogą np. serializować pola private. Jednak one obaj wymagają, że klasa docelowa jest oznaczona z atrybutem [Serializable], więc jak w przypadku XmlSerializer, klasa potrzebuje być napisaną z myślą o serializacji. Także są pewne wybiegi dla uwagi–np. przy deserializacji konstruktor nowego obiektu nie jest wywolywany.

 

Wybór między SoapFormatter i BinaryFormatter zależy od aplikacji. BinaryFormatter ma sens, gdzie zarówno serializacja i deserializacja będzie wykonywana na platformie .NET i gdzie wykonanie jest ważne. SoapFormatter generalnie ma większy sens we wszystkich innych przypadkach dla łatwego debugowania, jeśli nic innego.

 

 

Możemy dostosować proces serializowania

 

 

XmlSerializer wspiera atrybuty, które mogą być użyte do konfigurowania serializacji dla konkretnej klasy. Np. pole i właściwość może być oznaczony z atrybutem [XmlIgnore] dla wykluczenia tego z serializacji. Innym przykładem jest atrybut [XmlElement], który może być użyty dla określenia nazwy elementu XML dla użycia dla konkretnej właściwości lub pola.

 

Serializacja przez SoapFormatter/BinaryFormatter może być kontrolowana w pewnym stopniu przez atrybuty. Np. atrybut [NonSerialized] jest ekwiwalentem atrybutu [XmlIgnore] dla XmlSerializer. Podstawowa kontrola procesu serializacji może być osiągnięta przez implementowanie interfejsu ISerializable na klasie, której instancje mają być serializowane.

 

 

XmlSerializer jest wolny

 

 

Jest jeden na proces, na typ koszt ogólny z XmlSerializer. Tak więc za piewrszym razem, kiedy serializujemy i deserializujemy obiekt danego typu w aplikacji, jest znaczące opóźnienie. To jest normalnie bez znaczenia, ale to może znaczyć np. że XmlSerializer jest złym wyborem dla załadowania ustawień konfiguracji podczas uruchomienia aplikacji GUI.

 

 

Błędy, kiedy próbujemy serializować Hashtable

 

 

XmlSerializer odmówi serializowania instancji jakiejkolwiek klasy, która implementuje IDictionary, np. Hashtable. SoapFormatter i BinaryFormatter nie mają tego ograniczenia.

 

 

XmlSerializer wyrzuca ogólny błąd “There was an error reflecting MyClass”.

 

 

Patrzymy na właściwość InnerException wyjątku, który jest wyrzucany dla otrzymania bardziej określonej wiadomości o błędzie.

 

 

Dostajemy InvalidOperationException, kiedy serializujemy ArrayList

 

 

XmlSerializer musi wiedzieć zawczasu, jaki typ obiektów to znajdzie w ArrayList. Aby określić ten typ, używamy atrybutu XmlArrayItem jak ten:

 

public class Person

 

{

 

public string Name;

 

public int Age;

 

}

 

 

public class Population

 

{

 

[XmlArrayItem(typeof(Person))] public ArrayList People;

 

}

 

 

Atrybuty

 

 

Są przynajmniej dwa typy atrybutu .NET. Pierwszy typ odnosi się jako atrybut metadanych–to pozwala pewnym danym być dołączonym do klasy lub metody. Te dane stają się częścią metadanych dla tej klasy i (jak inne metadane klasy) mogą być dostępne przez reflection. Przykładem atrybutu metadanych jest [serializable], który może być dołączony do klasy i znaczy, że instancje tej klasy mogą być serializowane.

 

[serializable] public class CTest {}

 

Innym typem atrybutu jest atrybut context. Atrybuty context używają podobnej składni do atrybutów metadanych, ale one są zasadniczo różne. Atrybuty context dostarczają mechanizmu przejęcia, przez który aktywacja instancji i wywołania metody mogą być przed i/lub potem przetwarzane.

 

 

Tworzenie własnych atrybutów metadanych

 

 

Po prostu wywodzimy klasę z System.Attribute i oznaczamy ją atrybutem AttributeUsage. Np.:

 

[AttributeUsage(AttributeTargets.Class)]

 

public class InspiredByAttribute : System.Attribute

 

{

 

public string InspiredBy;

 

 

public InspiredByAttribute( string inspiredBy )

 

{

 

InspiredBy = inspiredBy;

 

}

 

}

 

 

[InspiredBy(“Andy Mc’s brilliant .NET FAQ”)]

 

class CTest

 

{

 

}

 

 

class CApp

 

{

 

public static void Main()

 

{

 

object[] atts = typeof(CTest).GetCustomAttributes(true);

 

 

foreach( object att in atts )

 

if( att is InspiredByAttribute )

 

Console.WriteLine( “Class CTest was inspired by {0}”, ((InspiredByAttribute)att).InspiredBy );

 

}

 

}

 

 

Tworzenie własnych atrybutów context

 

 

Patrzymy na Peter Drayton’s Tracehook.NET.

 

 

 

Code Access Security (CAS)?

 

 

CAS jest częścią modelu bezpieczeństwa .NET, który określa czy lub nie kod może być uruchomiony i jakie zasoby może używać, kiedy jest uruchomiony. Np. To CAS, który chroni .NET web applet od formatowania naszego twardego dysku.

 

 

Działanie CAS

 

 

Strategia polityki CAS zawiera dwa kluczowe koncepty–grupy kodu (code groups) i prawa (permissions). Każdy zestaw składowy .NET jest członkiem konkretnej grupy kodu i każda grupa kodu jest obdarzona prawami określonymi w named permission set.

 

Np. używanie domyślnej strategii bezpieczeństwa, kontroli ściagniętej z witryby web należy do grupy kodu ‘Zone – Internet’, która przystaje do praw określonych przez named permission set ‘Internet’. (Naturalnie named permission set ‘Internet’ reprezentuje bardzo restrykcyjny zakres praw).

 

 

Kto określa grupy kodu CAS?

 

 

Microsoft określa pewne domyślne grupy kodu, ale możemy je modyfikować i nawet tworzyć swoje własne. Aby zobaczyć grupy kodu określone na naszym systemie, uruchamiamy caspol -lg z wiersza polecenia.

 

Level = Machine

 

 

Code Groups:

 

 

1. All code: Nothing

 

1.1. Zone – MyComputer: FullTrust

 

1.1.1. Honor SkipVerification requests: SkipVerification

 

1.2. Zone – Intranet: LocalIntranet

 

1.3. Zone – Internet: Internet

 

1.4. Zone – Untrusted: Nothing

 

1.5. Zone – Trusted: Internet

 

1.6. StrongName –

 

0024000004800000940000000602000000240000525341310004000003

 

000000CFCB3291AA715FE99D40D49040336F9056D7886FED46775BC7BB5430BA4444FEF8348EBD06

 

F962F39776AE4DC3B7B04A7FE6F49F25F740423EBF2C0B89698D8D08AC48D69CED0FC8F83B465E08

 

07AC11EC1DCC7D054E807A43336DDE408A5393A48556123272CEEEE72F1660B71927D38561AABF5C

 

AC1DF1734633C602F8F2D5: Everything

 

 

Patrzymy na hierarchię grup kodów–szczyt hierarchii jest najbardziej ogólny (‘All code’), który jest podem dzielony na kilka grup, z których każda po kolei może być znowu dzielona. Także widzimy, że (nieco przeciw intuicyjnie) podgrupa może być skojarzona z bardziej dopuszczalnym zestawem praw niż jego rodzic.

 

 

Jak definiujemy naszą własną grupę kodu?

 

 

Używamy caspol. Np. zakładamy, że mamy trust code z http://www.mydomain.com i chcemy, aby to miało pełny dostęp do naszego systemu, ale chcemy trzymać domyślne ograniczenia dla wszystkich innych witryn internetowych. Aby to osiągnąć, dodalibyśmy nową grupę kodu jako podgrupę grupy ‘Zone – Internet’ w ten sposób:

 

caspol -ag 1.3 -site http://www.mydomain.com FullTrust

 

Teraz jeśli uruchomimy caspol -lg, zobaczymy, że ta nowa grupa została dodana jako grupa 1.3.1:

 

 

1.3. Zone – Internet: Internet

 

1.3.1. Site – http://www.mydomain.com: FullTrust

 

 

Numeryczna etykieta (1.3.1) jest tylko inwencją caspol dla uczynienia grup kodu łatwymi do manipulacji z wiersza polecenia. Podległy agent czasu uruchomienia nigdy nie widzi tego.

 

 

Zmienianie zestawu praw dla grupy kodu

 

 

Używamy caspol. Jeśli jesteśmy administratorem maszyny, możemy operować na poziomie maszyny, co znaczy, że nie tylko zmiany, które zrobimy staną się domyślne dla naszej maszyny, ale też użytkownicy nie mogą zmieniać tych praw, aby były bardziej dopuszczające. Jeśli jesteśmy zwykłymi użytkownikami, możemy ciagle modyfikować te prawa, ale tylko dla uczynienia ich bardziej ograniczonymi. Np. aby pozwolić kodowi intranet zrobić to, co lubi, możemy zrobić to:

 

caspol -cg 1.2 FullTrust

 

Ponieważ to jest bardziej przyzwalające niż strategia domyślna (na standardowym systemie), powinniśmy tylko zrobić to na poziomie maszyny–robiąc to na poziomie użytkownika nie będzie miało efektu.

 

 

Czy możemy zrobić nasz własny zestaw praw?

 

 

Tak, używamy

 

caspol -ap

 

określajac plik XML zawierający prawa w zestawie praw. Aby oszczędzić nam pewien czas ściągamy sampel z Internetu i dodajemy to do dostępnych zestawów praw jak to:

 

caspol -ap samplepermset.xml

 

Potem, aby dodać zestaw praw do grupy kodu, robimy tak:

 

caspol -cg 1.3 SamplePermSet

 

(Domyślnie, 1.3 jest grupą kodu ‘Internet’)

 

 

Problemy z CAS

 

 

Caspol ma kilka opcji, które mogą pomóc. Możemy pytać caspol, który powie do jakiej grupy kodu zestaw składowy należy, używając

 

caspol -rsg

 

Podobnie możemy pytać jakie prawa są stosowane do konkretnego zestawu składowego używając

 

caspol -rsp

 

 

Wyłączenie CAS

 

 

Jeśli jesteśmy administratorami, po prostu uruchamiamy

 

caspol -s off

 

 

 

Bierzemy IL dla zestawu składowego

 

 

MS daje narzędzie zw. Ildasm, które może być użyte, aby przejrzeć metadane i IL dla zestawu składowego.

 

 

Odwrócenie kodu źródłowego z IL

 

 

Jest prosto odtworzyć źródło wysokiego poziomu z IL. Np. Reflector dobrze zamienia IL na C# lub VB.NET.

 

 

Uniemożliwienie odwrócenia kodu źródłowego z IL

 

 

Możemy kupić narzędzie zw. IL obfuscation. Te narzędzia działają przez optymizowanie IL w taki sposób, że odwrócenie jest dużo trudniejsze. Oczywiście piszemy web services, potem odwrócenie nie jest problemem, ale klienci nie mają dostępu do naszego IL na serwerze.

 

 

Pisanie programów IL bezpośrednio

 

 

Przykład:

 

.assembly MyAssembly {}

 

.class MyApp {

 

.method static void Main() {

 

.entrypoint

 

ldstr “Hello, IL!”

 

call void System.Console::WriteLine(class System.Object)

 

ret

 

}

 

}

 

Wstawiamy to do pliku zw. hello.il i potem uruchamimy ilasm hello.il. Zostanie wygenerowany zestaw składowy exe.

 

 

Są rzeczy, które zrobimy w IL, a których nie zrobimy w C#

 

 

Np. możemy wyrzucać wyjątki, które nie pochodzą z System.Exception i możemy mieć tablice oparte na wartościach niezerowych (non-zero-based arrays).

 

 

.NET zastępuje COM

 

 

.NET ma swój własny mechanizmy dla interakcji typu i on nie używa COM. Nie ma IUnknown, IDL, typelibs, ani aktywacji opartej na rejestrze. .NET pozwala nam pakować i używać komponentów w podobny sposób do COM, ale łatwiej.

 

 

DCOM

 

 

DCOM jest w zasadzie nieaktualny dla programistów .NET..NET Framework ma nowy model remoting, który nie jest oparty na DCOM. DCOM jest w zasadzie martwy, kiedy firewalle rozpowszechniły się i Microsoft zainteresował się SOAP. DCOM będzie ciągle używany w scenariuszach współpracy.

 

 

COM+

 

 

COM+ zniknie nie od razu. .NET 1.0 dawało dostęp do istniejących usług COM+ (przez interop layer), niż zastąpić te usługi z natywnymi z .NET. Różne narzędzia i atrybuty są dla ułatwienia interakcji z COM+. Z czasem to będzie jedno, czyli te usługi wejdą do jądra CLR i to może znaczyć, że pewne usługi będą ponownie napisane jako zarządzany kod, który działa na szczycie CLR.

 

 

Używanie komponentów COM z programów .NET

 

 

Komponenty COM są dostępne dla agenta czasu ruchomienia przez Runtime Callable Wrapper (RCW). Ten wrapper zamienia interfejsy COM ujawnione przez komponent COM na interfejsy kompatybilne z .NET.

 

Dla interfejsów oleautomation RCW może być generowany automatycznie z biblioteki typów.

 

Dla interfejsów nie będących interfejsami oleautomation może być potrzebne rozwijanie dostosowanego RCW, który ręcznie mapuje te typy ujawnione przez interfejs COM na typy kompatybilne z .NET.

 

Przykład dla obeznanych z ATL. Najpierw tworzymy komponent ATL, który implementuje nastepujące IDL:

 

import “oaidl.idl”;

 

import “ocidl.idl”;

 

 

[

 

object,

 

uuid(EA013F93-487A-4403-86EC-FD9FEE5E6206),

 

helpstring(“ICppName Interface”),

 

pointer_default(unique),

 

oleautomation

 

]

 

 

interface ICppName : IUnknown

 

{

 

[helpstring(“method SetName”)] HRESULT SetName([in] BSTR name);

 

[helpstring(“method GetName”)] HRESULT GetName([out,retval] BSTR *pName );

 

};

 

 

[

 

uuid(F5E4C61D-D93A-4295-A4B4-2453D4A4484D),

 

version(1.0),

 

helpstring(“cppcomserver 1.0 Type Library”)

 

]

 

library CPPCOMSERVERLib

 

{

 

importlib(“stdole32.tlb”);

 

importlib(“stdole2.tlb”);

 

[

 

uuid(600CE6D9-5ED7-4B4D-BB49-E8D5D5096F70),

 

helpstring(“CppName Class”)

 

]

 

coclass CppName

 

{

 

[default] interface ICppName;

 

};

 

};

 

Kiedy zbudujemy ten komponent, powinniśmy dostać typelibrary. Uruchamiamy narzędzie TLBIMP w tym typelibary tak:

 

tlbimp cppcomserver.tlb

 

Jeśli uda się, dostajemy taką wiadomość:

 

Typelib imported successfully to CPPCOMSERVERLib.dll

 

Teraz potrzebujemy klienta .NET–używamy C#. Tworzymy plik .cs zawierający następujacy kod:

 

using System;

 

using CPPCOMSERVERLib;

 

 

public class MainApp

 

{

 

static public void Main()

 

{

 

CppName cppname = new CppName();

 

cppname.SetName( “bob” );

 

Console.WriteLine( “Name is ” + cppname.GetName() );

 

}

 

}

 

Kompilujemy kod C# tak:

 

csc /r:cppcomserverlib.dll csharpcomclient.cs

 

Ten kompilator ma za zadanie odnieść się do DLL, którą poprzednio wygenerowaliśmy z typelibrary używając TLBIMP. Powinniśmy teraz uruchomić csharpcomclient.exe i dostajemy dane wyjściowe w konsoli:

 

Name is bob

 

 

Używamy komponenty .NET z programów COM

 

 

Komponenty .NET są dostępne w COM przez COM Callable Wrapper (CCW). To jest podobne do RCW, ale działają w odwrotną stronę. Znowu jeśli taki wrapper nie może być wygenerowany automatycznie przez narzędzia rozwoju .NET lub jeśli to automatyczne zachowanie jest niepożądane, dostosowalny CCW może być rozwinięty. Także dla COM, aby zobaczył komponent .NET, komponent .NET musi być zarejestrowany w rejestrze.

 

Tworzymy plik C# zw. testcomserver.cs i wstawiamy ten kod do tego pliku:

 

using System;

 

using System.Runtime.InteropServices;

 

 

namespace AndyMc

 

{

 

[ClassInterface(ClassInterfaceType.AutoDual)]

 

public class CSharpCOMServer

 

{

 

public CSharpCOMServer() {}

 

public void SetName( string name ) { m_name = name; }

 

public string GetName() { return m_name; }

 

private string m_name;

 

}

 

}

 

Potem kompilujemy ten plik .cs tak:

 

csc /target:library testcomserver.cs

 

Powinniśmy dostać dll, który rejestrujemy tak:

 

regasm testcomserver.dll /tlb:testcomserver.tlb /codebase

 

Teraz musimy stworzyć klienta dla przetestwoania naszego komponentu .NET COM. VBScript będzie dobry–wstawiamy następujący kod do pliku zw. comclient.vbs:

 

Dim dotNetObj

 

Set dotNetObj = CreateObject(“AndyMc.CSharpCOMServer”)

 

dotNetObj.SetName (“bob”)

 

MsgBox “Name is ” & dotNetObj.GetName()

 

i uruchamiamy skrypt tak:

 

wscript comclient.vbs

 

I teraz powinniśmy dostać okienko z wiadomością wyświetlające tekst “Name is bob”.

 

 

ATL jest nadmiarowy dla świata.NET

 

 

ATL będzie ciągle cenny dla pisania komponentów COM przez pewien czas, ale nie ma on miejsca świecie .NET.

 

 

Mnożenie wątku

 

 

Tworzymy instancję obiektu System.Threading.Thread, przekazując to instancji delegata ThreadStart, który będzie wykonany na nowym wątku. Np.

 

class MyThread

 

{

 

public MyThread( string initData )

 

{

 

m_data = initData;

 

m_thread = new Thread( new ThreadStart(ThreadMain) );

 

m_thread.Start();

 

}

 

 

// ThreadMain() is executed on the new thread.

 

private void ThreadMain()

 

{

 

Console.WriteLine( m_data );

 

}

 

 

public void WaitUntilFinished()

 

{

 

m_thread.Join();

 

}

 

 

private Thread m_thread;

 

private string m_data;

 

}

 

W tym wypadku tworzenie instancji klasy MyThread jest wystarczające dla mnożenia wątku i wykonania metody MyThread.ThreadMain():

 

MyThread t = new MyThread( “Hello, world.” );

 

t.WaitUntilFinished();

 

 

Zatrzymanie wątku

 

 

Jest kilka opcji. Po pierwsze możemy używać naszego własnego mechanizmu komunikacji, aby powiedzieć metodzie ThreadStart, aby zakończyła się. Alternatywnie klasa Thread ma wbudowane wsparcie dla nakazania wątkowi zatrzymanie się. Tymi dwiema podstawowymi metodami są Thread.Interrupt() i Thread.Abort(). Ten poprzedni spowoduje, że ThreadInterruptedException będzie wyrzucony na wątku, kiedy następny wejdzie w stan WaitJoinSleep. Innymi słowy Thread.Interrupt jest grzecznym sposobem an zatrzymanie wątku, kiedy to już dłużej nie robi niczego pożytecznego. W przeciwieństwie Thread.Abort() wyrzuca ThreadAbortException bez względu na to, co dany wątek robi. Co więcej ThreadAbortException nie może normalnie być złapany (chociaż ostateczna metoda dla ThreadStart będzie wykonana). Thread.Abort() jest trudnoobsługiwalnym mechanizmem, który nie powinien być normalnie wymagany.

 

 

Używanie thread pool

 

 

Przez przekazania instancji delegata WaitCallback do metody ThreadPool.QueueUserWorkItem():

 

class CApp

 

{

 

static void Main()

 

{

 

string s = “Hello, World”;

 

ThreadPool.QueueUserWorkItem( new WaitCallback( DoWork ), s );

 

 

Thread.Sleep( 1000 ); // Give time for work item to be executed

 

}

 

 

// DoWork is executed on a thread from the thread pool.

 

static void DoWork( object state )

 

{

 

Console.WriteLine( state );

 

}

 

}

 

 

Wiedza, kiedy zagadnienie pracy thread pool jest zakończone

 

 

Nie ma sposobu, aby zapytać thread pool o te informacje. Musimy wstawić kod i metody WaitCallback dla zasygnalizowania, że to zostało zakończone. Zdarzenia są do tego bardzo użyteczne.

 

 

Unikanie jednoczesnego dostępu do danych

 

 

Każdy obiekt ma skojarzony ze sobą concurrency lock (critical section). Metody System.Threading.Monitor.Enter/Exit są używane dla nabycia i zwolnienia tego lock. Np. instancje następującej klasy pozwala jednemu wątkowi na raz wprowadzić metodę f():

 

class C

 

{

 

public void f()

 

{

 

try

 

{

 

Monitor.Enter(this);

 

 

}

 

finally

 

{

 

Monitor.Exit(this);

 

}

 

}

 

}

 

C# ma słowo kluczowe ‘lock’, które dostarcza odpowiedniego skrótu dla powyższego kodu:

 

class C

 

{

 

public void f()

 

{

 

lock(this)

 

{

 

 

}

 

}

 

}

 

Wywołanie Monitor.Enter(myObject) nie znaczy, że cały dostęp do myObject jest serializowany. Tzn., że wymagany jest synchronisation lock dla myObject i żaden inny wątek nie może nabywać tego lock aż jest wywołany Monitor.Exit(o). Innymi słowy ta klasa jest funkcjonalnym ekwiwalentem dla powyższych klas:

 

class C

 

{

 

public void f()

 

{

 

lock( m_object )

 

{

 

 

}

 

}

 

 

private m_object = new object();

 

}

 

W rzeczywistości możemy twierdzić, że ta wersja kodu jest lepsza, bo ten lock jest totalnie enkapsulowany w danej klasie i nie może być dostępna dla użytkownika danego obiektu.

 

 

Używanie ReaderWriterLock zamiast Monitor.Enter/Exit

 

 

Możliwe, ale ostrożnie. ReaderWriterLock jest używany dla pozwolenia wielu wątkom na odczyt ze źródła danych, podczas ciągłego przyznawania wyłącznego dostępu do pojedynczego wątku writer. To ma sens dla dostęp do danych, który jest przeważnie read-only, ale są pewne wady. Po pierwsze ReaderWriterLock jest względnie źle wykonywany w porównaniu do Monitor.Enter/Exit, co rekompensuje pewne korzyści. Po drugie musimy być pewni, że te struktury danych, do których mamy dostęp, w pełni wspierają wielowątkowy dostęp do odczytania. W końcu jest błąd w v1.1 ReaderWriterLock, który może powodować głód dla writers, kiedy jest dużo readers.

 

 

Wbudowane wsparcie dla tracing/logging

 

 

Jest takie wsparcie w przestrzeni nazwy System.Diagnostics. Są dwie główne klasy, które mają do czynienia z tracing–Debug i Trace. One dwie pracują w podobny sposób–różnica jest taka, że tracing z klasy Debug tylko pracuje w builds, które mają zdefiniowany symbol DEBUG, gdy tracing z klasy Trace tylko działa w builds, które ma zdefiniowany symbol TRACE. Zwykle to znaczy, że powinniśmy używać System.Diagnostics.Trace.WriteLine dla tracing, od którego chcemy, aby działało w builds debug i release oraz System.Diagnostics.Debug.WriteLine dla tracing, od którego chcemy, aby pracowało tylko w builds debug.

 

 

Przekierowanie redirect tracing do pliku

 

 

Klasy Debug i Trace mają właściwość Listeners, która jest kolekcją sinks, które otrzymują tracing, którego wysyłamy przez odpowiednio Debug.WriteLine i Trace.WriteLine. Domyślnie kolekcja Listeners zawiera pojedynczy sink, który jest instancją klasy DefaultTraceListener. To wysyła dane wyjściowe do funkcji Win32 OutputDebugString() i też metody System.Diagnostics.Debugger.Log(). To jest użyteczne, kiedy debugujemy, ale jeśli próbujemy tracować problem na stronie klienta, przekierowanie tych danych wyjściowych jest bardziej odpowiednie. Na szczęście klasa TextWriterTraceListener jest dostarczona do tego celu.

 

Oto jak używamy klasy TextWriterTraceListener dla przekierowania danych wyjściowych Trace do pliku:

 

Trace.Listeners.Clear();

 

FileStream fs = new FileStream( @”c:\log.txt”, FileMode.Create, FileAccess.Write );

 

Trace.Listeners.Add( new TextWriterTraceListener( fs ) );

 

 

Trace.WriteLine( @”This will be writen to c:\log.txt!” );

 

Trace.Flush();

 

Użycie Trace.Listeners.Clear() dla usunięcia domyślnego listenera. Jeśli nie zrobimy tego, dane wyjściowe pójdą do pliku i do OutputDebugString(). W zasadzie to nie jest to, co chcemy, bo OutputDebugString() nakazuje dobre wykonanie.

 

 

Dostosowanie danych wyjściowych trace

 

 

Możemy napisać naszą własną klasę pochodną z TraceListener i przekierować całe dane wyjściowe przez to. W poniższym przykładzie, który wywodzi się z TextWriterTraceListener (i dlatego ma wbudowane wsparcie dla zapisywania do plików, jak pokazana wyżej) i dodaje informacje o timing i thread ID dla każdej linii trace:

 

class MyListener : TextWriterTraceListener

 

{

 

public MyListener( Stream s ) : base(s)

 

{

 

}

 

 

public override void WriteLine( string s )

 

{

 

Writer.WriteLine( “{0:D8} [{1:D4}] {2}”,

 

Environment.TickCount – m_startTickCount,

 

AppDomain.GetCurrentThreadId(),

 

s );

 

}

 

 

protected int m_startTickCount = Environment.TickCount;

 

}

 

Ta implementacja nie jest kompletna–metoda TraceListener.Write nie jest nadpisana.

 

Piękno tego podejścia jest wtedy, kiedy instancja MyListener jest dodana do kolekcji Trace.Listeners, wszystkie wywołania do Trace.WriteLine() idą przez MyListener, w tym wywołania czynione przez odniesione zestawy składowe, które nic nie wiedzą o klasie MyListener.

 

 

Dostępne komponenty logujące trzeciej strony

 

 

Log4net jest portem ustalonego komponentu logującego log4j Javy.

 

 

Praca remoting dla .NET

 

 

Remoting dla .NET pociaga za sobą wysyłanie wiadomości przez kanały. Dwa z tych standardowych kanałów są: HTTP i TCP. TCP jest przeznaczony tylko dla LANs. HTTP może być używany dla LANs or WANs (internet).

 

Wsparcie jest dostarczone dla wielu formatów serializacji wiadomości. Przykładami są SOAP (oparty na XML) i binaria. Domyślnie kanał HTTP używa SOAP (przez agenta uruchomienia .NET Serialization SOAP Formatter) i kanał TCP używa binariów (przez agenta uruchomienia .NET Serialization Binary Formatter). Ale oba kanały muszą używać obu formatów serializacji.

 

Jest wiele stylów zdalnego dostępu:

 

SingleCall. Każda przychodząca prośba od klienta jest obsługiwana przez nowy obiekt. Ten obiekt jest odrzucany, kiedy ta prośba jest zakończona.

 

Singleton. Wszystkie przychodzące prośba od klientów są przetwarzane przez obiekt pojedynczego serwera (single server object).

 

Client-activated object. To jest dostojny stary model (D)COM, gdzie klient otrzymuje odniesienie do zdalnego obiektu i przechowuje to odniesienie (w ten sposób trzymając zdalny obiekt żywy) aż będzie zrobiona robota przy użyciu tego.

 

Dystrybuowany zbieracz śmieci obiektów jest zarządzany przez system zw. ‘leased based lifetime’. Każdy obiekt ma czas dzierżawy i kiedy ten czas wygasa, dany obiekt jest odłączany od innfrastruktury agenta czasu uruchomienia remoting. Obiekty mają domyślnie czas odnawiany– dzierżawa jest odnawiana, kiedy wywołanie z sukcesem jest czynione od klienta do obiektu. Dany klienta może też jasno odnowić dzierżawę.

 

Używamy XML-RPC (XML-RPC.Net) jako alternatywę dla SOAP.

 

 

Dojście do API Win32 z programu .NET

 

 

Używamy P/Invoke. To używa podobnej technologii dla COM Interop, ale jest używany do dostępu do punktów wejściowych static DLL zamiast obiektów COM. Oto jest przykład C# wywołujący funkcję MessageBox w Win32:

 

using System;

 

using System.Runtime.InteropServices;

 

 

class MainApp

 

{

 

[DllImport(“user32.dll”, EntryPoint=”MessageBox”, SetLastError=true, CharSet=CharSet.Auto)]

 

public static extern int MessageBox(int hWnd, String strMessage, String strCaption, uint uiType);

 

 

public static void Main()

 

{

 

MessageBox( 0, “Hello, this is PInvoke in operation!”, “.NET”, 0 );

 

}

 

}

 

Pinvoke.net jest dobrym zasobem dla gotowych P/Invoke signatures.

 

 

Zapisywanie do pliku konfiguracyjnego aplikacji w czasie uruchomienia

 

 

Nie możemy.

 

 

Różnica między zdarzeniem a delegatem

 

 

Zdarzenie jest wrapperem dla multicast delegate. Dodanie wrappera public event do klasy jest prawie takie same jak dodanie public multicast delegate field. W obu przypadkach obiekty subskrybera mogą zarejestrować dla zawiadomień i w obu przypadkach obiekt publishera może wysłać zawiadomienia do subskryberów. Jednak public multicast delegate ma niepożądaną właściwość, gdzie zewnętrzne obiekty mogą wywołać delgata, coś, co normalnie chcemy ograniczać dla publishera. Dlatego zdarzenie dodaje metody public do zawierającej klasy dla dodania i usunięcia otrzymujących, ale nie czyni mechanizmu wywołania public.

 

 

Rozmiar obiektu .NET

 

 

Każda instancja reference type ma dwa pola utrzymane przez agenta czasu uruchomienia–metoda table pointer i sync block. One są 4-bajtowe każdy na systemach 32-bitowych, ogólnie czyniąc w sumie 8 bajtów na obiekt. Oczywiście dane instancji dla tego typu muszą być dodane dla tego dla otrzymania całkowitego rozmiaru obiektu. Tak więc np. instancje następującej klasy są 12 bajtów każda:

 

class MyInt

 

{

 

 

private int x;

 

}

 

Jednak z bieżącą implementacją CLR wydaje się być obiektem minimalnego rozmiaru 12 bajtów, nawet dla klas bez żadnych danych (np. System.Object).

 

Values types nie mają żadnego ekwiwalentu ogólnego.

 

 

Aplikacja .NET działa na 64-bit Windows

 

 

Wersje 64-bit (x64) Windows wspierają zarówno procesy 32-bit i 64-bit i odpowiednie wersje 32-bit i 64-bit .NET 2.0. (.NET 1.1 jest tylko 32-bit).

 

Aplikacja .NET 1.x automatycznie działa na procesach 32-bit i na 64-bit Windows.

 

Aplikacje .NET 2.0 mogą działać jako procesy 32-bit lub jako procesy 64-bit. SO decyduje, które użyć w oparciu o PE header kodu wykonywalnego. Flagi w PE header są kontrolowane przez przełącznik kompilatora /platform, który pozwala docelowej aplikacji być określonym jako ‘x86’, ‘x64’ lub ‘any cpu’. Normalnie określamy ‘any cpu’ i nasza aplikacja będzie działać jako 32-bit na 32-bit Windows i 64-bit na 64-bit Windows. Jednak jeśli mam pewien natywny kod 32-bit w naszej aplikacji (załadowany np. przez COM interop), będziemy potrzebowali określić ‘x86’, który wymusi 64-bit Windows dla załadowania naszej aplikacji w proces 32-bit. Możemy też dostosować flagę 32-bit w PE header używając narzędzia SDK.

 

 

Reflekcja (reflection)

 

 

Wszystkie kompilatory .NET dają metadane o określonych typach w modułach, które one produkują. Te metadane są pakowane razem z modułem (moduły z kolei są pakowane razem w zestawy składowe) i mogą być dostępne przez mechanizm zw. reflekcją. Przestrzeń nazwy System.Reflection zawiera klasy, które mogą być użyte dla przebadania typów dla modułu/zestawu składowego.

 

Użycie refleksji dla dostępu do metadanych .NET jest bardzo podobne do użycia ITypeLib/ITypeInfo dla dostepu do danych biblioteki typu w COM i to jest używane dla podobnych celów–np. ustalenie rozmiarów typu danych dla uporządkowania danych w granicach context/process/machine.

 

Refleksja może też być użyta do dynamicznego wywoływania metod (patrzymy System.Type.InvokeMember) lub nawet tworzenia dynamicznego typów w czasie uruchomienia (patrzymy System.Reflection.Emit.TypeBuilder).

 

 

Nowe cechy .NET 2.0 w porównaniu z .NET 1.0

 

 

– generics

 

– anonymous methods

 

– partial classes

 

– iterators

 

– property visibility (oddzielna widoczność dla get i set)

 

– static classes

 

 

Użyteczność nowych cech 2.0

 

 

Generics są użyteczne dla wydajnego zapisu niezależnego od typu kodu, szczególnie gdzie te typy mogłyby zawierać typy wartości (value types). Aplikacja jest kontenerem klas i biblioteką klas. .NET 2.0 zawiera zestaw ogólny klasy kontenera w przestrzeni nazwy System.Collections.Generic. Przykład ogólnej klasy kontenera (generic container class) jest tu użyty:

 

List<int> myList = new List<int>();

 

myList.Add( 10 );

 

Anonimowe metody (anonymous methods) redukują sumę kodę, którego musimy zapisać, kiedy używamy delegatów i są dlatego zwłaszcza użyteczne dla programowania GUI. Przykład:

 

AppDomain.CurrentDomain.ProcessExit += delegate { Console.WriteLine(“Process ending …”); };

 

Klasy częściowe (partial classes) są użyteczną cechą dla oddzielenia kodu generowanego przez maszynę od kodu zapisanego ręcznie w tej samej klasie i będą dlatego mocno używane przez narzędzia rozwojowe takie jak Visual Studio.

 

Iteratory (iterators) redukują sumę kodu, którego musimy zapisać dla implementacji IEnumerable/IEnumerator. Przykład:

 

static void Main()

 

{

 

RandomEnumerator re = new RandomEnumerator( 5 );

 

foreach( double r in re )

 

Console.WriteLine( r );

 

Console.Read();

 

}

 

 

class RandomEnumerator : IEnumerable<double>

 

{

 

public RandomEnumerator(int size) { m_size = size; }

 

 

public IEnumerator<double> GetEnumerator()

 

{

 

Random rand = new Random();

 

for( int i=0; i < m_size; i++ )

 

yield return rand.NextDouble();

 

}

 

 

int m_size = 0;

 

}

 

Użycie ‘yield return’ jest raczej dziwne na pierwszy rzut oka. To wydajnie syntetyzuje implementację IEnumerator, co musieliśmy robić ręcznie w .NET 1.x.

 

 

Problem z generics .NET

 

 

Generics .NET dobrze pracuje dla klas kontenera. Ale co z innym użyciami. Okazuje się, ze generics .NET ma zasadnicze ograniczenie–wymaga parametru typu dla bycia ograniczonym. Np. nie możemy zrobić tego:

 

static class Disposer<T>

 

{

 

public static void Dispose(T obj) { obj.Dispose(); }

 

}

 

Kompilator C# odmówi kompilowania tego kodu jak typ T nie będzie ograniczony i dlatego tylko wspiera metody System.Object. Dispose nie jest metodą na System.Object, więc kompilacja nie udaje się. Aby naprawić ten kod, musimy dodać zdanie where dla zapewnienia, ze kompilator, który nasz typ T robi, ma metodę Dispose.

 

static class Disposer<T> where T : IDisposable

 

{

 

public static void Dispose(T obj) { obj.Dispose(); }

 

}

 

Problem jest, że wymaganie dla jasnych ograniczeń jest bardzo ograniczające. Możemy używać ograniczeń dla powiedzenia, że T implementuje konkretny interfejs, ale nie możemy osłabiać tego, aby po prostu powiedzieć, że T implementuje konkretną metodę. Kontrastujemy to z np. szablonami C++, gdzie żadne ograniczenie w ogóle nie jest wymagane–zakłada się (i weryfikuje się w czasie kompilacji), że jeśli kod wywołuje metodę Dispose() na typie, wtedy ten typ będzie wspierać tę metodę.

 

W rzeczywistości po napisaniu ogolnego kodu z ograniczeniami interfejsu, szybko zobaczymy, że nie uzyskalismy więcej niż programowanie w oparciu o interfejs nie-ogólny. Np. możemy łatwo jeszcze raz napisać klasę Disposer class bez generics:

 

static class Disposer

 

{

 

public static void Dispose( IDisposable obj ) { obj.Dispose(); }

 

}

 

 

Nowości w bibliotece klasy .NET 2.0

 

 

  • Ogólne kolekcje w przestrzeni nazwy System.Collections.Generic.

  • Typ System.Nullable<T>. (C# ma specjalną składnię dla tego typu np. int? jest ekwiwalentem dla Nullable<int>)

  • Klasy GZipStream i DeflateStream w przestrzeni nazwy System.IO.Compression.

  • Klasa Semaphore w przestrzeni nazwy System.Threading.

  • Wrappery dla DPAPI w formie klas ProtectedData i ProtectedMemory w ptrzestrzeni nazwy System.Security.Cryptography.

  • Kanał remoting IPC w przestrzeni nazwy System.Runtime.Remoting.Channels.Ipc dla optymizowania komunikacji wewnatrz maszyny.

 

 

Wstęp do .NET

 

 

Standard opisujący wszystkie typy informacji w Internecie to Extensible Markup Language (XML). Ważne usługi (wykonanie jakiegoś business logic):

 

– Validating a credit card purchase

 

– Getting directions from point A to point B

 

– Viewing a restaurant’s menu

 

– Booking a flight on an airline, a hotel room, or a rental car

 

– Updating photos in an online photo album

 

– Merging your calendar and your children’s calendars to plan a family vacation

 

– Paying a bill from a checking account

 

– Tracking a package being shipped to you

 

 

Aby stworzyć bogate aplikacje, biznesy muszą oferować programistyczny interfejs dla swoich usług business logic. Ten programistyczny interfejs musi być wywoływalny zdalnie przy użyciu sieci jak Internet. To jest właśnie inicjatywa Microsoft .NET. To jest wszystko o łączeniu informacji, ludzi i urządzeń.

 

Komputery mają urządzenia peryferyjne i SO dostarcza platformy rozwojowej, która abstrahuje dostęp aplikacji do tych urzadzeń peryferyjnych. Dlatego możemy myśleć o tych urządzeniach peryferyjnych jako usługach. One są podłączone do Internetu. Programiści chcą łatwego dostępu do tych usług.

 

 

Analogia urządzeń peryferyjnych i usług. Po lewej Windows jest platformą rozwojową, która abstrahuje różnice hardware urządzeń peryferyjnych od rozwoju aplikacji. Po prawej .NET Framework jest platformą rozwojową, która abstrahuje komunikację XML Web service od programowanej aplikacji.

 

Aplikacja Aplikacja

 

| |

 

SO .NET Framework

 

| |

 

Hardware XML

 

| |

 

Urządzenia peryferyjne Usługi Web

 

 

Chociaż Microsoft jest liderem w rozwoju i definicji standardów zaangażowanych w to, nie posiada na własność tych standardów. Maszyny klienta opisują prośbę do serwera przez tworzenie specjalnie formatowanego XML i potem wysyłanie tego (typowo przez użycie HTTP) przez intranet i Internet. Serwery wiedzą jak parsować dane XML, przetwarzać prośbę klienta i zwracać odpowiedź jako XML do tegoż klienta. Simple Object Access Protocol (SOAP) jest terminem używanym do opisania specialnie formatowanego kodu XML, kiedy to jest wysyłane przy użyciu HTTP.

 

Prośba

 

Klient———————————————————————————————–>Serwer

 

HTML—->Formatowany XML SOAP Parsowanie XML

 

Odpowiedź

 

Klient<———————————————————————————————–Serwer

 

HTML<—Formatowany XML SOAP Usługi Web

 

Obrazek pokazuje wiązkę XML Web services wszystkich komunikujących się z jeden z drugim przy użyciu SOAP z jego ładownością XML. Ten obraz też pokazuje klientów uruchamiających aplikacje, które mogą przemawiać do usług Web i nawet do innych klientów przez SOAP (XML).

 

 

Dodatkowo obrazek pokazuje klienta biorącego rezultaty przez HTML z Web serwera. Użytkownik prawdopodobnie wypełnia Web form, który został wysłany do Web serwera. Web serwer przetwarza prośbę użytkownika (który angażuje komunikację z pewnymi usługami Web) i wyniki są ostatecznie odsyłane do tegoż użytkownika przez standardową stronę HTML. Dodatkowo komputery dostarczające usług muszą mieć SO, który słucha tych próśb SOAP. Microsoft ma nadzieję, że ten SO będzie Windows, ale Windows nie jest wymagany. Jakikolwiek SO, który może słuchać na porcie socketu TCP/IP i odczytywać/zapisywać bajty do tegoż portu jest dobry do tego zadania. Niedługo do tego świata będą należeć: komórki, pagery, samochody, kuchenki, zmrażarki, telewizory, stereo, konsole gier i inne urządzenia.

 

Po stronie klienta lub aplikacji SO musi działać, który może odczytywać/zapisywać do socketu portu dla emisji próśb usług. Komputer klienta musi też być zdolny do wspierania takich cech, jakich wymaga użytkownik aplikacji. Jeśli użytkownik aplikacji chce stworzyć okno lub menu, SO musi dostarczać tej funkcjonalności lub programista aplikacji musi implementować to ręcznie. Oczywiście Microsoft ma nadzieję, że ludzie napiszą aplikacje, które bedą korzystać z bogatego zestawu cech Windows, ale Windows jest zaleceniem, nie koniecznością. Ten świat może istnieć bez Windowsa, ale Windowsa .NET tylko to ułatwia dla programistów w tworzeniu tych usług.

 

Teraz możemy napisać swój własny SO i stworzyć swój własny Web serwer dla słuchania i ręcznego przetwarzania próśb SOAP, jeśli tego chcemy, ale to jest trudne i czasochłonne. Microsoft to zrobił za nas i możemy wykorzystać to dla naszego programowania. Teraz jako programiści możemy skoncentrować się na naszych business logic i usługach, pozostawiając wszystkie te komunikacyjne protokoły i przejść do Microsoftu.

 

 

Co tworzy Microsoft .NET Initiative

 

 

Technologie i inicjatywy Microsoft:

 

– MS-DOS

 

– Windows

 

– Windows CE

 

– OLE

 

– COM

 

– ActiveX

 

– COM+

 

– Windows DNA (Distributed InterNet Architecture)

 

 

ActiveX to tylko ActiveX controls.

 

Windows DNA wziął w jedno wiązkę już istniejących technologii.

 

 

Podległy SO: Windows

 

 

Ponieważ te usługi Web i aplikacje, które używają usług Web działają na komputerach i ponieważ komputery mają urządzenia peryferyjne, ciągle potrzebujemy SO. Microsoft sugeruje, że ludzie używają Windows. Microsoft dodaje cechy XML Web service do swojej linii SOs i Windows XP oraz serwery w rodzinie Windows .NET Server Family będą wersjami najlepiej dostosowanymi do nowego świata napędzanego usługami.

 

Produkty Windows XP i Windows .NET Server Family mają zaintegrowane wsparcie dla Microsoft .NET Passport XML Web service. Passport jest usługą, która autentykuje użytkowników. Wiele usług Web będzie wymagać autentykacji użytkownika dla bezpiecznego dostępu do informacji. Kiedy użytkownicy logują się do systemu Windows XP lub jednego z serwerów z Windows .NET Server Family, one są wydajnie logowane do każdej witryny Web i usługi Web, która używa Passport do autentykacji. Tzn., że użytkownicy nie będą musieli wprowadzać nazw użytkownika i haseł, bo oni mają dostęp do różnych witryn Internetu. Passport jest wielką korzyścią dla użytkowników–jedna tożsamość i hasło dla wszystkiego, co czynimy i musimy wprowadzić to tylko raz.

 

Dodatkowo produkty Windows XP i Windows .NET Server Family mają wbudowane pewne wsparcie dla ładowania i wykonywana aplikacji implementujących .NET Framework. Ostatecznie Windows XP i Windows .NET Server Family mają nową aplikację natychmiastowego powiadamiania rozszerzalnego. Ta aplikacja pozwala trzeciej stronie (takiej jak Expedia, the United States Postal Service i.in) na komunikację z użytkownikami idealnie. Np. użytkownicy mogą otrzymywać automatyczne powiadomienia, kiedy ich loty są opóźnione (z Expedia) i kiedy pakiet jest gotowy do dostarczenia (z the U.S. Postal Service).

 

 

Pomocne produkty: The .NET Enterprise Servers

 

 

Jako część .NET initiative, Microsoft dostarcza kilka produktów, które firmy mogą wybrać do użycia, jeśli ich business logic (services) traktuje je jako użyteczne. Oto są niektóre produkty enterprise server Microsoftu:

 

– Microsoft Application Center 2000

 

– Microsoft BizTalk Server 2000

 

– Microsoft Commerce Server 2000

 

– Microsoft Exchange 2000

 

– Microsoft Host Integration Server 2000

 

– Microsoft Internet Security and Acceleration (ISA) Server 2000

 

– Microsoft Mobile Information Server 2002

 

– Microsoft SQL Server 2000

 

 

Każdy z tych produktów ostatecznie będzie miał “.NET” dodany do swojej nazwy dla celów marketingowych.

 

 

Microsoft XML Web Services: .NET My Services

 

 

Microsoft chce zrobić więcej niż tylko dostarczać podległe technologie, które pozwalają innym grać w tym nowym świecie. Microsoft też chce grać w tych technologiach. Tak więc Microsoft będzie budować swój własny zestaw XML Web services: pewne będą darmowe a inne będą wymagać pewnej opłaty. Microsoft planuje zaoferować takie .NET My Services:

 

– .NET Alerts

 

– .NET ApplicationSettings

 

– .NET Calendar

 

– .NET Categories

 

– .NET Contacts

 

– .NET Devices

 

– .NET Documents

 

– .NET FavoriteWebSites

 

– .NET Inbox

 

– .NET Lists

 

– .NET Locations

 

– .NET Presence

 

– .NET Profile

 

– .NET Services

 

– .NET Wallet

 

Te XML Web services zorientowane na konsumenta są znane jako “.NET My Services.” Potem będzie dodane więcej usług i będzie też tworzone XML Web services zorientowane na biznes.

 

Dodatkowo do tych public Web services, Microsoft stworzy wewnętrzne usługi dla sales data i billing. Te wewnętrzne usługi będą dostępne tylko dla pracowników Microsoft. To będzie w intranetach innych firm, czyli użycie Web services. Potem w Internecie.

 

 

Platforma programistyczna The .NET Framework

 

 

Pewne z Microsoft .NET My Services (jak Passport) dzisiaj istnieją. Te usługi działają na Windows i są budowane przy użyciu technologii jak C/C++, ATL, Win32, COM itd. Z czasem te usługi i nowe usługi będą w końcu zaimplementowane przy użyciu nowszych technologii takich jak C# i .NET Framework.

 

.NET Framework nie tylko może budować Internetowe aplikcje i usługi Web. Można budować:

 

– XML Web services

 

– Web Forms

 

– Win32 GUI applications

 

– Win32 CUI (console UI) applications

 

– services (controlled by the Service Control Manager)

 

– utilities

 

– stand-alone components

 

 

.NET Framework ma dwie części: common language runtime (CLR) i

 

Framework Class Library (FCL)..NET Framework jest częścią inicjatywy, która ułatwia rozwój usług i aplikacji. Tutaj mamy rozwój aplikacji i usług XML Web.

 

Windows XP (Home Edition i Professional) nie jest razem z .NET Framework “in the box.” Jednak Windows .NET Server Family (Windows .NET Web Server, Windows .NET Standard Server, Windows .NET Enterprise Server i Windows .NET Datacenter Server) będą zawierać .NET Framework. Dlatego Windows .NET Server Family otrzymał swoją nazwę. Następne wersje Windows (code-named “Longhorn”) będą zawierać .NET Framework we wszystkich edycjach.

 

Inni agenci uruchomienia i biblioteki klasy:

 

– C-runtime library

 

standard template library (STL)

 

– Microsoft Foundation Class library (MFC)

 

– Active Template Library (ATL)

 

– Visual Basic runtime library

 

– Java virtual machine.

 

 

Rola CLR i FCL:

 

Zwięzły model programowania. Kiedyś programy w SO były dostępne przez funkcje dynamic-link library (DLL), a inne narzędzia były dostępne przez obiekty COM– wszystkie usługi aplikacji są oferowane przez model programowania Common Object-Oriented.

 

Uproszczony model programowania. CLR szuka uproszczonych konstrukcji wymaganych przez Win32 i COM. CLR uwalnia programistę od znania rejestru, globally unique identifiers (GUIDs), IUnknown, AddRef, Release, HRESULTs itd. Te zagadnienie po prostu nie istnieją w CLR. Jednak jeśli chcemy pisać aplikacje, które współdziałają z kodem niezarządzanym, ciągle musimy wiedzieć o tym.

 

Uruchomiony raz, uruchomiony będzie zawsze. problem z DLL i wersjowaniem. Komponenty nowej aplikacji zastępują komponenty starej aplikacji, powodują błędy w tej ostatniej. Architektura .NET Framework teraz izoluje komponenty aplikacji, aby aplikacja zawsze ładowała te komponenty, które są zbudowane i przetestowane z nią. Jeśli dana aplikacja uruchamia się po instalacji, wtedy zawsze uruchomi się.

 

Uproszczone rozmieszczenie. Teraz aplikacje Windowsa są trudne do ustawienia i rozmieszczenia. Kilka plików, ustawienia rejestru i skróty zwykle muszą być stworzone. Dodatkowo kompletne odinstalowanie aplikacji jest prawie niemożliwe. Z Windows 2000 jest nowy silnik instalacji, który pomaga rozwiaząć te kwestie, ale ciągle może być produkt trzeciej strony działający pod Windows, który podczas odinstalowania nie zrobi wszystkiego właściwie..NET Framework pozbywa się tego problemu. Komponenty .NET Framework (znane jako typy) nie mają odniesienia w rejestrze. W rzeczywistości instalowanie większości aplikacji .NET Framework wymaga niczego więcej niż kopiowania plików do katalogu i dodanie skrótu do Start menu, pulpitu lub paska szybkiego uruchamiania. Odinstalowanie aplikacji to jest po prostu kasowanie tych plików.

 

Szeroki zasięg platformy. Kiedy kompilujemy kod źródłowy dla .NET Framework, kompilatory dają common intermediate language (CIL) zamiast tradycyjnych instrukcji CPU. W czasie uruchomienia CLR tłumaczy CIL na natywne instrukcje CPU. Ponieważ to tłumaczenie na natywne instrukcje CPU jest czynione w czasie uruchomienia, to tłumaczenie jest czynione dla CPU hosta. Tzn., że możemy stosować naszą aplikację .NET Framework na jakiejkolwiek maszynie, która ma działającą wersję CLR i FCL zgodną z ECMA. Te maszyny mogą być:

 

– x86

 

– IA64

 

– Alpha

 

– PowerPC

 

– itd.

 

Jest to szerokie wykonanie na wielu architekturach.

 

Integracja języka programowania. COM pozwala różnym językom programowania na współdziałanie jeden z drugim. .NET Framework pozwala jezykom być zintegrowanym jeden z drugim, abyśmy mogli używać typów innego języka, jak gdyby one były nasze własne. Np. CLR czyni to możliwym stworzyć klasę w C++, która pochodzi z klasy implementowanej w Visual Basic. CLR pozwala na to, bo to określa i dostarcza Common Type System (CTS), któremu muszą podporządkować się wszystkie języki, które mają na celu CLR. Common Language Specification (CLS) opisuje co implementatorzy kompilatora muszą zrobić, aby ich języki integrowały się dobrze z innymi językami. Microsoft sam dostarcza kilka kompilatorów, które dają kod mający na celu agenta czasu uruchomienia: C++ z Managed Extensions, C#, Visual Basic .NET (które teraz podciąga Visual Basic Scripting Edition lub VBScript i Visual Basic for Applications lub VBA) i JScript. Inni producenci też produkują kompilatory mające na celu CLR.

 

Uproszczone ponowne użycie kodu. Używając mechanizmów opisanych wcześniej możemy tworzyć swoje własne klasy, które oferują usługi dla aplikacji trzeciej strony. To czyni, że jest bardzo łatwo ponownie używać kod i to też tworzy wielki rynek dla sprzedawców komponentów (typów).

 

Automatyczne zarządzanie pamiecią, czyli zbieracz śmieci. Programowania wymaga wielkich umiejętności i dyscypliny, zwł. kiedy idzie o użycie zasobów takich jak pliki, pamięć, przestrzeń na ekranie, połączenia sieciowe, zasoby bazy danych itd. Jednym z błędów jest zapomnienie uwolnienia jednego z tych zasobów, co może spowodować, że aplikacja będzie wykonywać niewłaściwie w nieprzewidzianym czasie. CLR automatycznie śledzi użycie zasobu, gwarantując, że nasza aplikacja nigdy nie spowoduje wyciekania zasobów. W rzeczywistości nie ma sposobu dla wyraźnego oczyszczenia pamięci.

 

Weryfikacja bezpiecznego typu (Type-safe). CLR może weryfikować, że nasz kod jest bezpiecznego typu. Bezpieczeństwo typu zapewnia, że alokowane obiekty są zawsze dostępne w sposób kompatybilny. Dlatego jeśli metoda parametru danych wejściowych jest deklarowana jako przyjmująca wartość 4 bajtów, CLR wykryje i złapie usiłowania dostępu do parametru jako wartość 8 bajtowa. Podobnie jeśli obiekt zajmuje 10 bajtów w pamięci, aplikacja nie może zmuszać obiektu do przyjecia formy, która pozwoli na więcej niż 10 bajtów do odczytu. Bezpieczeństwo typu też znaczy, że przepływ wykonania będzie transferować tylko dobrze znane lokacje (czyli metodę punktów wejścia). Nie ma sposobu na konstruowanie dowolnego odniesienia do lokacji pamięci i spowodowania, że kod w tej lokacji zacznie wykonywanie. Razem te środki zapewniają bezpieczeństwo typu eliminujące wiele powszechnych błędów programowania i klasyczne ataki na system (np. wykorzystanie przepełnienia bufora).

 

Wsparcie bogatego debugowania. Ponieważ CLR jest używany dla wielu języków programowania, to jest teraz łatwiejsze implementowanie kawałków aplikacji przy użyciu najlepiej dopasowanego jezyka do konkretnego zadania. CLR w pełni wspiera debugowanie aplikacji, które przekraczają granice języka.

 

Zwięzła metoda modelu niepowodzenia. Wcześniej był chaotyczny styl, gdzie funkcje raportowały niepowodzenia. Pewne funkcje zwracały stan kodów Win32, pewne funkcje zwracały HRESULTs i pewne funkcje wyrzucały wyjątki. W CLR wszystkie niepowodzenia są raportowane przez wyjątki. Wyjątki pozwalają programiście izolować kod powodujący powrót do normy po niepowodzeniu od kodu wymaganego dla zrobienia zadania. To oddzielenie bardzo upraszcza pisanie, czytanie i utrzymanie kodu. Dodatkowo wyjątki działają poza granicami modułu i języka programowania. I nie tak jak kody stanu i HRESULTs, wyjątki nie mogą być ignorowane. CLR też dostarcza wbudowanych narzędzi stack-walking, czyniąc łatwiejszym lokalizowanie błędów i niepowodzeń.

 

Bezpieczeństwo. Tradycyjne bezpieczeństwo SO dostarcza izolacji i kontroli dostępu w oparciu o konta użtkownika. Ten model okazał się użyteczny, ale w swoich podstawach zakłada, że cały kod jest równie warty zaufania. To założenie jest usprawiedliwione, kiedy cały kod został zainstalowany z fizycznego medium (np. CD-ROM) lub zaufanych serwerów korporacyjnych. Ale wraz ze wzrastającym poleganiem na mobilnym kodzie takim jak skrypty Web, aplikacje ściągane przez Internet i załączniki e-mail, potrzebujemy sposobów na kontrolowanie zachowania aplikacji na sposób bardziej skupiony na kodzie. Bezpieczeństwo dostępu do kodu dostarcza środków do zrobienia tego.

 

Interoperacyjność. Microsoft wie, że programiści już mają wielkie ilości istniejącego kodu i komponenty. Przepisanie tego kodu dla pełnego wykorzystania platfromy .NET Framework byłoby wielkim przedsięwzieciem i powtrzymałoby szybką adopcję tej platformy. Tak więc .NET Framework w pełni wspiera zdolność, gdzie programista ma dostęp do istniejących komponentów COM a także funkcji Win32 w istniejących DLLs.

 

 

Development Environment: Visual Studio .NET

 

 

Ostatnią cześcią .NET initiative jest Visual Studio .NET. Visual Studio .NET jest środowiskiem rozwojowym Microsoftu. Mamy to wiele cech .NET Framework. Visual Studio .NET zawiera menadżera projektu, edytor kodu źródłowego, projektantów UI, wiele kreatorów, kompilatorów, linkerów, narzędzi, dokumetację i debugery. Wspiera budowę aplikacji dla platform 32-bit i 64-bit. Jedne zintegrowane środowisko rozwojowe dla wszystkich języków.

 

Microsoft też daje .NET Framework SDK. Zawiera kompilatory jezyków, narzędzia i wiele dokumentacji. Możemy rozwijać aplikacje dla .NET Framework bez używania Visual Studio .NET. Musimy użyć tylko edytora i systemu zarządzania projektami.

 

 

.NET Framework

 

 

.NET Framework jest integralną częścią Windows, wspierającą budowanie i uruchamianie aplikacji nowej generacji i usług Web XML:

 

– zwięzłe środowisko programowania obiektowego (obiekt może być przechowywany i wykonywany lokalnie lub zdalnie)

 

– środowisko wykonywania kodu, które minimalizuje konflikty rozwoju software i konflikty wersji

 

– promuje bezpieczne wykonanie kodu, w tym kodu stworzonego przez stronę trzecią niewiadomego pochodzenia.

 

– eliminuje problemy z wykonaniem środowisk skryptowych i interpretowanych

 

– zwięzłe środowisko w różnych typach aplikacji takich jak aplikacje oparte na Windowsie i aplikacji opartych na Web

 

– komunikacja na standardach industrialnych dla zapewnienia, że kod oparty na .NET Framework może zintegrować się z jakimś innym kodem

 

.NET Framework ma dwa główne komponenty:

 

common language runtime (CLR)- wspólne środowisko uruchomienia języka

 

.NET Framework class library– biblioteka klasy .NET Framework

 

CLR jest podstawą .NET Framework. Możemy traktować ten runtime jako agenta, który zarządza kodem w czasie wykonania, dostarczając podstawowych usług takich jak:

 

– zarządzanie pamięcią (memory management)

 

– zarządzanie wątkiem (thread management)

 

– zdalność (remoting)

 

– wymuszenie dokładnego typu bezpieczeństwa i innych form poprawności kodu, który promuje bezpieczeństwo i stabilność

 

Koncept zarządzania kodem jest fundamentalną zasadą agenta czasu uruchomienia (runtime). Kod, który ma na celu agenta czasu uruchomienia jest zw. kodem zarządzanym (managed code), gdy kod, który nie ma celu agenta czasu uruchomienia jest zw. kodem niezarządzanym (unmanaged code).

 

 

kod zarządzany- wpływ CLR

 

kod niezarządzany- bez wpływu CLR

 

 

Innym głównym komponentem .NET Framework jest biblioteka klasy (class library), czyli zbiór typów (klas) OOP do wielokrotnego użycia, które używamy do rozwoju aplikacji od wiersza polecenia i GUI do ASP.NET, czyli takich jak usługi Web Forms i XML Web.

 

.NET Framework może być hostowany (korzystać z gościnności) przez niezarządzane składniki, które ładują do CLR swoje procesy i inicjują wykonanie kodu zarządzanego, w ten sposób tworząc środowisko programowe, które może używać zarówno cechy zarządzane i niezarządzane.

 

IE

 

————————————————————————

 

| |

 

kod zarządzany (Form kontrols) kod niezarządzany (HTML)

 

| |

 

CLR wykonanie bezpośrednie

 

| |

 

wykonanie |

 

| |

 

————————————————————————

 

Strona WWW

 

.NET Framework nie tylko dostarcza kilku hostów agenta czasu uruchomienia, ale też wspiera rozwój hostów uruchomienia trzeciej strony.

 

Np. ASP.NET hostuje środowisko uruchomienia dla wprowadzenia skalowalnego, po stronie serwera środowiska dla kodu zarządzanego. ASP.NET działa bezpośrednio z agentem czasu uruchomienia dla umożliwienia działania aplikacjom ASP.NET i usługom XML Web.

 

Internet Explorer jest przykładem aplikacji niezarządzanej, która hostuje (gości) agenta czasu uruchomienia (w formie rozszerzenia typu MIME). Używając Internet Explorer dla hostowania agenta czasu uruchomienia umożliwia nam osadzenie składników zarządzanych lub Windows Forms controls w dokumentach HTML.

 

HTML- kod niezarządzany

 

Windows Forms controls- kod zarządzany

 

Hostowanie czasu ruchomienia w ten sposób czyni zarządzany kod mobilny (managed mobile code), podobny do Microsoft® ActiveX® controls, możliwym, ale ze znaczącymi ulepszeniami, które tylko może zaoferować kod zarządzany, taki jak zaufane wykonanie (semi-trusted execution) i oddzielny plik przechowania (isolated file storage).

 

Ilustracja pokazuje związki CLR i class library z naszą aplikacją i z całym systemem. Pokazuje też jak działa kod zarządzany w większej architekturze.

 

 

 

Cechy Common Language Runtime

 

 

CLR zarządza:

 

– memory

 

– thread execution

 

– code execution

 

– code safety verification

 

– compilation, and other system services

 

Te cechy są wewnętrzne dla kodu zarządzanego, który działa na CLR.

 

Z powodu bezpieczeństwa komponenty zarządzane są wyróżniane różnymi stopniami zaufania, zależnie od liczby czynników, które zawierają swoje pochodzenie (takie jak Internet, sieć korporacyjna lub komputer lokalny). Tzn., że komponent zarządzany mógłby lub nie mógłby być w stanie wykonać operacje dostępu do pliku, operacje dostępu do rejestru lub inne wrażliwe funkcje, nawet jeśli to jest używane w tej samej aktywnej aplikacji.

 

Agent czasu uruchomienia narzuca bezpieczeństwo dostępu do kodu. Np. użytkownicy mogą wierzyć, że kod wykonywalny osadzony na stronie Web może grać animację na ekranie lub śpiewać piosenkę, ale jednocześnie nie może mieć dostępu do danych osobowych, systemu plików lub sieci. Cechy bezpieczeństwa agenta czasu uruchomienia w ten sposób uzasadniają oprogramowanie wykorzystywane w Internecie, aby ono było wyjątkowo bogate w cechy.

 

Agent czasu uruchomienia wymusza też solidność kodu przez dokładne implementowanie infrastruktury weryfikacji kodu i typu zw. common type system (CTS)–wspólny system typu. CTS zapewnia, że cały kod zarządzany jest samoopisujący. Różne kompilatory języka Miscrosoft i trzeciej strony generują kod zarządzany, który podporządkowuje się do CTS. Tzn., że kod zarządzany może pochłaniać inne typy (klasy) i instancje zarządzane, podczas dokładnego wymuszenia bezpieczeństwa typu i ścisłości.

 

Dodatkowo środowisko zarządzane agenta czasu uruchomienia eliminuje wiele pospolitych zagadnień software. Np. czas uruchomienia automatycznie obsługuje układ obiektu i zarządza odniesieniami do obiektów, zwalniając je, kiedy dłużej nie są potrzebne. To automatyczne zarządzanie pamięcią rozwiązuje dwa najczęstsze błędy aplikacji:

 

– wyciekanie pamięci

 

– nieważne odniesienia w pamięci

 

Czas uruchomienia też przyśpiesza produktywność programisty. Np. możemy pisać aplikacje w swoim języku i korzystać z agenta czasu uruchomienia, biblioteki klasy i komponentów napisanych w innych językach przez innych programistów. Jakikolwiek sprzedawca kompilatora, który wybiera jako cel agenta czasu uruchomienia, może to zrobić. Kompilatory języka, które celują w .NET Framework mają te cechy .NET Framework dostępnymi dla istniejącego kodu napisanego w tym języku, bardzo ułatwiając proces migracji dla istniejących aplikacji.

 

Podczas gdy środowisko uruchomienia jest przeznaczone dla oprogramowania przyszłości, to też wspiera dzisiejsze i wcześniejsze software. Interoperacyjność między kodem zarządzanym i niezarządzanym umożliwia deweloperom kontynuowanie użycia potrzebnych komponentów COM i DLL.

 

Środowisko uruchomienia jest przeznaczone dla zwiększenia wydajności. Chociaż CLR daje wiele standardowych usług agenta czasu uruchomienia, kod zarządzany nie jest nigdy interpretowany. Ta cecha kompilująca jest zw. just-in-time (JIT) i umożliwia całemu kodowi zarządzanemu działanie w języku maszyny natywnej systemu, na której jest wykonywana. Tymczasem menadżer pamięci usuwa te obszary pofragmentowanej pamięci i zwiększa odniesienie do położenia pamięci do dalszego podniesienia wydajności.

 

Ostatecznie agent czasu uruchomienia może być hostowany (goszczony) przez aplikacje po stronie serwera o wysokiej wydajności takie jak Microsoft® SQL Server™ i Internet Information Services (IIS). Ta infrastruktura umożliwia nam używanie kodu zarządzanego dla napisania naszego biznesowego logic, podczas ciągłego cieszenia się wysoką wydajnością serwerów korporacyjnych, które wspierają hosting czasu uruchomienia.

 

 

.NET Framework Class Library

 

 

Biblioteka klasy .NET Framework jest zbiorem typów (klas) wielokrotnego użytku, które ciasno integrują się z CLR. Jest ona OO, dając typy, z których nasz własny kod zarządzany może wyciągać funkcjonalność. To nie tylko czyni typy .NET Framework łatwymi w użyciu, ale też redukuje czas związany z uczeniem się nowych cech .NET Framework. Dodatkowo komponenty trzeciej strony mogą integrować się idealnie z klasami w .NET Framework.

 

Np. kolekcja klas .NET Framework implementuje zestaw interfejsów, które możemy użyć dla rozwijania naszej własnej kolekcja klas. Nasza kolekcja klas będzie idealnie mieszać się z klasami w .NET Framework.

 

nasze klasy ———————————————————————————-

 

interfejsA interfejsB interfejsC interfejsD interfejsE

 

——– ——– ——– ——– ——–

 

klasaA klasaB klasaC klasaD klasaE

 

bibl. klas —————————————————————————————————-

 

interfejs1 interfejs2 interfejs3 interfejs4 interfejs5 interfejs6

 

———- ———– ———– ———– ———– ———–

 

klasa1 klasa2 klasa3 klasa4 klasa5 klasa6

 

 

Jak z inną biblioteką klas OO, typy .NET Framework umożliwiają nam osiągnięcie zakresu powszechnych zadań programowania, w tym zadania takie jak:

 

– string management

 

– data collection

 

– database connectivity

 

– file access

 

Dodatkowo biblioteka klasy zawiera typy, które wspierają różne wyspecjalizowane scenariusze. Np. możemy użyć .NET Framework dla rozwoju następujących typów aplikacji i usług.

 

– Console applications.

 

– Windows GUI applications (Windows Forms).

 

– ASP.NET applications.

 

– XML Web services.

 

– Windows services.

 

Np. klasy Windows Forms są zrozumiałymi typami do ponownego użycia, co znacznie upraszcza rozwój Windows GUI. Jeśli piszemy aplikację ASP.NET Web Form, możemy użyć klas Web Forms.

 

 

Client Application Development

 

 

Aplikacje klienta są najbliżej do tradycyjnego stylu aplikacji w programowaniu opartym na Windows. Te typy są aplikacjami, które wyświetlają okna lub formy na pulpicie, umożliwiając użytkownikowi wykonanie zadania. Aplikacje klienta zawierają aplikacje takie jak procesory tekstu i arkusze kalkulacyjne, a także aplikacje biznesowe takie jak narzędzia wstawiania danych, narzędzia raportujące itp. Aplikacje klienta zazwyczaj używają okien, menus, guzików i innych elementów GUI i one mają dostęp do lokalnych zasobów takich jak system plików i urządzenia peryferyjne jak drukarki.

 

Innym rodzajem aplikacji klienta jest tradycyjny ActiveX control (teraz zastąpiony przez zarządzany Windows Forms control) wykorzystywany przez Internet jako strona Web. Ta aplikacja jest bardzo podobna do innych aplikacji klienta–to jest wykonywane natywnie, ma dostęp do lokalnych zasobów i zawiera elementy graficzne.

 

Kiedyś programiści tworzyli takie aplikacje używając C/C++ w połączeniu z Microsoft Foundation Classes (MFC) lub z środowiskiem rapid application development (RAD) takim jak Microsoft® Visual Basic®..NET Framework ma aspekty tych produktów w jednym zwięzłym środowisku programistycznym, które bardzo upraszcza programowanie klienckich aplikacji.

 

Klasy Windows Forms zawarte w .NET Framework są przeznaczone dla rozwoju GUI. Możemy łatwo tworzyć kontrolne okna, guziki, menus, paski narzędzi i inne elementy z elastycznością potrzebną dla potrzeb biznesu.

 

Np..NET Framework dostarcza prostych właściwości dla dostosowania wizualnych atrybutów skojarzonych z formami. W pewnych przypadkach podległy SO nie wspiera zmian tych atrybutów bezpośrednio i w tych przypadkach .NET Framework automatycznie tworzy po raz kolejny te formy. To jest jeden ze sposobów, jak .NET Framework integruje interfejs programistyczny, czyniąc kod łatwiejszym i bardziej zwięzłym.

 

Nie tak jak ActiveX controls, Windows Forms controls mają na wpół zaufany dostep do komputera użytkownika. Tzn., że te binaria lub natywnie wykonywany kod może mieć dostęp do pewnych zasobów na systemie użytkownika (takiego jak elementy GUI i ograniczony dostęp do pliku) bez możliwości dostępu lub narażenia innych zasobów. Z powodu bezpieczeństwa kodu, wiele aplikacji, które musimy zainstalować na systemie użytkownika może teraz być stosowana przez Web. Nasze aplikacje mogą implementować cechy lokalnej aplikacji, podczas stosowania jak strona Web. Rozwój intranetu w korporacjach jest oparty na technologii Web.

 

 

Server Application Development

 

 

Aplikacje po stronie serwera (który jest niezarządzanym hostem) w świecie zarządzanym są implementowane (wdrażane) przez hosty, które goszczą agenta czasu uruchomienia. CLR jest w niezarządzanych aplikacjach hosta i pozwala nam dostosować kod zarządzany tak, aby kontrolować zachowania tego serwera. Pozwala nam mieć na niego wpływ, chociaż jest niezarządzany. Mamy więc tu wpływ CLR na serwera. Ten model daje nam wszystkie te cechy, które ma CLR i biblioteki klasy, gdy jednocześnie zyskujemy na wydajności i skalowalności hostującego serwera. Bowiem serwer działa natywnie, czyli bez żadnych pośrednich etapów, ale część kodu jest zarządzana.

 

Ilustracja pokazuje schemat podstawowej sieci z kodem zarządzanym działającym w różnych środowiskach serwera. Serwery takie jak IIS i SQL Server mogą wykonywać standardowe operacje niezarządzane, gdy nasz logic aplikacji wykonywany jest przez kod zarządzany.

 

Server-side managed code

 

 

 

ASP.NET jest środowiskiem hostowania, które umożliwia programistom używanie .NET Framework dla aplikacji opartych na Web. Jednak ASP.NET jest czymś więcej niż tylko hostem agenta czasu uruchomienia–to jest kompletna architektura dla rozwoju witryn Web i obiektów dystrybuowanych Internetem przy użyciu kodu zarządzanego. Zarówno usługi Web Forms i XML Web używają IIS i ASP.NET jako mechanizmu publikacji dla aplikacji i obie mają zbiór wspierających klas w .NET Framework.

 

Usługi XML Web, ważna ewolucja w technologii opartej na Web, są dystrybuowanymi komponentami aplikacji po stronie serwera podobnymi do witryn Web. Jednak w przeciwieństwie do aplikacji opartych na Web, komponenty usług XML Web nie mają żadnego UI i nie są przeznaczone dla przeglądarek jak Internet Explorer i Netscape Navigator. Zamiast tego usługi XML Web składają się z ponownie używalnych komponentów software przeznaczonych do wchłonięcia przez inne aplikacje takie jak tradycyjne aplikacje klienckie, aplikacje oparte na Web lub nawet usługi XML Web. W rezultacie technologia usług XML Web szybko rozwija aplikacje i stosowanie w środowisku wysoce dystrybuowanym Internetu.

 

Jeśli mamy wcześniejsze wersje technologii ASP, natychmiast zauważymy, że są ulepszenia w ASP.NET i Web Forms. Np. możemy rozwijać strony Web Forms w jakimkolwiek języku wspierającym .NET Framework. Dodatkowo nasz kod już nie musi dzielić tego samego pliku z tekstem HTTP (chociaż to ciągle tak robi, jeśli tego chcemy). Strony Web Forms wykonują w języku natywnej maszyny, bo, jak inne aplikacje zarządzane, one wykorzystują agenta czas uruchomienia. W przeciwieństwie to tego strony ASP niezarządzanego są zawsze skryptowane lub interpretowane. Strony ASP.NET są szybsze, bardziej funkcjonalne i łatwiejsze dla rozwijania niż niezarządzane strony ASP, bo one wchodzą w interakcje z agentem czasemu uruchomienia jak jakkolwiek aplikacja zarządzana.

 

.NET Framework też daje zbiór klas i narzędzi do pomocy w rozwijaniu i wchłanianiu usług aplikacji XML Web. Usługi XML Web są zbudowane na standardach takich jak SOAP (protokół zdalnego wywołania procedury, a remote procedure-call protocol), XML (an extensible data format) i WSDL ( the Web Services Description Language)..NET Framework jest zbudowany na tych standardach dla promowania współpracy z rozwiązaniami nie-Microsoft.

 

Np. narzędzie Web Services Description Language zawarte w .NET Framework SDK może prosić usługę XML Web publikowaną na Web, parsować jej opis WSDL i wytwarzać kod źródłowy C# lub Visual Basic, który nasza aplikacja może użyć dla stania się klientem usługi XML Web. Ten kod źródłowy może tworzyć klasy pochodzące z klas w bibliotece klas, która obsługuje całą podległą komunikację używając SOAP i parsowania XML. Chociaż możemy używać biblioteki klas dla pochłonięcia usług XML Web bezpośrednio, narzędzie Web Services Description Language i inne narzędzia zawarte w SDK ułatwiają nam rozwój z .NET Framework.

 

Jeśli rozwijamy i publikujemy naszą własną usługę XML Web, .NET Framework dostarcza zestaw klas, które dostosowują się do wszystkich podległych standardów komunikacji takich jak SOAP, WSDL i XML. Używanie tych klas umożliwia nam skupienie się na logic naszej usługi bez koncentrowania się na infrastrukturze komunikacji wymaganej przez rozwój dystrybuowanego oprogramowania.

 

Ostatecznie, jak strony Web Forms w środowisku zarządzanym, nasza usługa XML Web będzie działa z szybkością języka natywnej maszyny używając skalowalnej komunikacji IIS.

 

 

Opisane języki programowania

 

 

Języki NET Framework:

 

 

Visual C# .NET

 

Visual Basic .NET

 

Visual C/C++ .NET

 

– J#

 

– JScript

 

Python .NET

 

 

Główną cechą, która wyróżnia platformę .NET wśród innych środowisk programistycznych, jest wsparcie wielu języków programowania. Umożliwia to grupom programistów o różnych umiejętnościach tworzenie komponentów oprogramowania w wybranych językach, a następnie połączenie opracowanych komponentów w dobrze współpracującą całość.

 

Wraz z wprowadzeniem CLR programiści uzyskali możliwość wyboru spośród szerokiej palety języków, co pozwala im programować w języku najbardziej odpowiadającym ich umiejętnościom i najlepiej nadającym się do wykonania otrzymanego zadania. Współpraca fragmentów kodu napisanych w różnych językach możliwa jest ze względu na to, że każdy język zgodny z platformą .NET Framework kompilowany jest do kodu MSIL, uruchamianego następnie w środowisku CLR.

 

Do języków platformy .NET zalicza się języki: Visual Basic, Visual C++ oraz Visual C#.

 

 

Visual C# .NET

 

 

C# to jedyny język programowania Microsoft, który został zaprojektowany od samego początku specjalnie dla platformy .NET i wspólnego środowiska uruchomieniowego CLR. Chociaż CLR obsługuje wiele języków, to tylko C# był projektowany równolegle z CLR. Te dwie technologie miały na siebie duży wpływ, przez co C# świetnie nadaje się do pisania kodu zarządzanego. Kod zarządzany komponentów platformy .NET, takich jak biblioteki klas i środowisko programistyczne ASP.NET, został napisany właśnie w języku C#.

 

C# jest znacznie prostszym językiem niż C++, jednak — jak sama nazwa wskazuje — należy do rodziny języków C. Oznacza to, że ma wiele cech wspólnych z C/C++, których nie mają języki takie jak Visual Basic. Na przykład C# rozróżnia wielkie i małe litery, a VB nie. C# wymaga od programistów jawnej konwersji pomiędzy typami danych, a Visual Basic dokonuje niektórych konwersji automatycznie. Składnia języka C# jest podobna do składni języków C++ i Java. C# ma jednak w stosunku do C++ kilka dodatkowych cech obiektowych, takich jak właściwości, atrybuty, delegaty czy zdarzenia.

 

W języku C# można także tworzyć kod „niebezpieczny”. W C# można na przykład uzyskać bezpośredni dostęp do pamięci zaalokowanej dla bufora i przeglądać tę pamięć przy użyciu wskaźników. Określenie „niebezpieczny” może wydawać się dość szokujące, jednak nie taki diabeł straszny, jak go malują. Niebezpieczny kod nie jest kodem, który jest źle napisany i ma luki. Nazywany jest „niebezpiecznym” dlatego, że niemożliwe jest sprawdzenie, czy kod bezpośrednio operujący na pamięci wykona niedozwoloną akcję.

 

 

Cechy języka Visual C# .NET

 

 

Wsparcie wszystkich typów danych CTS

 

Obsługa przekazywania parametrów przez referencje

 

Obsługa parametrów wyjściowych. W języku C# programiści mogą tworzyć parametry wyjściowe, wymagające inicjalizacji przed zakończeniem wykonywania funkcji, w której zostały zdefiniowane

 

Przeciążanie (overloading) operatorów

 

Możliwość stosowania wskaźników i bezpośredniego operowania na pamięci

 

Dokumentacja tworzonych rozwiązań w kodzie źródłowym w języku XML

 

 

Visual Basic .NET

 

 

Visual Basic jest uważany za najbardziej popularny język programowania aplikacji dla Windows. W wersji Visual Basic .NET wprowadzono do języka wiele zmian. Zmiany objęły między innymi sposób deklaracji zmiennych i funkcji, sposób tworzenia i usuwania obiektów, domyślny sposób przekazywania parametrów funkcji, sposób wywoływania procedur. Największe zmiany dotyczą chyba sposobu obsługi błędów — została usunięta stosowana do tej pory obsługa błędów, często nazywana „on error goto hell”. Visual Basic .NET w pełni wspiera strukturalną obsługę wyjątków.

 

Dzięki możliwości współdziałania platformy .NET Framework ze starszymi technologiami, kod napisany w Visual Basic .NET może wywoływać istniejący kod, napisany w starszych wersjach języka Visual Basic (i odwrotnie), dzięki czemu aplikacje na platformie .NET mogą wykorzystywać starsze moduły aplikacji.

 

Na platformę .NET przeniesiono jedynie główną odmianę języka Visual Basic. Nie został przeniesiony język skryptowy Visual Basic Scripting Edition (znany pod nazwą VBScript), wykorzystywany do tworzenia skryptów administracyjnych, stron ASP i dynamicznej zawartości stron internetowych oraz język Visual Basic for Applications (VBA) — język skryptowy wykorzystywany do pisania makr dla aplikacji rodziny Office.

 

 

Cechy języka Visual Basic .NET

 

 

Domyślna inicjalizacja zmiennych

 

Typy domniemane i późne wiązanie (nie trzeba określać typu zmiennej przed jej użyciem)

 

Bardziej intuicyjne stosowanie typów wyliczeniowych

 

Domyślny dostęp publiczny

 

Dostęp do współdzielonych elementów składowych klas może być realizowany zarówno poprzez nazwę klasy, jak też przez zmienną instancji klasy zawierającej te elementy

 

Możliwość stosowania parametrów opcjonalnych

 

Strukturalna obsługa wyjątków

 

Parametryzowane właściwości

 

Funkcje obsługi zdarzeń mogą deklarować obsługiwane przez siebie zdarzenia

 

Redeklaracja składowych w interfejsach

 

 

Visual C++ .NET

 

 

Visual C++ to bardzo popularny język programowania, nadający się zarówno do tworzenia kodu niskiego poziomu, jak i do pisania aplikacji dla Windows. W podstawowym języku C++ można pisać kod niezarządzany. Jednak w Visual C++ .NET wprowadzono obsługę nowych słów kluczowych i typów danych (zwanych rozszerzeniami Managed Extentions dla Visual C++), które umożliwiają pisanie kodu zarządzanego oraz tworzenie aplikacji w pełni korzystających z możliwości platformy .NET Framework.

 

Kompilator Visual C++ .NET nadal jest kompilatorem natywnym, co – wraz z zapewnianymi przez CLR możliwościami łączenia nowego kodu zarządzanego z istniejącym kodem niezarządzanym – pozwala programistom C++ nadal stosować dokładnie ten sam język i środowisko, którego używali do tej pory. Dodatkowo w Visual Studio .NET 2003, programiści C++, wykorzystujący rozszerzenia Managed Extensions do tworzenia aplikacji na platformę .NET, mogą stosować te same kreatory interfejsu użytkownika, których używają programiści języków Visual Basic i C#. Wcześniej programiści C++ musieli korzystać z biblioteki MFC lub pisać interfejsy użytkownika ręcznie, co trwało dużo dłużej i było związane z większą liczbą błędów.

 

 

Cechy języka Visual C++ .NET

 

 

Szablony umożliwiające wielokrotne wykorzystywanie kodu i zwiększenie wydajności

 

Wskaźniki dające bezpośredni dostęp do pamięci systemu

 

Wielokrotne dziedziczenie

 

Funkcje wbudowane, umożliwiające dostęp do ważnych funkcji platformy sprzętowej

 

Atrybuty kompilacji, umożliwiające szybkie tworzenie zoptymalizowanego kodu do wielokrotnego wykorzystania

 

Wsparcie kodu 32- i 64-bitowego

 

 

Python .NET

 

 

IronPython to pełnoprawna implementacja języka Python, zanim więc poruszone zostaną bardziej zaawansowane przypadki jego użycia lub integracji z platformą .NET, warto zrobić bardziej dokładne wprowadzenie do samego języka.

 

Artykuł ten jest kolejnym z cyklu artykułów poświęconych wsparciu technologii .NET dla dynamicznych języków programowania na przykładzie języka Python.

 

Python for .NET jest pakietem, który daje programistom Pythona prawie idealną intergację z .NET Common Language Runtime (CLR) i dostarcza silnego narzędzia skryptowania aplikacji dla programistów .NET. Używając tego pakietu możemy skryptować aplikacje .NET lub budować całe aplikacji w Pythonie używając usług .NET i komponentów napisanych w jakimkolwiek języku, który ma na celu CLR (Managed C++, C#, VB, JScript).

 

Ten pakiet nie implementuje Pythona jako pierwszej klasy język CLR- to nie daje zarządzanego kodu (IL) z kodu Pythona. To jest raczej integracja silnika C Pythona z agentaem czasu uruchomienia .NET. To podejście pozwala nam użyć usług CLR i kontynuować użycie istniejacego kodu Pythona irozszerzeń opartych na C podczas utrzymania natywnej szybkości wykonania dla kodu Pythona. Jeśli szukamy czytej implementacji Pythona zarządzanego kodu, trzeba sprawdzić projekt IronPython, który jets prawdziwym Pythonem for .NET, kompatybilnym z Pythonen releases 2.3 i wyższej.

 

 

Wskazówki dotyczące wyboru języka

 

 

Przy języku C++ powinni pozostać programiści, którzy dobrze znają ten język i piszą nowe aplikacje natywne. Natomiast programiści, którzy adaptują kod istniejących aplikacji natywnych, przenosząc go do platformy .NET, powinni skorzystać z rozszerzeń Managed Extensions dla C++.

 

 

Programiści C++, którzy tworzą nowe aplikacje i komponenty, wykorzystywane przez innych programistów, powinni używać języka C# lub rozszerzeń Managed Extensions dla C++.

 

Język C# jest najbardziej atrakcyjny dla programistów, którzy znają Visual C++ lub język Java oraz dla zaawansowanych programistów Visual Basic, którzy tworzą komponenty i szukają łatwego do opanowania języka, wykorzystującego środowisko CLR i biblioteki klas .NET Framework.

 

Programiści Visual Basic, którzy korzystają z bardziej zaawansowanych możliwości języka, mogą uznać C# za przydatne narzędzie dodatkowe.

 

Zaawansowani programiści, korzystający do tej pory z języka Visual Basic i często odwołujący się bezpośrednio do systemu operacyjnego oraz jego funkcji, mogą nadal pisać w tym języku komponenty niższego poziomu, które będą na przykład wykorzystywane przez innych programistów. Jednak ze względu na fakt, że komponenty te będą wykorzystywane przez innych, warto jest zastanowić się nad programowaniem ich w bardziej rygorystycznym języku zorientowanym obiektowo, takim jak C#.

 

C# jest także dobrym wyborem dla programistów, którzy znają już język Java lub J++ i chcą skupić się na pisaniu nowych aplikacji.

 

Język J# .NET powinien spodobać się wszystkim programistom, którzy programowali w języku J++ i dobrze znają składnię języka Java, ale chcieliby przejść na platformę .NET lub przenieść na nią istniejące aplikacje napisane w języku J++.

 

 

Porównanie .NET z J2EE

 

 

Firma Sun jest producentem platformy programistycznej, konkurencyjnej w stosunku do platformy Microsoft .NET Framework – Java 2 Enterprise Edition (w skrócie J2EE). Założenia projektowe oraz architektura obydwu platform są podobne, jednak sposób ich implementacji jest całkowicie inny.

 

 

Podobne misje

 

 

Zarówno platformę .NET, jak i J2EE projektowano z myślą o zwiększeniu produktywności programistów. Cel ten osiągnięto poprzez udostępnienie gotowych komponentów (programiści nie muszą już poświęcać wiele czasu na pisanie procedur niskiego poziomu).

 

Obydwie platformy cechuje większa niezawodność. Uzyskano ją, ograniczając w językach programowania stosowanie konstrukcji, których użycie często prowadziło do błędów (taką konstrukcją są na przykład wskaźniki, które dają bezpośredni dostęp do pamięci operacyjnej). W obydwu platformach zastosowano również bardziej restrykcyjne modele programowania, wymuszające ścisłe deklarowanie zmiennych. Kolejnym celem, jaki postawiono twórcom tych platform, było zwiększenie bezpieczeństwa. Osiągnięto go dzięki stosowaniu podpisów cyfrowych oraz kontroli praw nadawanych aplikacjom.

 

Wspólną cechą .NET i J2EE jest także uproszczenie procesu instalacji i wdrażania rozwiązań. Aplikacje, zbudowane w oparciu o te platformy, mogą być automatycznie instalowane na żądanie, a proces instalacji często nie wymaga żadnej interwencji ze strony użytkownika bądź administratora.

 

 

Podobna architektura

 

 

Ze względu na podobne cele, platformy .NET i J2EE mają także podobną architekturę. W obydwu platformach wprowadzono maszynę wirtualną, wykorzystywaną do sprawdzania, ładowania i wykonywania programów w ściśle kontrolowanym środowisku. Takie rozwiązanie ogranicza możliwości ataków wirusów lub niepoprawnych akcji zaufanego kodu. W przypadku platformy .NET maszyną wirtualną jest CLR, a w przypadku J2EE – Maszyna Wirtualna Java. Dzięki zastosowaniu w językach programowania ścisłego dopasowania typów oraz modułów odzyskiwania pamięci zmniejszyło się także prawdopodobieństwo wystąpienia błędów.

 

Biblioteka klas zapewnia programistom wiele przydatnych funkcji, takich jak obsługa uwierzytelniania i wielu protokołów, czy podłączanie się do zewnętrznych źródeł danych. Programiści nie muszą już wszystkiego wymyślać i kodować od podstaw.

 

Na obydwu platformach można tworzyć tradycyjne aplikacje oraz aplikacje internetowe. Technologią tworzenia aplikacji internetowych na platformie .NET jest ASP.NET, a na platformie J2EE jest to technologia Java Server Pages.

 

 

Wybór platformy

 

 

Platformy .NET Framework oraz J2EE mają bardzo podobną architekturę oraz możliwości, dlatego decyzja co do wyboru platformy nie zależy od sfery technicznej. Przy wyborze platformy warto zwrócić uwagę na następujące zagadnienia:

 

– wsparcie usług internetowych – Java i towarzyszące jej biblioteki klas są starsze niż idea usług internetowych, dlatego Sun musiał przepisać istniejące interfejsy API tak, by wspierały XML i usługi internetowe. W przypadku platformy .NET obsługę XML i usług internetowych zaimplementowano od razu podczas tworzenia platformy .NET,

 

– umiejętności programistów – przy wyborze platformy decydujące znaczenie może mieć liczba programistów znających poszczególne języki programowania,

 

– dostępność narzędzi – wraz z wprowadzeniem technologii .NET, Microsoft wprowadził także wiele ulepszeń do środowiska programistycznego Visual Studio. Z językiem Java nie są związane żadne środowiska programistyczne, które budziłyby taki entuzjazm programistów, jaki budzi Visual Studio,

 

– przenośność i interoperacyjność – aplikacje napisane w języku Java można łatwiej przenosić pomiędzy różnymi platformami. Natomiast wspólne środowisko uruchomieniowe CLR platformy .NET zapewnia większą interoperacyjność między kodem .NET a kodem napisanym dla istniejących platform Windows, niż Java może zapewnić po przeniesieniu na platformę Windows.

 

 

Opis Microsoft .NET Framework

 

 

Wiele zespołów ISVs korporacji i Microsoft dla produktów z sukcesem buduje nowe cechy: Windows Workflow Foundation (WF), Windows Communication Foundation (WCF), Windows Presentation Foundation (WPF) i Windows CardSpace w.NET Framework 3.0.

Microsoft planuje kontynuować inwestowanie w .NET Framework i we wsparcie .NET Framework 3.5. Dlatego istniejące aplikacje zbudowane dla .NET Framework 2.0 lub .NET Framework 3.0 powinny działać bez wprowadzenai zmian na .NET Framework 3.5.

 

.NET Framework 3.5 dodaje nowe cechy, w tym:
– Głęboka integracja Language Integrated Query (LINQ) i świadomość danych
– ASP.NET AJAX dla szybkiego tworzenia bardziej wydajnych, bardziej interaktywnych i wysoko-spersonalizowanych Web, które działają na wszystkich popularnych przeglądarkach.

 

– Nowy protokół Web wspiera budowanie usług WCF, w tym AJAX, JSON, REST, POX, RSS, ATOM i kilka standardów WS-*.
– Pełne narzędziowe wsparcie dla WF, WCF i WPF, w tym nowa technologia usług dla

 

– Nowe klasy w base class library (BCL) dla .NET Framework 3.5 adresującego najbardziej powszechne prosby klientów.

 

.NET Framework 3.5 wyszedł w w końcu 2007 roku z kodem Visual Studio zw. “Orcas”.
Microsoft .NET Framework 3.0 (który jest znany jako WinFX), nowym modelem zarządzania kodem programowania dla Windows. To łączy siłę .NET Framework 2.0 z nowymi technologiami dla budowania aplikacji:

 

– Windows Presentation Foundation

 

– Windows Communication Foundation

 

– Windows Workflow Foundation

 

– Windows CardSpace (znanu jako “Infocard”).

 

.NET Framework 3.0 może być zainstalowany na systemach:
· Microsoft Windows 2003 Server Service Pack 1 (SP1)
· Windows XP SP2
· Windows Vista
Windows Vista jest z .NET Framework 3.0. Nie jest wymagana oddzielna instalacja pakietu i dlatego samodzielny .NET Framework 3.0 nie jest wsparty przez Vista.

 

 

Microsoft Connected Services Framework 3.0 Service Pack 1 Enterprise Edition

 

 

Microsoft Connected Services Framework jest zintegrowanym pakietem opartym na serwerze dla budowania i zarządzania usługami przez użycie service-oriented architecture (SOA). Dla operatorów telekomunikacyjnych i innych dostawców usług, CSF umożliwia im zebranie, dostarczenie i zarządzanie połączonymi usługami telekomunikacyjnymi dla swoich abonentów w wielu sieciach i wielu typach urządzeń.

 

Microsoft Connected Services Framework 3.0 Service Pack 1 (SP1) adresuje wiele zapytań wysokiego priorytetu od naszych lientów, w tym usprawnienie w ustawieniu i konfiguracji komponentów CSF. CSF 3.0 SP1 też wspiera usługi oparte na WCF, które zawierają widomości oparte na WS i lepsze wykonanie. Można to ściągnąć z Connected Services Framework 3.0 EE SP1

 

 

Wymagania Microsoft Connected Services Framework 3.0 Service Pack 1 Enterprise Edition:

· Internal Information Services 6.0
· Active Directory (Functional Level 2000)
· Microsoft .NET Framework 2.0
· Microsoft SQL Server 2000 Service Pack 4 (SP4), or 2005 SP1
· Windows Support Tools 2003 SP2
· Microsoft Operations Manager 2005 SP1
· UDDI 2.0
· Enterprise Single Sign-On 3.0
· Microsoft Clusting Server (if clustering is required)
· Microsoft Management Console 3.0
· Web Service Enhancement 3.0

Microsoft .NET Framework 3.0 Service Pack 1 Language Packs zawiera przetłumaczony tekst taki jak wiadomości o błędach dla języków innych niż angielski. Bez instalacji Language Pack, te wiadomości są wyświetlane domyślnie po angielsku. Wiele pakietów jezykowych każdy dla innego jezyka moze być zainstalowanych na pojedycnzym komputerze. Microsoft .NET Framework 3.0 SP1 Language Packs zawiera przetłumaczony tekst jak i wiadomości o błędach dla każdeog jezyka.
The following Language Packs are designed for NET Framework 3.0 SP1 x86 ONLY : French , Greek , Spanish , Italian , German , Japanese.
The following Language Packs are designed for NET Framework 3.0 SP1 x64 ONLY : French , Spanish , Italian , German , Japanese.

.NET Framework 3.0 Service Pack 2 Update for Windows Server 2003 and Windows XP
Są pewne niekompatybilności w ogólnych typach używając BinaryFormatter lub NetDataContractSerializer serializowanego i deserializowanego przez zmieszane środowisko .NET Framework 3.5 SP1 i .NET Framework 4. Instalując to uaktualnienie dostajemy to też.

Microsoft .NET Framework 3.5 Service pack 1 Beta

Microsoft .NET Framework 3.5 service pack 1 jest skumulowanym uaktualnieniem, który zawiera wiele nowych cech budujących wzrostowo na .NET Framework 2.0, 3.0, 3.5 i zawiera zebrane uaktualnienia .NET Framework 2.0 service pack 2 i .NET Framework 3.0 service pack 2.

.NET Framework version 3.5 Service Pack 1 dostarcza następujących cech i ulepszeń:

 

ASP.NET Dynamic Data, które dostarcza bogatego framework, który pozwala na szybki rozwój danych bez pisania kodu i nowy dodatek do ASP.NET AJAX, który dostarcza wsparcia dla zarządzania historią przeglądarki (wsparcia przycisku powrotengo).

 

– Ulepszenia dla CLR, które zawiera lepsze wykorzystanie natywnych obrazów .NET Framework, wycofania się z weryfikacji strong-name dla w pełni zaufanych zestawów składowych, ulepszonego wykonania startu aplikacji, lepszego generowanai kodu, który ulepsza czas wykonania aplikacji od początku do końca i optowania za kodem zarządzanym dla uruchomienia w trybie ASLR (Address Space Layout Randomization), jeśli to jest wsparte przez SO. Dodatkowo zarządza aplikacjami, które są otwierane z sieci, dzielących to samo zachowanie jako natywne aplikacje przez uruchomienie z pełnym zaufaniem.

 

– Ulepszenie wykonania dla Windows Presentation Foundation, w tym szybszy czas uruchomienia i ulepszone wykonanie dla wyników Bitmap. Dodatkowa funkcjonalność dla WPF, w tym lepsze wsparcie dla aplikacji biznesowych, wsparcie natywnego ekranu spalsh, wspracie DirectX pixel shader, i nowa WebBrowser control.

 

– Publikacje aplikacji ClickOnce mogą decydować o wycofaniu sie z podpisywania i haszowania jako odpowiedniego dla ich scenariuszy, programiści mogą programistycznie instalować aplikacje ClickOnce, które wyświetlają dostosowane cechowanie i okienko dialogowe błędu ClickOnce łączy z witryną Web wspartą specyficznie dla aplikacji.

 

Entity Framework jest ewolucją zestawu technologii dostępu do danych .NET. Entity Framework pozwala programistom programować dla relacyjnych baz danych pod względem modeli specyficznych dla aplikacji zamiast podległych modeli baz danych.

 

The Entity Framework wprowadza pewne dodatkowe cechy, w tym wsparcie dla nowych typów SQL Server 2008, domyślny graf serializacji dla Entities, i pierwsza szeroko publiczne wydanie Entity Data Source. Z tym wydaniem, Entity Framework wspiera nowe możliwości daty i strumieni plikowych w SQL Server 2008. Graf serializacji pomaga programistom, którzy chcą budować usługi Windows Communication Foundation (WCF), których pełny model przedstawia na wykresie jako kontrakty danych (data contracts). Entity Data Source dostarcza tradycyjnego znajdowania źródła danych dla programistów aplikacji ASP.NET, którzy chcą pracować z Entity Framework.

 

– LINQ dla SQL zawiera nowe wsparcie dla możliwości nowej daty i strumienia pliku w SQL Server 2008.

 

ADO.NET Data Services Framework składa się z połączenia wzorców i bibliotek, które umożliwiają danym ujawnienie jako elastyczna usługa danych oparta na REST (Representational State Transfer), która może być pochłonięta przez klientów Web w tworzeniu korporacyjnej sieci lub przez Internet. ADO.NET Data Services Framework czyni tworzenie usługi danych przez jakiekolwiek źródo danych. Model konceptualnego widoku podległego schematu przechowywania może łatwo być ujawniony przez bogatą integrację z ADO.NET Entity Framework. Usługi tworzone przez użycie .NET Data Services Framework, a także kompatybilne usługi Windows Live (dev.live.com), mogą być łatwo dostępne z jakiejkolwiek platformy. Dla klienckich aplikacji działających na platformach Microsoft, zestaw bilbiotek klienkich jest dostarczony dla interakcji z prostymi usługami danych. Np.

 

Klienci oparci na .NET Framework mogą używać LINQ dla proszenia o usługi danych i warwtę obiektu prostego .NET Framework dla uaktualnienia danych w danej usłudze.

 

Windows Communication Foundation teraz czyni DataContract Serializer łatwiejszym dla użycia przez dostarczenie wsparcia ulepszonej interoperacyjności, wzbogacając debugowanie w częściowo zaufanych scenariuszach i rozszerzając wsparcie protokołu syndykacji dla szerszego użycia w aplikacjach Web 2.0.

 

.NET Framework Data Provider for SQL Server (SqlClient) dodaje nowe wsparcie dla strumienia pliku i nelicznych zdolność kolumnowania w SQL Server 2008.
Inne wersje:
· Expression Blend (all versions)
· Silverlight 2 Beta 1 SDK
· Silverlight Tools Beta 1 for Visual Studio 2008

 

Ustawiamy zmienne śrdowiskowe dla narzędzi Microsoft .NET Framework v2.0 SDK. Lista narzędzi SDK jest w pliku ‘StartTools.htm’ w folderze bin.

 

 

Kompilatory SDK

 

 

– Visual Basic vbc .vb

 

– Visual C# csc .cs

 

– Visual J# vjc .jsl

 

– Visual C cl .c

 

– Visual C++ cl .cpp

 

– Visual JScript jsc .js

 

 

Visual Basic

 

 

D:\>vbc HelloWorld.vb

 

Microsoft (R) Visual Basic Compiler version 8.0.50727.42

 

for Microsoft (R) .NET Framework version 2.0.50727.42

 

Copyright (c) Microsoft Corporation. All rights reserved.

 

D:\>HelloWorld

 

HelloWorld

 

D:\>

 

 

Visual C#

 

 

D:\>csc HelloWorld.cs

 

Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.42

 

for Microsoft (R) Windows (R) 2005 Framework version 2.0.50727

 

Copyright (C) Microsoft Corporation 2001-2005. All rights reserved.

 

D:\>HelloWorld

 

HelloWorld

 

D:\>

 

 

Visual J#

 

 

D:\> vjc HelloWorld.jsl

 

Microsoft Visual J# (R) Compiler version 8.0.50727.42

 

for Microsoft (R) .NET Framework version 2.0.50727

 

Copyright (C) Microsoft Corp 2000-2002. All rights reserved.

 

D:\>HelloWorld

 

HelloWorld

 

D:\>

 

 

Visual C

 

 

D:\ >cl HelloWorld.c

 

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80×86

 

Copyright (C) Microsoft Corporation. All rights reserved.

 

D:\>HelloWorld

 

HelloWorld

 

D:\>

 

 

Visual C++

 

 

D:\ >cl HelloWorld.cpp

 

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80×86

 

Copyright (C) Microsoft Corporation. All rights reserved.

 

D:\>HelloWorld

 

HelloWorld

 

D:\>

 

 

JScript

 

 

D:\ >jsc HelloWorld.js

 

Microsoft (R) JScript Compiler version 8.00.50727

 

for Microsoft (R) .NET Framework version 2.0.50727

 

Copyright (C) Microsoft Corporation 1996-2005. All rights reserved.

 

D:\>HelloWorld

 

HelloWorld

 

D:\>

 

 

ASP.NET

 

 

Tworzymy projekt ASP.NET używając VB.NET i C#.

 

1. Startujemy nowy dokument albo w Visual Studio.NET albo w edytorze tekstu.

 

2. Wprowadzamy kod i zapisujemy jako HelloWorld.ASPX w naszym folderze root Web.

 

<html>

 

<head>

 

<title>Example 1: Hello World</title>

 

</head>

 

<body bgcolor=white>

 

<h1>

 

<% response.write(“Hello World”) %>

 

</h1>

 

</body>

 

</html>

 

3. Uruchamiamy przegladarkę i wprowadzamy ścieżkę do naszego pliku, np.

 

localhost/helloworld.aspx

 

Musimy zobaczyć coś jak na obrazku 1.4.

 

 

 

 

Ten HTML powinien być znany webmasterom, bo to jest po prostu zwykła strona Web. Zasadniczą różnicą jest dodatek kodu w tagach <% i %>. To jest właśnie nasz kod ASP.NET. Domyślnie ASP.NET używa języka VB.NET (możemy też stosować inne jak C#).

 

<% response.write(“Hello World”) %>

 

Ten kod każe serwerowi dać dane wyjściowe w postaci tekstu “Hello World” do przeglądarki użytkownika. Alternatywnym skrótem dla wartości danych wyjściowych ma być użycie następującej formy, gdzie wartość jest zmienną lub literałem, który ma być w danych wyjsciowych.

 

<%=value%>

 

<% response.write=Hello World %>

 

 

Kompilowanie i wyświetlenie stron ASP.NET

 

 

Proces kompilacji i wyświetlania stron ASP.NET:

 

1. IIS dopasowuje URL w zapytaniu do pliku na dysku twardym przez przetłumaczenie ścieżki wirtualnej (np. /site/index.aspx) na ścieżkę względną w roocie Web witryny (np. d:\domains\thisSite\wwwroot\site\index.aspx).

 

2. Kiedy dany plik jest znaleziony, rozszerzenie pliku (.aspx) jest dopasowywane z listą znanych typów plików zarówno dla wysłania do klienta jaki i do przetworzenia.

 

3. Jeśli to są pierwsze odwiedziny na stronie web, jak plik został zmieniony, kod ASP jest kompilowany do zestawu składowego (assembly) przy użyciu kompilatora CLR na MSIL i potem na kod binarny specyficzny dla maszyny do wykonania.

 

4. Ten kod binarny jest klasą .NET .dll i jest przechowywany w tymczasowej lokacji.

 

5. Nastepnym razem, gdy strona jest poproszona, serwer sprawdzi, czy ten kod został zmieniony. Jeśli ten kod jest taki sam, wtedy ten proces kompilacji jest pomijany i poprzednia skompilowana klasa jest wykonywana; inaczej, kiedy kod zmieniony, ta klasa jest kasowana, bo jest nieaktualna, i ponownie kod jest kompilowany z nowego źródła na nową klasę.

 

6. Skompilowany kod jest wykonywany i wartości zapytania są interpretowane takie jak pola danych wejściowych formularza lub parametry URL. (kod + dane dostarczone przez użytkownika).

 

7. Jeśli programista użył Web forms, wtedy serwer może wykryć, jakiego software używa klient i zwrócić strony, które są dostosowane do wymagań klientów, np. zwracając kod specyficzny dla Netscape lub kod Wireless Markup Language (WML) dla urządzeń mobilnych.

 

8. Jakiekolwiek wyniki są z powrotem dostarczane do przegladarki Web klienta.

 

9. Elementy formularza są konwertowane np. na znaczniki po stronie klienta i skrypt, HTML i JavaScript dla przeglądarek Web lub na WML i WMLScript dla urządzeń mobilnych.

 

 

Architektura .NET Framework (Chapter 1)

 

 

Platforma rozwojowa .NET Framework wprowadza nowe koncepty, technologie i terminy. Tu też jest proces budowania naszego kodu źródłowego w aplikację lub zestaw redystrybuowanych komponentów (typów, klas) i potem pokazanie jak te komponenty są wykonywane.

 

 

Kod źródłowy—->Komponenty—->Aplikacja

 

 

Kompilowanie kodu źródłowego w moduły zarządzane (Managed Modules)

 

1/ Najpierw ustalamy typ aplikacji lub komponentu, który zamierzamy zbudować. Mamy projekt, zapisujemy specyfikacje i możemy je rozwijać.

 

2/ Wybieramy język programowania. Np. niezarządzany C/C++ mamy kontrolę SO na niskim poziomie. Możemy zarządzać pamięcią dokładnie jak chcemy, tworzyć wątki itp.

 

Visual Basic 6 pozwala nam budować aplikacje UI szybko i mamy łatwą kontrolę obiektów COM i baz danych.

 

Jeśli używamy .NET Framework, nasz kod ma na celu CLR, co ma wpływ na naszą decyzję o języku programowania. W czasie uruchomienia CLR nie wie, jakiego języka używamy do rozwijania naszego kodu źródłowego bo to jest IL taki sam dla każdego jezyka (to jest tylko ważne przy kompilacji). Tzn., że używamy takiego języka, jaki nam odpowiada, pod warunkiem jednak, że używany przez nas kompilator skompiluje nasz kod w sposób, który ma na celu CLR. Wtedy bowiem mamy IL, którego możemy uruchomić.

 

Kompilatory sprawdzają składnię i poprawność kodu. Sprawdzają, czy ma to sens i potem dają kod wyjściowy, który opisuje nasze intencje. Różne programy pozwalają nam rozwijać używając różnej składni. Np. przy APL zaoszczędzimy dużo dni w porównaniu z Perlem, kiedy tworzymy aplikacje matematyczne czy finansowe.

 

Microsoft tworzy kilka kompilatorów językowych, które mają na celu tego agenta uruchomienia CLR:

 

– C++ with managed extensions,

 

– C# (pronounced “C sharp”)

 

– Visual Basic.NET

 

– JScript

 

– Java (J#)

 

– intermediate language (IL) Assembler

 

Dodatkowo inne firmy tworzą kompilatory, które dają kod, który ma na celu CLR:

 

– Alice

 

– APL

 

– COBOL

 

– Component Pascal

 

– Eiffel

 

– Fortran

 

– Haskell

 

– Mercury

 

– ML (machine language)

 

– Mondrian

 

– Oberon

 

– Perl

 

– Python

 

– RPG

 

– Scheme

 

– Smalltalk.

 

 

 

The figure on the next page shows the process of compiling source code files.

 

 

Możemy tworzyć pliki kodu źródłowego używając jakiegokolwiek języka programowania, który wspiera CLR. Potem używamy odpowiedniego kompilatora dla sprawdzenia składni i analizy kodu źródłowego. Bez względu na to, jaki kompilator będzie używany, rezultatem będzie moduł zarządzany takiego samego rodzaju. Jest to standardowy przenośny plik wykonywalny Windows (standard Windows portable executable (PE) file), który wymaga CLR do jego wykonania. W przyszłości inne SOs mogą używać też format pliku PE. Moduł zarządzany składa się z:

 

Nagłówek PE (PE header)- typ pliku, czas powstania, informacje o kodzie natywnym

 

To jest standardowy nagłówek pliku PE Windows, który jest podobny do nagłówka Common Object File Format (COFF). Nagłówek PE wskazuje typ pliku–GUI (interfejs graficzny), CUI (interfejs konsoli), DLL (biblioteka)–i też ma stempel czasu wskazujący, kiedy ten plik został zbudowany. Dla modulów, które zawierją tylko kod IL (Intermediate Language Code), większość informacji w nagłówku PE jest ignorowana. Dla modulłów, które zawierają też dodatkowo natywny kod CPU (niezarządzany), ten nagłówek zawiera informacje o natywnym kodzie CPU.

 

Nagłówek CLR (CLR header )- wersja CLR, flagi, metoda Main, informacje o metadane

 

Ten nagłówek zawiera te informacje (interpretowane przez CLR i narzędzia), które czynią to zarządzanym modułem. To zawiera wersję wymaganego CLR, pewne flagi, token metadanych MethodDef metody punktu wejściowego zarządzanego modułu (metoda Main) i lokalizację/rozmiar metadanych, zasobów, strong name, pewne flagi i inne rzeczy zarządzanego modułu.

 

Metadane (Metadata)- tablice metadanych (w kodzie i odniesione)

 

Każdy zarządzany moduł zawiera tablice metadanych, w których są dwa główne typy– ten opisujący typy i członków zdefiniowanych w naszym kodzie źródłowym i ten opisujący te typy i członków odnoszonych przez nasz kod źródłowy.

 

Moduł zarządzany:

 

Nagłówek PE

 

——————

 

Nagłówek CLR

 

——————

 

Metadane

 

—————————————————————————————————————–

 

typy i członki w kodzie źródłowym typy i członki odniesione przez nasz kod

 

(typy loklane i ich członki) (typy importowane i ich członki)

 

 

Kod Intermediate Language (IL)

 

 

To jest kod, który powstaje przez działalność kompilatora jak kompilowany jest kod źródłowy. IL jest potem kompilowany przez CLR na natywne instrukcje CPU.

 

Kompilator CLR

 

Kod źródłowy————–>Język pośredni (IL)————->natwne instrukcje CPU

 

 

Większość kompilatorów kiedyś tworzyło kod mający na celu określoną architekturę CPU taką jak x86, IA64, Alpha lub PowerPC. Wszystkie kompilatory zgodne z CLR dają zamiast tego kod intermediate language (IL), czyli język pośredni. Kod IL odnosi się czasami do kodu zarządzanego, bo jego czas życia i wykonanie jest zarządzane przez CLR.

 

Dodatkowo w trakcie wydzielania IL każdy kompilator mający na celu CLR musi dla emitować wszystkie metadane do każdego zarządzanego modułu, który tworzy. W skrócie, metadane są po prostu zestawem tablic, które opisują co jest w danym module, takie jak typy (klasy) i ich członki (members). Dodatkowo metadane mają też tablice wskazujące, do czego dany zarządzany moduł się odnosi, takie jak importowane typy (imported types) i ich członki (members). Metadane są superzestawem starszych technologii takich jak biblioteki typów (type libraries) i pliki IDL. Rzeczą godną uwagi jest to, że metadane CLR są daleko bardziej kompletne niż ich poprzednicy. Nie tak jak biblioteki typów i IDL, metadane są zawsze skojarzone z danym plikiem, który zawiera kod IL. W rzeczywistości te metadane są zawsze osadzone w tym EXE/DLL co dany kod, czyniąc to niemożliwym dla oddzielenia ich obu.

 

 

moduł zarządzany = metadane + kod

 

 

Skoro metadane i sam kod są wytwarzane przez kompilator w tym samym czasie i są złączone w jeden zarządzany moduł, kod IL i metadane, które to opisują, nie są nigdy niezsynchronizowane ze sobą.

 

Metadane mają wiele użyć. Oto niektóre:

 

– metadane usuwają całą potrzebę dla headera i biblioteki plików podczas kompilacji, bo wszystkie informacje o odniesionych typach/członkach są zawarte w jednym pliku razem z IL, który implementuje te typy/członki. Kompilatory mogą odczytywać metadane bezpośrednio z zarządzanych przez siebie modułów i nie muszą sięgać gdzieś na zewnątrz.

 

-Visual Studio używa metadanych dla pomocy w pisaniu kodu. Jego cecha IntelliSense parsuje metadane, aby powiedzieć nam, jakie metody dany typ (klasa) oferuje i jakich parametrów ta metoda oczekuje.

 

– Proces weryfikacji kodu CLR używa metadanych dla zapewnienia, że nasz kod wykonuje tylko bezpieczne operacje.

 

– Metadane pozwalają polom obiektu (zmiennym) być podzielonym w bloki pamięci w innej maszynie, odległe od danej maszyny, przy której aktualnie jesteśmy. Potem na naszej maszynie składane są one w jeden obiekt i odtwarzany jest jego stan, który był na odległej maszynie.

 

– Metadane pozwalają zbieraczowi śmieci śledzić czas życia obiektów. Dla każdego obiektu zbieracz śmieci ustala typ obiektu i z metadanych wie, jakie pola w tym obiekcie odnoszą się do innych obiektów. Jeśli nie ma odniesień, dany obiektu, już nie jest potrzebny, jest usuwany z pamięci.

 

Cztery kompilatory oferuje Microsoft offers–C#, Visual Basic, JScript i IL Assembler– które zawsze dają zarządzane moduły, które wymagają CLR do wykonania. Czyli użytkownicy końcowi muszą mieć zainstalowany obowiązkowo CLR na swoich maszynach, aby wykonać jakiekolwiek zarządzane moduły z IL. Ta sytuacja jest podobna do tej, którą mają użytkownicy końcowi z aplikacjami MFC (Microsoft Foundation Classes) lub VB 6: aby je uruchomić muszą mieć zainstalowany MFC lub VB DLLs.

 

Domyślnie kompilator C++ Microsoftu buduje niezarządzane moduły: pliki EXE lub DLL. Te moduły nie wymagają CLR do wykonania, bo nie są w żadnym pośrednim języku (jak IL), ale są od razu kodem natywnym zdolnym do wykonania na danej maszynie. Jednak przez określenie nowego przełącznika wiersza polecenia, kompilator C++ może dawać zarządzane moduły, które wymagają już CLR do wykonania, bo daje najpierw IL. Ze wszystkich wymienionych kompilatorów Miscrosoft, C++ jest unikalny w tym, że to jest jedyny język, który pozwala programiście pisać zarówno zarządzany jak i niezarządzany kod i nakazać temu ostatniemu emisję do pojedynczego modułu zarządzanego. To jest dobra cecha, bo to pozwala programistom napisać wiele z aplikacji w zarządzanym kodzie (dla bezpieczeństwa typu i interoperacyjności komponentu), ale mamy ciągle dostęp do ich istniejącego niezarządzanego kodu C++.

 

 

Łączenie Zarządzanych Modułów (Managed Modules) w zestawy składowe (Assemblies)

 

 

CLR obecnie nie współpracuje z modułami, ale działa z zestawami składowymi (assemblies). Zestaw składowy jest abstrakcyjnym konceptem, który jest trudny do zrozumienia. Jest to logiczne grupowanie jednego lub więcej plików zarządzanych modułów i/lub zasobów.

 

Zestaw składowy

 

=============================================================

 

Kompilacja i linkowanie

 

—————————————————————————————————-

 

Plik modułu Plik modułu Plik zasobu Plik modułu Plik zasobu Manifest

 

kod IL kod IL obraz jpg kod IL kod HTML metadane

 

 

Wszystkie pliki (moduły kodu IL, pliki zasobów i metadane) są łączone w jeden zestaw składowy przy użyciu odpowiednich narzędzi .NET: kompilatorów dla kompilacji do kodu zarządzanego z niezarządzanymi zasobami i Assembly linker dla połączenie tego w jedną całość. Powstaje też Manifest opisujący w tablicach to wszystko.

 

Zestaw składowy (assembly) jest najmniejszą jednostką do wielokrotnego użycia, bezpieczeństwa i wersjowania (versioning). Jest to cegiełka, którą możemy wszędzie umieścić w różnych aplikacjach. Zależnie od wyborów w stosunku do naszych kompilatorów i narzędzi, możemy stworzyć zestaw złożony z pojedynczego pliku lub zestaw złożony z wielu plików. Jest tu funkcja traktowania grupy plików jako pojedynczej jednostki. Stanowi to jedną nierozerwalną i autonomiczną całość.

 

 

Tutaj przekazujemy nazwy plików pewnych zarządzanych modułów i plików zasobów (lub danych), czyli fizyczne jednostki, do narzędzia kompilacji. To narzędzie daje pojedynczy plik PE (Portable Executable), który z kolei reprezentuje logiczne grupowanie plików, wykorzystując fizyczne jednostki. Ten plik PE zawiera m.in. blok danych zw. manifest, który jest po prostu innym zestawem tablic (tables) metadanych, które są nadrzędne w stosunku do tablic w użytych modułach. Te tablice opisują ten zestaw składowy (assembly)–pliki, które to tworzą, typy exportowane i publicznie implementowane przez te pliki w danym zestawie i pliki zasobów lub danych, które są z tym skojarzone.

 

Domyślnie kompilatory w rzeczywistości wykonują pracę zamiany emitowanych zarządzanych modułów w jeden zestaw składowy. Czyli kompilator C# emituje zarządzany moduł, który zawiera manifest. Każdy taki moduł zawiera taki manifest do opisu swoich danych, które zawiera. Kiedy mamy jeden moduł w zestawie, manifest modułu jest tym samym co manifest zestawu składowego. Ten manifest wskazuje, że dany zestaw składa się po prostu z jednego pliku (pliku zarządzanego modułu). Tak więc dla projektów, które mają tylko jeden zarządzany moduł i żadnych plików zasobów, ten zestaw będzie zarządzanym modułem i nie mamy żadnych dodatkowych kroków dla wykonania podczas budowania procesu. Jeśli chcemy zgrupować zestaw plików (pliki modułów i zasobów) w zestaw składowy (assembly), wtedy musimy wiedzieć o innych narzędziach (takich jak assembly linker, AL.exe) i ich opcje wiersza polecenia. Musi być linkowanie (połączenie) tych plików (plików modułów i plików zasobów) w zestawie składowym w jedną strukturę.

 

Zestaw składowy pozwala nam odłączyć od siebie logiczne i fizyczne koncepty ponownej używalności, stosowalności, wersjowania składnika i połączyć tak jak chcemy w nową strukturę. Bowiem sposób, w jaki dzielimy nasz kod i zasoby na różne pliki zależy od nas. Np. możemy włożyć rzadko używane typy lub zasoby do oddzielnych plików, które są ciągle częścią jednego zestawu składowego. Te oddzielne pliki mogłyby być ściągnięte z web, jeśli trzeba. Jeśli te pliki nie są nigdy potrzebne, one nigdy nie będą ściągnięte, oszczędzając powierzchnię dysku i redukując czas instalacji.

 

Zestaw składowy pozwala nam podzielić swoje dane tak, aby fizycznie rozmieścić te pliki (mogą być różnych miejscach) wg. naszego uznania, ale ciągle traktuje je jako pojedynczy logiczny zbiór, który jest nierozerwalny.

 

Te moduły w zestawie składowym też zawierają informacje, w tym numery wersji i o innych zestawach, do których się odnoszą. Te informacje czynią zestaw somoopisujący. Innymi słowy, CLR wie wszystko, co potrzebuje zestaw składowy, aby go wykonać. Żadne dodatkowe informacje nie są wymagane w rejestrze lub w Active Directory, więc stosowanie zestawów jest dużo łatwiejsze niż stosowanie niezarządzanych komponentów.

 

 

Łdowanie Common Language Runtime

 

 

Każdy zestaw składowy, którego budujemy, może albo być wykonywalną aplikacją (EXE) i/albo zestawem typów (DLL), zawierającą zestaw typów (komponentów) dla użycia przez wykonywalną aplikację.

 

Zestaw składowy

 

——————————————————————————————————–

 

DLL DLL EXE DLL DLL DLL

 

 

Oczywiście CLR jest odpowiedzialny za zarządzanie wykonywaniem kodu zawartego w tych zestawach składowych. Tzn., że .NET Framework musi być zainstalowany na maszynie hosta, aby to działało. Microsoft stworzył pakiet redystrybuowany (redistribution package), którego się dostarcza darmowo dla instalacji .NET Framework na maszynach naszych klientów.

 

Przyszłe wersje Windows będą zawierały .NET Framework, więc nie będzie potrzeby dostarczania tego z zestawami.

 

Możemy dowiedzieć, czy .NET Framework jest zainstalowany przez odszukanie pliku MSCorEE.dll w katalogu:

 

%windir%\system32

 

Istnienie tego pliku mówi nam, czy jest zainstalowany .NET Framework. Jednak kilka wersji .NET Framework może być zainstalowanych na pojedynczej maszynie jednocześnie. Jesli chcemy ustalić dokładnie, która wersja jest zainstalowana, sprawdzamy podklucz pod następującym kluczem rejestru:

 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy

 

Kiedy budujemy zestaw EXE, kompilator/linker emituje pewne specjalne informacje do headera pliku PE wynikowego zestawu składowego sekcji .text pliku. Kiedy plik EXE jest wywoływany, te specjalne informacje powodują, że CLR jest ładowany i inicjowany. Potem CLR lokuje metodę punktu wejścia dla aplikacji i pozwala danej aplikacji zacząć wykonanie.

 

 

kompilator/linker———>plik PE———>CLR———>Metoda Main——->wykonanie kodu

 

—————————————>—————->————————–>————————->

 

emisja specjalnych informacji ładowanie lokacja punktu wejścia wykonanie aplikacji

 

 

Podobnie, jeśli niezarządzana aplikacja wywołuje LoadLibrary do załadowania zarządzanego zestawu składowego, funkcja punktu wejściowego dla DLL wie jak załadować CLR, aby przetworzyć kod zawarty w danym zestawie.

 

Przeważnie nie musimy wiedzieć jak lub rozumieć jak w rzeczywistości CLR jest ładowany.

 

The figure on the next page summarizes how a managed EXE loads and initializes the CLR.

 

 

1/ MSCorEE bada header CLR, aby dostać token metadanych metody Main

 

2/ MSCorEE bada metadane Main, aby dostać lokację IL w EXE

 

3/ MSCorEE kompiluje IL Main na natywny CPU

 

4/ MSCorEE wskakuje do natywnego CPU Main, używając podstawowego wątku (primary thread) i aplikacja rusza

 

Czynności MSCorEE (.NET):

 

 

badanie headera CLR

 

|

 

otrzymanie tokenu metadanych

 

|

 

badanie metadanych Main

 

|

 

otrzymanie lokacji IL w EXE

 

|

 

kompilacja Main na natywny CPU

 

|

 

przejście do natywnego CPU

 

 

5/ Kiedy kompilator/linker tworzy wykonywalny zestaw składowy, a następująca 6-byte x86 funkcja stub jest emitowana do sekcji .text pliku PE:

 

JMP _CorExeMain

 

Funkcja _CorExeMain jest importowana z biblioteki linkowanej dynamicznie Microsoftu zw. MSCorEE.dll i dlatego MSCorEE.dll jest odnoszony (ma odniesienie) w sekcji import (.idata) pliku zestawu. (MSCorEE.dll to jest Component Object Runtime Execution Engine.). Kiedy wywoływany jest zarządzany plik EXE, Windows traktuje to po prostu jak każdy normalny (niezarządzany) plik EXE–ładowacz Windows ładuje ten plik i sprawdza sekcję .idata, aby zobaczyć, czy MSCorEE.dll powinien być załadowany do przestrzeni adresowej procesu. Potem ładowacz otrzymuje adres funkcji _CorExeMain w MSCorEE.dll i ustala instrukcję JMP (JuMP, czyli jump wskoczenie) funkcji stub w pliku zarządzanym EXE.

 

Podstawowy wątek dla tego procesu zaczyna się wykonywaniem tej funkcji stub x86, która natychmiast wskakuje do _CorExeMain w MSCorEE.dll. _CorExeMain inicjuje CLR i potem patrzy na header CLR dla wykonywalnego zestawu składowego dla ustalenia, jaka metoda punktu wejściowego zarządzanego powinna być wykonana. Kod IL dla tej metody jest potem kompilowany do natywnych instrukcji CPU, po których CLR wskakuje do natywnego kodu (używając podstawowego wątku tego procesu). W tym momencie kod zarządzanej aplikacji działa.

 

Ta sytuacja jest podobna dla zarządzanej DLL. Kiedy budujemy zarządzany DLL, kompilator/linker emituje podobną funkcję 6-byte x86 dla zestawu DLL w sekcji .text pliku PE:

 

JMP _CorDllMain

 

Funkcja _CorDllMain jest też importowana z MSCorEE.dll, powodując, że sekcja .idata dla DLL dla odniesienia do MSCorEE.dll. Kiedy Windows ładuje DLL, to automatycznie ładuje MSCorEE.dll (jeśli to nie jest już załadowane), otrzymuje adres funkcji _CorDllMain i ustala do 6-byte x86 JMP stub zarządzanym DLL.

 

Ten wątek jest zw. LoadLibrary dla załadowania zarządzanej DLL, wtedy wskakuje do x86 stub w zarządzanym zestawie DLL, który natychmiast wskakuje do _CorDllMain w MSCorEE.dll. _CorDllMain inicjuje CLR (jeśli już nie jest zainicjowany dla tego procesu) i potem wraca, aby aplikacja mogła kontynuować wykonanie jak zwykle.

 

Te funkcje 6-byte x86 stub są wymagane dla uruchomienia zarządzanych zestawów składowych na Windows 98, Windows 98SE, Windows ME, Windows NT 4, and Windows 2000, bo wszystkie te SOs wyprodukowano przed pojawieniem się CLR.

 

Funkcja 6-byte stub jest określona dla maszyn x86. Ta funkcja nie pracuje właściwie, jeśli ten CLR jest przenoszony do działania na innych architekturach CPU. Ponieważ Windows XP i Windows .NET Servers wspierają architektury CPU zarówno x86 i IA64, ładowacz dla Windows XP i Windows .NET Servers został zmodyfikowany, aby wyglądać specyficznie dla zestawów zarządzanych.

 

Na Windows XP i Windows .NET Servers, kiedy zestaw zarządzany jest wywoływany (typowo przez CreateProcess lub LoadLibrary), ładowacz SO wykrywa, że ten plik zawiera kod zarządzany. To jest robione przez sprawdzenie wpisu katalogu 14 w headerze pliku PE (patrzymy na IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR w WinNT.h). Jeśli ten wpis katalogu istnieje i nie jest 0, wtedy ten ładowacz ignoruje sekcję import (.idata) tego pliku całkowicie i wie jak automatycznie załadować MSCorEE.dll do przestrzeni adresowej tego procesu. Raz załadowany, ten ładowacz SO robi tak, że ten wątek procesu wskakuje bezpośrednio do właściwej funkcji w MSCorEE.dll. Funkcje stub 6-byte x86 są ignorowane na maszynach z działającym Windows XP i Windows .NET Servers.

 

Pliki zarządzane PE zawsze używają formatu pliku 32-bit PE, one nie używają nowszego formatu pliku 64-bit PE. Na SOs Windows 64-bit, ładowacz SO wykrywa zarządzany plik 32-bit PE i automatycznie wie jak stworzyć przestrzeń adresową 64-bit.

 

 

Wykonanie kodu w naszym zestawie składowym

 

 

Zarządzane moduły zawierają zarówno kod metadanych i intermediate language (IL). IL jest językiem maszynowym niezależnym od CPU stworzonym przez Microsoft po konsultacji z kilkoma specjalistami od programowania. IL jest na o wiele wyższym poziomie niż większość języków maszynowych CPU. IL rozumie typy obiektów i ma instrukcje, które tworzą i inicjują obiekty, wywołują wirtualne metody na obiektach i manipulują bezpośrednio elementami tablicy (array). To nawet ma instrukcje, które rzucają i łapią wyjątki dla obsługi błędów. IL to jest język maszynowy OOP, a więc wyższego poziomu niż tradycyjne asemblery.

 

Zazwyczaj programiści preferują programowanie w językach wysokiego poziomu takim jak C# lub Visual Basic.NET. Te kompilatory dla tych wszystkich języków wysokiego poziomu wytwarzają IL. Jednak jak inne języki maszynowe, IL może być napisany w asemblerze i Microsoft dostarcza asembler IL, czyli ILAsm.exe. Microsoft też dostarcza dezasemblera IL, czyli ILDasm.exe.

 

Możemy budować zarządzany moduł i ktoś inny może użyć narzędzia jak dezasembler IL dla odwrócenia tego, co nasz kod aplikacji robi.

 

Kod IL jest wyższego poziomu niż inne języki asemblerowe i generalnie odwrócenie kodu IL jest proste. Jednak kiedy implementujemy usługę web lub formę aplikacji web, nasz zarządzany moduł jest na naszym serwerze, niedostępny dla kogokolwiek z zewnątrz firmy. Nie można używać jakiegokolwiek narzędzia, aby zobaczyć kod IL, więc to jest bezpieczne.

 

Jeśli mam do czynienia z innymi zarządzanymi modułami, które dystrybuujemy, wtedy możemy użyć narzędzia Microsoft obfuscator (OB.exe), które możemy mieć z:

 

http://www.GotDotNet.com

 

To narzędzie miesza (scramble) nazwy wszystkich prywatnych symboli w naszym module zarządzanym metadanych. To będzie trudne dla kogoś dla odmiesznia tych nazw i zrozumienia celu każdej metody. Zaciemniacz (obfuscator) Microsofta miesza tylko nazwy metadanych i nie miesza kodu IL, bo CLR musi być w stanie przetwarzać niezmieszany IL.

 

Jeśli zaciemniacz to za mało, są bardziej czułe algorytmy w niezarządzanym module, który będzie zawierać natywne instrukcje CPU zamiast IL i metadanych. Potem możemy użyć cech interoperacyjności CLR dla komunikowania się miedzy porcjami zarządzaną i niezarządzaną naszej aplikacji. Po warunkiem, że nie musimy martwć się odwrócenie instrukcji CPU w naszym niezarządzanym kodzie.

 

Jakikolwiek język wysokiego poziomu będzie przeważnie ujawniał tylko podzestaw narzędzi oferowanych przez CLR, bo ma wieksze ograniczenia (C# ma inne, a VB inne itd.). Język asemblerowy IL jednak daje programiście dostęp do wszystkich narzędzi CLR, bo nie ma żadnych ograniczeń. Tak więc nasz wybrany język chowa pewne cechy CLR, z których chcemy skorzystać, zatem możemy napisać tę porcję naszego kodu w asemblerze IL lub w innym języku programowania, który ujawnia cechy CLR, których szukamy. Nie widzimy więc wszystkich cech .NET używając C# czy VB.

 

 

.NET

 

————————————————————————————————-

 

C# VB

 

————————————————– ——————————————–

 

cecha1 cecha2 cecha3 cecha4 cecha5 cecha6

 

————————————————————————————————–

 

IL

 

 

Aby poznać te narzędzia oferowane przez agenta czasu ruchomienia trzeba czytać dokumentację specyficzną dla samego CLR. Tutaj próbujemy koncentrować się na cechach CLR i jak one są ujawnione lub nie przez język C#. CLR oferuje tylko te cechy, które ujawnia jezyk wybrany przez programistę. Tak długo jak nasz jezyk pozwala nam osiągnąć to, co próbujemy zrobić, to zamazana perspektywa nie jest złą rzeczą. Łatwość przełączania między językami programowania z bogatą integracją między językami jest niesamowitą cechą CLR. Ta cecha jest często pomijana przez programistów.

 

Języki jak C# i Visual Basic.NET są doskonałymi dla robienia operacji I/O. APL jest dobrym językiem dla celów inżynierskich i obliczeń finansowych. Przez CLR możemy napisać porcje I/O naszej aplikacji przy użyciu C# i potem napisać obliczenia inżynierskie z APL. CLR oferuje poziom integracji między tymi językami jest niespotykany i naprawdę czyni mieszanie języków wartym rozważenia dla wielu projektów.

 

IL nie jest związany z żadną konkretną platformą CPU. Tzn., że zarządzany moduł zawierający IL może działać na jakiejkolwiek platformie CPU tak długo jak SO działa na tej platformie i CPU hostuje wersję CLR. Chociaż początkowe wydanie CLR będzie uruchamiane na platformach 32-bit Windows, rozwijanie aplikacji przy użyciu zarządzanego IL ustawia programistę w pozycji bardziej niezależnej niż architektura CPU.

 

 

W 2000 Microsoft (z Intel i Hewlett-Packard) zaproponował wielki podzestaw .NET Frameworks do ECMA (the European Computer Manufacturer’s Association) dla celu standaryzacji. ECMA zaakceptowało tę propozycję i stworzyło techniczny komitet (TC39) dla procesu standaryzacji. Jego zadania:

 

· Technical Group 1: Develop a dynamic scripting language standard (ECMAScript). Microsoft’s implementation of ECMAScript is JScript.

 

· Technical Group 2: Develop a standardized version of the C# programming language.

 

· Technical Group 3: Develop a common language infrastructure (CLI) based on a subset of the functionality offered by the .NET Framework’s CLR and class library.

 

CLI określa zwłaszcza format pliku, common type system (CTS), extensible metadata system, intermediate language (IL) i dostęp do podległej platformy (P/Invoke, czyli Platform Invoke). Dodatkowo CLI też definiuje rozkładalną (dla małych urządzeń hardware) podstawową klasę biblioteki przeznaczoną do użycia przez wiele jezyków.

 

Common Language Infrastructure (CLI)- połączenie Common Language Runtime, Base Framework i innych bibliotek. CLI jest głównym komponentem dla standardu ECMA.

 

Common Language Runtime (CLR)- typ, metadane i systemy wykonania dostarczane przez .NET Framework, które dostarczają zarządzanego kodu u danych z usługami takimi jak integracja miedzyjęzykowa, bezpieczeństwo dostępu do kodu, zarządzanie czasem życia obiektu oraz wsparcie debugowania i profilowania. Przez obranie za cel CLR kompilatory i inne narzędzia mogą zaoferować te usługi programistom.

 

Common Language Specification (CLS)- podzestaw cech .NET Framework, które są wsparte przez szeroki zestaw zgodnych języków i narzędzi. Zgodność z CLS jest tylko stosowalna do publicznie ujawnionych aspektów typów. Języki i narzędzia zgodne z CLS są gwarantowane, że współdziałają z innym językami i narzędziami zgodnymi z CLS. Np. typ Int32 jest zgodny z CLS, więc oczekuje się, że inne języki i narzędzia zgodne z CLS będą wiedziały jak właściwie używać tego typu.

 

 

Kiedy standaryzacja jest zakończona, te standardy będą w ISO/IEC JTC 1 (Information Technology). W tym czasie komitet bada inne kierunki dla CLI, C#, i ECMAScript. Więcej:

 

http://www.ECMA.ch

 

http://MSDN.Microsoft.com/Net/ECMA

 

Ze standaryzacją CLI, C#, i ECMAScript, Microsoft nie będzie jedynym posiadaczem tych technologii. Microsoft będzie po prostu jedną firmą z wielu, która będzie implementować te technologie. Każda z firm wypuszcza swoje produkty w tym standardzie, konkurując z Microsoft. Instrukcje IL nie mogą być wykonywane bezpośrednio przez dzisiejsze CPUs. Aby wykonać metodę, jej kod IL musi po pierwsze być konwertowany do natywnych instrukcji CPU. Aby zrobić konwersję, CLR daje kompilator JIT (just-in-time).

 

The figure below shows what happens the first time a method is called.

 

 

Działanie JITCompiler w MSCorEE.dll:

 

1/ W zestawie składowym, który implementuje dany typ czy klasę (np. Console) szukamy danej metody (np. WriteLine) wywoływanej w metadanych.

 

2/ Z tych metadanych otrzymujemy IL dla tej metody.

 

3/ Alokujemy blok pamięci.

 

4/ Kompilujemy ten IL na natywne instrukcje CPU.

 

5/ Modyfikujemy wpis metody w tablicy Type, aby teraz to wskazywało na blok pamięci wcześniej alokowany.

 

6/ Wskakujemy do natywnego kodu zawartego w tym bloku pamięci.

 

 

Zanim metoda Main wykonuje, CLR wykrywa wszystkie typy (klasy), dla których są odniesienia przez kod w Main. To powoduje, że CLR alokuje wewnętrzną strukturę danych, która jest używana do zarządzania dostępem do każdego odniesionego typu. Powyżej na obrazku metoda Main odnosi się do pojedynczego typu, Console, powodując, ze CLR alokuje pojedynczą strukturę wewnętrzną.

 

 

Wewnętrzna struktura danych alokowana przez CLR

 

Zestaw składowy

 

———————————————————————————————–

 

Main

 

————————————————————————————————

 

| | |

 

Console Typ2 Typ3

 

WriteLine metoda2… metoda1 metoda2… metoda1 metoda2…

 

| metadane | metadane | metadane

 

wpis1 wpis2 wpis1 wpis2 wpis1 wpis2

 

adres1 adres2 adres1 adres2 adres1 adres2

 

————————————————————————————————

 

Funkcja JITCompiler

 

 

Pierwsze wywołanie implementacj metody:

 

 

Main

 

| wywołanie

 

WriteLine

 

| wywołanie

 

JITCompiler

 

| weryfikacja, kompilowanie

 

kod IL danego zestawu składowego

 

| zapisywanie w dynamicznie alokowanym bloku pamięci

 

natywne instrukcje CPU

 

| zastąpienie adresu tej metody adresem bloku pamięci instrukcjami natywnego CPU

 

natywne instrukcje CPU są w bloku pamięci (implementacja metody WriteLine)

 

| powrót do funkcji głównej

 

Main

 

 

Kolejne wywołanie tej metody:

 

 

Main

 

| wywołanie

 

WriteLine

 

| wywołanie

 

natywne instrukcje CPU są w bloku pamięci (implementacja metody WriteLine)

 

| powrót do funkcji głównej

 

Main

 

 

Ta wewnętrzna struktura danych zawiera wpis dla każdej metody określonej przez ten typ. Każdy wpis ma adres, gdzie ta implementacja metody może być znaleziona. Kiedy inicjujemy tę strukturę, CLR ustawia każdy wpis dla funkcji zawartej w samym CLR. Nazywamy tę funkcję JITCompiler. Kiedy Main po raz pierwszy wywołuje WriteLine, funkcja JITCompiler jest wywoływana. Funkcja JITCompiler jest odpowiedzialna za kompilowanie kodu IL metody na natywne instrukcje CPU. Skoro IL jest kompilowany “just in time” (na czas), ten komponent CLR jest często odnoszony jako JITter lub JIT Compiler.

 

Kiedy wywołany, funkcja JITCompiler wie, jaka metoda jest wywoływana i jaki typ definiuje tę metodę. Funkcja JITCompiler potem szuka określających metadanych zestawu składowego dla IL wywołanej metody.

 

JITCompiler weryfikuje i kompiluje kod IL na instrukcje natywne CPU, które są potem zapisywane w dynamicznie alokowanym bloku pamięci. JITCompiler wraca do wewnętrznej struktury danych i zastępuje adres wywołanej metody adresem bloku pamięci zawierającym instrukcje natywnego CPU.

 

Ostatecznie JITCompiler wskakuje do kodu w bloku pamięci. Ten kod jest implementacją metody WriteLine (ta wersja biorąca parametr String). Kiedy ten kod zwraca (wraca do funkcji Main), wykonanie jest kontynuowane w Main jak zwykle.

 

Np. Main wywołuje po raz drugi WriteLine. Tym razem ponieważ ten kod dla WriteLine jest już zweryfikowany i skompilowany, to wywołanie idzie bezpośrednio do natywnego kodu w bloku pamięci, przeskakując całkowicie funkcję JITCompiler. Po wykonaniu metody WriteLine, to wraca do Main.

 

The figure below shows what the situation looks like when WriteLine is called the second time:

 

 

Ten długi proces funkcjonuje tylko po raz pierwszy, kiedy dana metoda jest wywoływana. Wszystkie kolejne wywoływania do tej metody są wykonywane z pełną szybkością kodu natywnego: weryfikacja i kompilacja do natywnego kodu nie jest znowu wykonywana.

 

Kompilator JIT przechowuje instrukcje natywne CPU w pamięci dynamicznej, czyli skompilowany kod jest potem wyrzucany z pamięci, kiedy aplikacja kończy działanie. Jeśli więc uruchamiamy tę aplikację w przyszłości lub jeśli uruchamiamy dwie instancje tej aplikacji równocześnie ( na dwa procesy SO), wtedy kompilator JIT będzie musiał skompilować IL znowu do natywnych instrukcji.

 

Dla większości aplikacji to długie wykonanie przez kompilację JIT nie jest czasowo znaczące. Większość aplikacji zmierza do wywołania tych samych metod tylko raz, kiedy aplikacja jest wykonywana, aby nie powtarzać całego procesu od nowa. Ten proces normalnie poświęca więcej czasu w tej metodzie niż poświęca on przy wywołaniu tej metody.

 

Kompilator JIT optymizuje kod natywny tak jak strona końcowa niezarządzanego kompilatora C++. Znowu ta optymizacja może trwać, ale ten kod będzie wykonany z dużo lepszą wydajnością niż kod niezoptymizowany.

 

Programiści wywodzący się z niezarządzanego C lub C++ prawdopodobnie myślą, że to wykonanie rozwidla to wszystko. W końcu niezarządzany kod jest kompilowany dla określonej platformy CPU i kiedy wywołany, ten kod może po prostu natychmiast wykonywać. W tym środowisku zarządzanym kompilowanie kodu jest osiągane w dwóch fazach. Najpierw kompilator przekazuje nasz kod źródłowy, robiąc tak wiele pracy, jak to możliwe w wytwarzaniu IL. Ale potem aby w rzeczywistości wykonywać ten kod, sam IL musi być skompilowany do natywnych instrukcji CPU w czasie uruchomienia, wymagając, aby było więcej pamięci alokowanej i wymagając dodatkowego czasu CPU dla zrobienia tej pracy. Drugi etap kompilacji, który pojawia się w czasie uruchomienia nie szkodzi wykonaniu i alokuje pamięć dynamiczną. Jednak Microsoft zrobił wiele pracy przy wykonaniu, aby trzymać te dodatkowe koszty główne w minimum.

 

Myślimy, że zarządzane aplikacje mogą w rzeczywistości przewyższać wykonaniem niezarządzane aplikacje. Np. kiedy kompilator JIT kompiluje kod IL do kodu natywnego w czasie uruchomienia, ten kompilator wie więcej o środowisku wykonania niż wiedziałby niezarządzany kompilator. Kilka sposobów na to, aby zarządzany kod mogł przewyższać niezarządzany kod w wykonaniu:

 

– kompilator JIT może wykryć, że ta aplikacja działa na Pentium 4 i dlatego kompilator ten wytwarza kod natywny, który korzysta z jakichkolwiek specjalnych instrukcji oferowanych przez Pentium 4. Zazwyczaj niezarządzane aplikacje są kompilowane dla najniższego wspólnego denominatora CPU i używają specjalnych instrukcji, które dałyby tej aplikacji polepszenie wykonania na nowszych CPUs.

 

– Kompilator JIT mógłby wykryć, że pewien test jest zawsze fałszywy na bieżącej maszynie hosta. Np. metoda z kodem jak ten:

 

if (numberOfCPUs > 1) {

 

 

}

 

mogłaby spowodować, że kompilator JIT nie generuje jakichkolwiek instrukcji CPU dla powyższego kodu, jeśli maszyna hosta ma tylko 1 CPU. W tym wypadku kod natywny jest dostosowany do maszyny hosta–ten kod jest mniejszy i wykonywany szybciej.

 

– CLR mógłby profilować wykonanie kodu i ponowną kompilację IL do kodu natywnego, gdy kompilacja działa. Ten ponownie skompilowany kod mógłby być zreorgaznizowany dla zredukowania niepoprawnego przewidywanego rozgałęzienia zależnie od obserwowanych wzorców wykonania.

 

Dla wielu powodów powinniśmy oczekiwać przyszłych osiagnięć z zarządzanym kodem do wykonania lepszego niż dzisiejszy niezarządzany kod. Dzisiaj wykonanie jest całkiem dobre dla większości aplikacji i to obiecuje poprawić z czasem.

 

Jeśli kompilator CLR nie da naszej aplikacji odpowiedniego wykonania, wtedy możemy użyć narzędzia NGen.exe, które jest z .NET Framework SDK. Ono kompiluje cały kod IL dla zestawu składowego na kod natywny i zapisuje powstały kod natywny w pliku na dysku. W czasie uruchomienia kiedy zestaw składowy jest załadowany, CLR automatycznie sprawdza, czy przedkompilowana wersja tego zestawu składowego istnieje i jeśli tak, CLR ładuje ten prekompilowany kod, aby nie była wymagana żadna dodatkowa kompilacja podczas uruchomienia.

 

 

IL i Weryfikacja

 

 

IL jest oparte na stosie, tzn., że wszystkie jego instrukcje wpychają operandy (operands) na stos wykonania i wypychają wyniki z tego stosu. Zgodnie z tym IL nie oferuje żadnych instrukcji dla manipulowania rejestrami. Programiści kompilatora mogą łatwo wytwarzać kod IL. Oni nie muszą myśleć o zarządzaniu rejestrami i jest mniej instrukcji IL (skoro żadna nie istnieje dla manipulowania rejestrami). I jest jeszcze jedno uproszczenie–instrukcje IL są beztypowe (typeless). Np. IL oferuje i dodaje instrukcje, które dodają ostatnie dwa operandy wepchnięte na stos. IL nie oferuje instrukcji add 32-bit i instrukcji add 64-bit. Kiedy instrukcja add wykonuje, to ustala typy operandów na stosie i wykonuje odpowiednią operację.

 

Największą korzyścią z IL nie jest abstrahowanie z podległego CPU, ale solidność aplikacji. Podczas kompilowania IL na instrukcje natywne CPU, CLR wykonuje proces zw. weryfikacją. Weryfikacja sprawdza wysoki poziom kodu IL i zapewnia, że wszystko to jest bezpieczne. Np. weryfikacja sprawdza, czy żadna pamięć nie jest odczytywana bez poprzedniego zapisu do niej, że każda metoda jest wywoływana z poprawną liczbą parametrów, że każdy parametr jest poprawnego typu, że każda wartość zwracana metody jest użyta właściwie, że każda metoda ma instrukcję return itd.

 

Te metadane dla każdego zarządzanego modułu zawierają wszystkie informacje o metodzie i typie używanym przez proces weryfikacji. Jeśli kod jest ustalany jako niebezpieczny, wtedy rzucany jest wyjątek System.Security.VerifierException, uniemożliwiając tej metodzie wykonanie.

 

Domyślnie kompilatory C# i Visual Basic.NET dają bezpieczny kod. Bezpieczny kod jest po prostu weryfikowany jako bezpieczny. Jednak używając słowa kluczowego w C# unsafe lub używając innych języków (takich jak C++ z Managed Extensions lub językiem IL Assembly), może wytworzyć kod, który nie może być bezpiecznie zweryfikowany. Czyli taki kod mógłby być w rzeczywistości bezpieczny, ale po prostu weryfikacja nie jest w stanie tego udowodnić.

 

Aby zapewnić, że wszystkie metody w naszym zarządzanym module zawierają zweryfikowalny jako bezpieczny kod IL, możemy użyć narzędzia PEVerify.exe, które jest z .NET Framework SDK. Kiedy programiści Microsoft testują ich kompilatory C# i Visual Basic.NET, oni uruchamiają wynikowy moduł przez PEVerify dla zapewnienia, że ten kompilator zawsze tworzy bezpieczny kod zweryfikowalny. Jeśli PEVerify wykrywa kod unsafe, wtedy Microsoft naprawia kompilator.

 

Możemy użyć PEVerify na naszych własnych modułach zanim je spakujemy i wprowadzimy. Jeśli PEVerify wykrywa problem, wtedy jest błąd w tym kompilatorze i powinniśmy zaraportować to dla Microsoft (lub jakikolwiek kompilator jakiejkolwiek firmy). Jeśli PEVerify nie wykrywa jakiegokolwiek niezweryfikowalnego kodu, wtedy wiemy, że nasz kod będzie działał bez wyrzucania VerifierException na maszynie końcowego użytkownika.

 

Można wyłączyć weryfikację z pozycji administratora używając “.NET Management” Microsoft Management Console Snap-In). Z weryfikacją wyłączoną (off), kompilator JIT skompiluje niezweryfikowany IL do natywnych instrukcji CPU.

 

W Windows każdy proces ma swój własną wirtualną przestrzeń adresową. Oddzielne przestrzenie adresowe są potrzebne, bo Windows nie może ufać kodowi aplikacji. To jest całkowicie możliwe (i na nieszczęście zbyt często), że aplikacja będzie odczytywać z lub zapisywać do nieważnego adresu pamięci. Umieszczanie każdego procesu Windows w oddzielnej przestrzeni adresowej wzmacnia solidność: jeden proces nie może źle wpływać na inny.

 

Jednak przez weryfikację zarządzanego kodu, wiemy, że ten kod będzie zachowywał się jak trzeba. Tzn., że możemy uruchomić wiele zarządzanych aplikacji w pojedynczej wirtualnej przestrzeni adresowej Windows.

 

Ponieważ procesy Windows wymagają wiele zasobów SO, uruchomienie wielu procesów może poszkodzić wykonaniu i ograniczyć dostępne zasoby SO. Uruchamianie wielu aplikacji w pojedynczym procesie SO redukuje liczbę tych procesów, co może poprawić wykonanie, wymaga mniej zasobów i oferuje równą solidność. To jest inna korzyść z zarządzanego kodu w porównaniu z niezarządzanym kodem.

 

CLR w rzeczywistości oferuje zdolność do wykonania wielu zarządzanych aplikacji w pojedynczym procesie SO. Każda zarządzana aplikacja jest zw. AppDomain. Domyślnie każdy zarządzany EXE będzie działać w swojej własnej przestrzeni adresowej, która ma tylko tą jedną AppDomain. Jednak proces hostujący (goszczący) CLR (taki jak IIS lub przyszłe wersje SQL Server) mogą zdecydować uruchomić AppDomains w pojedynczym procesie SO.

 

 

.NET Framework Class Library

 

 

W .NET Framework jest pakiet (assemblies) zestawów składowych Framework Class Library (FCL), który zawiera kilka tysięcy definicji typów (klas), gdzie każdy typ ujawnia pewną funkcjonalność.

 

Ogółem CLR i FCL pozwalają programistom zbudować następujące rodzaje aplikacji:

 

Web Services– komponenty, które mogą być łatwo dostępne przez Internet. Są główną ideą inicjatywy .NET.

 

Web Forms– aplikacje oparte na HTML (web sites). Typowo aplikacje w web forms robią zapytania do bazy danych i wywołania usługi web, łączenie i filtrowanie zwracanych informacji i potem prezentowanie tego w przeglądarce używając bogatego UI HTML.Web forms dostarczają środowiska rozwojowe Visual Basic 6- i InterDev- dla aplikacji web napisanych w jakimkolwiek języku CLR.

 

Windows Forms– bogate aplikacje GUI Windows. Zamiast używania web form dla tworzenia UI naszych aplikacji możemy użyć silniejszej, lepszej w wykonaniu funkcjonalności oferowanej przez pulpit Windows. Aplikacje Windows form mogą korzystać z kontroli, menus, zdarzeń myszy i klawiatury i mogą przemawiać bezpośrednio do podległego SO. Jak aplikacje web form, aplikacje Windows form czynią zapytania do bazy danych i wywołują usługi web. Windows Forms dostarczają środowiska programistycznego podobnego do Visual Basic 6 dla aplikacji GUI napisanych w języku CLR.

 

Windows Console Applications– dla aplikacji z prostymi prośbami UI, aplikacje konsoli dają szybkie i łatwe rozwiązanie. Kompilatory, narzędzia i programy użytkowe są typowo implementowane jako aplikacje konsoli.

 

Windows Services– jest możliwe budowanie aplikacji usługi kontrolowanej przez Windows Service Control Manager (SCM) przy użyciu .NET Framework.

 

 

· Component Library– .NET Framework pozwala nam budować samodzielne komponenty (typy), które mogą być łatwo wcielane do jakichkolwiek typów aplikacji wymienionych wyżej.

 

Skoro FCL zawiera tysiące typów, komplet powiązanych typów jest prezentowany dla programisty z pojedynczą przestrzenią nazwy (namespace). Np. przestrzeń nazwy System zawiera podstawowy typ Object, z którego wszystkie inne typy się wywodzą. Dodatkowo przestrzeń nazw System zawiera typy dla:

 

– characters

 

– strings

 

– exception handling

 

– console I/O

 

– pakiet typów narzędzi dla bezpiecznej konwersji między typami danych, formatami typu danych, generowaniem liczb losowych i wykonywaniem funkcji matematycznych

 

Wszystkie aplikacje używają typów z przestrzeni nazwy System.

 

Aby mieć dostęp do cechy jakiejkolwiek platformy, musimy wiedzieć, jaka przestrzeń nazwy zawiera typy, które ujawniają dane narzędzie, którego aktualnie poszukujemy. Gdzie jest metoda, którą chcemy się posłużyć? W jakim typie i w jakiej przestrzeni nazwy? Jeśli chcemy dostosować zachowanie jakiegokolwiek typu, możemy po prostu uzyskać swój własny typ z żądanego typu istniejącego FCL. .NET Framework polega na naturze platformy OOP dla prezentowania zwięzłego modelu programowania dla programistów software. To też pozwala programistom tworzyć swoje własne przestrzenie nazw zawierające swoje własne typy, które stapiają się idealnie z modelem programowania. W porównaniu do modeli programowania Win32 to bardzo upraszcza rozwój software.

 

Większość przestrzeni nazw w FCL prezentuje typy, które możemy używać dla jakiegokolwiek rodzaju aplikacji. Ta tablica listuje pewne z bardziej ogólnych przestrzeni nazw, z krótkim opisem tego, co te typy w tej przestrzeni nazw znaczą:

 

System

 

Wszystkie podstawowe typy używane przez każdą aplikację.

 

System.Collections

 

Zarządzanie kolekcją obiektów. Zawiera popularne kolekcje typów takich jak stosy, kolejki, tablice hashowane itp.

 

System.Diagnostics

 

Instrumentowanie i debugowanie naszej aplikacji.

 

System.Drawing

 

Obsługa grafiki 2D. Typowo używany dla aplikacji i dla tworzenia obrazów, które mają pojawić się w web form.

 

System.EnterpriseServices

 

Zarządzanie transakcjami, kolekcjami komponentów, zbieraniem obiektów w pule, aktywacją just-in-time, bezpieczeństwem i innymi cechami dla użycia zarządzanego kodu bardziej efektywnie na serwerze.

 

System.Globalization

 

National Language Support (NLS) taki jak porównanie ciągu, formatowanie i kalendarze.

 

System.IO

 

Strumienie I/O, katalogi i pliki typu walking.

 

System.Management

 

Zarządzanie innymi komputerami w korporacji przez. Windows Management Instrumentation (WMI)- A management infrastructure in Windows that supports monitoring and controlling system resources through a common set of interfaces and provides a logically organized, consistent model of Windows operation, configuration, and status.

 

System.Net

 

Komunikacje sieciowe.

 

System.Reflection

 

Badanie metadanych i późne wiązanie do typów i ich członków.

 

System.Resources

 

Manipulowanie zewnętrznymi zasobami danych.

 

System.Runtime.InteropServices

 

Umożliwienie zarządzanemu kodowi dostęp do niezarządzanych narzędzi pltaformy SO takich jak komponenty COM i funkcje w Win32 DLLs.

 

System.Runtime.Remoting

 

Zdalny dostęp do typów.

 

System.Runtime.Serialization

 

Umożliwienie instancjom obiektów bycie trwałymi i regenerowanymi ze strumienia.

 

System.Security

 

Chronienie danych i zasobów.

 

System.Text

 

Praca z tekstem w różnych kodowaniach jak ASCII lub Unicode.

 

System.Threading

 

Wykonywanie asynchronicznych operacji i synchronizowanie dostępu do zasobów.

 

System.Xml

 

przetwarzanie schematówi i danych XML.

 

Ta książka jest o CLR i o generalnych typach, które są w interakcji z CLR (co zawiera większość przestrzeni nazw wymienionych wyżej). Tzn., ta zawartość książki odnosi się do .NET Framework bez względu na typ aplikacji, który budujemy.

 

Jednak trzeba pamiętać, że dodatkowo dostarczając bardziej generalnych przestrzeni nazw, FCL oferuje przestrzenie nazw, których typy są używane do budowania określonych typów aplikacji. Tablica poniżej listuje pewne specyficzne dla aplikacji przestrzenie nazw:

 

System.Web.Services

 

Budowanei web services.

 

System.Web.UI

 

Budowanie web forms.

 

System.Windows.Forms

 

Budowanie aplikacji Windows GUI.

 

System.ServiceProcess

 

Budowanie Windows service kontrolowanej przez Service Control Manager.

 

Te aplikacje to: Windows services, Web forms czy Windows forms.

 

Ta książka oferuje informacje, które pomogą nam uczyć się z dołu na górę, czyli od podstaw platformy .NET do aplikacji. Po przeczytaniu tej książki i książek specyficznych dla aplikacji, powinniśmy być w stanie łatwo i wydajnie zbudować każdy rodzaj aplikacji .NET Framework.

 

 

Common Type System

 

 

CLR to wszystko o typach. Typy ujawniają funkcjonalność dla naszych aplikacji i komponentów aplikacji. Typy są mechanizmem, przez który kod napisany w jednym języku programowania może przemawiać do kodu napisanego w innym języku programowania. Ponieważ typy są w roocie CLR, Microsoft stworzył formalną specyfikację–common type system (CTS), która opisuje jak typy są definiowane i jak się zachowują.

 

 

CLR– wszystko o typach

 

CTS– definiowanie i zachowanie typów

 

 

Specyfikacja CTS stwierdza, że typ może zawierać zero lub więcej członków. Krótkie wprowadzenie do nich:

 

Field. Zmienna danych, która jest częścią stanu obiektu. Pola są identyfikowane przez ich nazwę i typ.

 

Zmienna

 

——————————————————————————————————–

 

Nazwa Typ

 

 

Method. Funkcja, która wykonuje operacje na obiekcie, często zmieniając stan obiektu. Metody mają nazwę, podpis i modyfikatory. Podpis (signature) określa konwencję wywołania, liczbę parametrów (i ich kolejność), typy tych parametrów i typ wartości zwróconej przez tę metodę.

 

Funkcja

 

——————————————————————————————————–

 

Nazwa Podpis Modyfikatory

 

Property. Dla wywołującego ten członek wygląda jak pole (field), ale dla implementatora typu (type implementer), ten członek wygląda jak metoda (lub dwie). Właściwości pozwalają implementatorowi legalizować parametry danych wejściowych i stan obiektu przed dostepem do wartości i obliczać wartość tylko, kiedy trzeba. One też pozwalają użytkownikowi danego typu mieć uproszczoną składnię. Ostatecznie właściwości też pozwalają nam stworzyć „pola” tylko do odczytu (read-only) lub tylko do zapisu (write-only).

 

Właściwość

 

——————————————————————————————————–

 

Nazwa Typ Nazwa Podpis Modyfikatory

 

 

Event. Mechanizm powiadomień miedzy obiektem i innymi interesującymi obiektami. Np. guzik powinien oferować zdarzenie, które powiadamia inne obiekty, kiedy dany guzik jest kliknięty.

 

CTS też określa zasady dla widoczności typu i dla dostępu do członków typu. Np. oznaczając typ jako public eksportuje typ, czyniąc go widocznym i dostępnym dla jakiegokolwiek zestawu.

 

Oznaczajac typ jako assembly (zw. internal w C#) czyni ten typ widocznym i dostępnym dla kodu tylko w tym samym zestawie składowym (assembly).

 

Dlatego CTS ustala zasady przez które zestawy składowe formują granice widoczności dla typu i agent czasu uruchomienia wymusza zasady widoczności.

 

Bez względu na to czy typ jest widoczny dla wywołującego, ten typ kontroluje czy ten wywołujący ma dostęp do swoich członków. Nastepująca lista pokazuje ważne opcje dla kontrolowania dostępu do metody lub pola:

 

· Private. Wywoływalne tylko przez inne metody w tym samym typie klasy.

 

· Family. Wywoływalne przez typy pochodne, bez względu na to czy one są w tym samym zestawie składowym. Wiele jezyków (jak C++ i C#) odnosi się do family jako protected.

 

· Family and Assembly. Wywoływalne przez typy pochodne, ale tylko jeśli te typy pochodne są określone w tym samym zestawie składowym.

 

· Assembly. Wywoływalne przez jakikolwiek kod w tym samym zestawie składowym. Wiele jezyków odnosi się do assembly jako internal.

 

· Family or Assembly. Wywoływalne przez typy pochodne w jakimkolwiek zestawie składowym i przez jakiekolwiek typy w tym samym zestawie składowym.C# odnosi się do family or assembly jako protected internal.

 

· Public. Wywoływalne przez jakikolwiek kod w jakimkolwiek zestawie składowym.

 

Dodatkowo CTS definiuje zasady rządzące dziedziczeniem typu, funkcjami wirtualnymi, czasem życia obiektu itd. Te zasady zostały zaprojektowane dla dostosowania semantyki wyrażanej w nowoczesnych językach programowania. W rzeczywistości nie musimy uczyć sie zasad CTS jako takich, bo dany język, którego używamy, ujawnia swoją własną składnię języka i typowe zasady w ten sam sposób, z którymi jesteśmy zaznajomieni dzisiaj. To mapuje składnię specyficzną dla języka na język CLR, kiedy to emituje zarządzany moduł.

 

Kiedy pracujemy z CLR, dobrze jest myśleć o danym języku i zachowaniu naszego kodu jako dwóch oddzielnych rzeczach. Używając C++ możemy definiować C# lub Visual Basic.NET dla określenia tego samego typu z tymi samymi członkami. Składnia, której używamy do definiowania tego typu, jest inna zależnie od języka, którego wybierzemy, ale zachowanie typu będzie zupełnie takie same bez względu na język, bo CLR (przez CTS) definiuje zachowanie tego typu.

 

C# VB C++ J# JScript …

 

——————————————————————————————————–

 

Różna składnia

 

——————————————————————————————————–

 

CLR przez CTS

 

——————————————————————————————————–

 

Takie samo zachowanie

 

 

Np. CTS wspiera tylko pojedyncze dziedziczenie. Język C++ wspiera typy, które dziedziczą z wielu typów podstawowych, jednak CTS nie może akceptować i operować na jakimkolwiek takim typie. Aby nam pomóc, kompilator Visual C++ raportuje błąd, jeśli wykryje, że usiłujemy stworzyć zarządzany kod, który zawiera typ dziedziczony z wielu typów podstawowych.

 

Inna zasada CTS:

 

Wszystkie typy muszą ostatecznie dziedziczyć z predefiniowanego typu, System.Object. Object jest nazwą typu zdefiniowanego w przestrzeni nazwy System. Ten Object jest rootem dla wszystkich innych typów i dlatego gwarantuje, że każda instancja typu ma minimalny zestaw zachowań. Konkretnie typ System.Object pozwala nam na:

 

· porównanie dwóch instancji dla równości, jednolitości (equality)

 

· otrzymanie kodu hashowanego (hash code) dla danej instancji

 

· zapytanie (query) typu true o instancję

 

· wykonanie płytkiej (shallow), czyli bitwise kopi danej instancji

 

· otrzymanie reprezentacji ciągu bieżącego stanu obiektu instancji

 

 

Common Language Specification

 

 

COM pozwala stworzonym obiektom w różnych językach komunikować się jeden z drugim. CLR idzie dalej. Integruje wszystkie jezyki, aby pozwolić obiektom stworzonym w jednym języku być traktowanym jako równymi obywatelami przez kod napisany w kompletnie innym języku. Aby to uczynić możliwym, CLR definiuje standard zachowania dla typów, osadza samoopisujące się informacje typu (metadane) i dostarcza wspólnego środowiska wykonania.

 

Integracja językowa jest dobra, ale różne języki są bardzo różne jeden od drugiego. Np. pewnych cech brakuje w innych językach:

 

· rozpoznawanie wielkości liter

 

· unsigned integers

 

· przeciążenie (overloading) operatorów

 

· metody, które wspierają zmienną liczbę parametrów

 

Jeśli zamierzamy tworzyć typy, które są łatwo dostępne z innych języków programowania, wtedy jest ważne, że używamy tylko cech naszego języka programowania, które są gwarantowane, że są dostępne we wszystkich innych językach. Aby pomóc, Microsoft zdefiniował common language specification (CLS), który daje szczegóły dla sprzedawców kompilatorów o minimalnym zestawie cech, które ich kompilatory muszą wspierać, jeśli one mają na celu środowisko uruchomienia CLR.

 

CLR/CTS wspiera wiele więcej cech niż podzestaw zdefiniowany przez CLS, więc jeśli nie martwimy się o interoperacyjność języka z innymi językami, możemy rozwijać bardzo bogate typy ograniczone tylko przez zdolności języka. Konkretnie CTS określa zasady, które muszą być respektowane przez widoczne typ i metody, jeśli one mają być dostępne z języka programowania zgodnym z CLR. Zasady CLS nie odnoszą się do kodu, który jest tylko dostępny w określonym zestawie. Poniżej mamy podsumowanie sposobu, w jakim cechy języka pokrywają się z CLS, a w szerszym kontekscie z CLR/CTS.

 

 

CLR/CTS oferuje szeroko obejmujący zestaw cech. Pewne języki ujawniają wielki podzestaw CLR/CTS; w rzeczywistości programista chcący napisać w języku asmeblera IL jest w stanie użyć wszystkich tych cech oferowanych przez CLR/CTS. Większość innych języków, takich jak C#, VB i Fortran, ujawnia podzestaw cech CLR/CTS dla programisty.

 

CLS określa minimalny zestaw cech, które wszystkie języki muszą wspierać. Jeśli projektujemy typ (klasę) w jednym języku i oczekujemy, że ten typ będzie użyty przez inny język, wtedy nie powinniśmy korzystać z cech, które są poza CLS. Robiąc to znaczy, że członki naszego typu mogłyby być dostępne przez programistów piszących kod w innych językach.

 

W kodzie poniżej, typ odpowiadający CLS jest definiowany w C#. Jednak ten typ ma kilka nieodpowiadających konstrukcji CLS, które powodują, że kompilator C# narzeka w sprawie kodu:

 

using System;

 

 

// Tell compiler to check for CLS Compliance

 

[assembly:CLSCompliant(true)]

 

 

// Errors appear because the class is public

 

public class App {

 

 

// Error: Return type of ‘App.Abc()’ is not CLS-compliant

 

public UInt32 Abc() { return 0; }

 

 

// Error: Identifier ‘App.abc()’ differing

 

// only in case is not CLS-compliant

 

public void abc() { }

 

 

// No error: Method is private

 

private UInt32 ABC() { return 0; }

 

}

 

W powyższym kodzie atrybut [assembly:CLSCompliant(true)] jest stosowany do zestawu składowego. Ten atrybut każe kompilatorowi upewnić się, że jakikolwiek publicznie ujawniany typ nie ma konstrukcji, która uniemożliwiłaby temu typowi być dostępnym z jakiegokolwiek innego języka. Kiedy powyższy kod jest skompilowany, kompilator C# emituje dwa błędy. Pierwszy jest raportowany, bo metoda Abc zwraca unsigned integer; Visual Basic.NET i pewne inne języki nie mogą manipulować wartościami unsigned integer. Ten drugi błąd powstaje, bo ten typ ujawnia dwie metody public, które różnią się tylko wielkością liter: Abc i abc. Visual Basic.NET i pewne inne języki nie mogą wywoływać obu tych metod.

 

Jeśli byśmy skasowali public sprzed klasy App i ponownie to skompilowali, oba błędy znikną.

 

Ten powód jest taki, że typ App byłby domyślny dla internal i dlatego już nie byłby ujawniany na zewnątrz tego zestawu składowego (assembly).

 

W CLR każdy członek typu (klasy) jest albo polem (data) albo metodą (behavior). Tzn., że każdy język programowania musi być w stanie mieć dostęp do pól i wywoływać metody. Pewne pola i pewne metody są używane na specyficzne dla języka lub wspólne dla iwelu języków sposoby. Aby łatwiej kodować te wspólne wzorce programowe, języki typowo oferują dodatkowe abstrakcje. Np. języki ujawniają koncepty takie jak:

 

enums– typ wartości, który określa grupę nazwanych numerycznych stałych

 

tablice (arrays)- struktura danych, w której konkretne elementy są przechowywane w sposób ciągły w pojedynczym bloku pamięci. Jest to nazwana lista wartości, z której każdy ma unikalny klucz do identyfikacji tego. W normalnej tablicy ten klucz jest numeryczny (integer). W tablicy hash (tablica asocjacyjna), klucz jest ciągiem. Zestaw sekwencyjnie indeksowanych elementów mający ten sam wrodzony typ danych. Każdy element tablicy ma unikalny numer indeksu. Zmiany dokonane na jednym elemencie tablicy nie mają wpływu na pozostałe elemeny.

 

właściwości (properties)- Właściwości określają obiekt cechami charakterystycznymi takimi jak rozmiar, kolor i ulokowanie na ekranie lub stan obiektu, taki jak włączony (enabled) lub wyłączony (disabled).

 

indeksery (indexers)- mechanizm indeksowania, który ma szybki dostęp do przechowywanych danych

 

delegaty (delegates)typ dla definiowania podpisu metody, aby instancje delegata mogły przechowywać i wywoływać metodę lub listę metod, które dopasowuje do swego podpisu.

 

zdarzenia (events)- akcja skierowana na cel, której celem jest zmiana stanu (statusu) tego celu.

 

konstruktorzy (constructors)- specjalna metoda klasy, która konstruuje obiekt i zwraca go. Funkcja obiektu, która inicjuje ten obiekt i przygotowuje go do wywołania.

 

destruktorzy (destructors)- specjalna metoda, która jest wywoływana, kiedy obiekt ma być zniszczony (samozniszczenie).

 

przeciążenie operatorów (operator overloads)- rodzaj przeciążenia, dzięki któremu możemy działać na wbudowanych operatorach, aby zmusić je do pracy (składniowo) na obiektach, jak gdyby były one zwykłymi wartościami typu scalar (prosta wartość taka jak liczba lub ciąg), ale z bieżącą semantyką dostarczoną przez tę klasę obiektu.

 

konwersja operatorów (conversion operators)- specjalny członek funkcji, który określa jak obiekt może jednoznacznie być konwertowany na obiekt innego typu. To jest deklarowane przy użyciu formy operatora type().

 

 

Kiedy kompilatory napotykają jakąkolwiek z tych konstrukcji w naszym kodzie, taki kompilator musi przetłumaczyć je na pola i metody, aby CLR (w jakimkolwiek języku programowania) mógł mieć dostęp do tych konstrukcji.

 

Rozważamy następujący typ definicji, która zawiera:

 

– konstruktor

 

– destruktor

 

– pewne przeciążone operatory

 

– właściwość

 

– indekser

 

– zdarzenie

 

Dodatkowy specjalny kod jest wprowadzany, aby uczynić ten kod skompilowanym wg. CLR–ten kod nie ilustruje poprawnego sposobu implementacji typu wg. CLR.

 

using System;

 

 

class Test {

 

// Constructor

 

public Test() {}

 

 

// Destructor

 

~Test() {}

 

 

// Operator overload

 

public static Boolean operator == (Test t1, Test t2) {

 

return true;

 

}

 

public static Boolean operator != (Test t1, Test t2) {

 

return false;

 

}

 

 

// An operator overload

 

public static Test operator + (Test t1, Test t2) { return null; }

 

 

// A Property

 

public String AProperty {

 

get { return null; }

 

set { }

 

}

 

 

// An Indexer

 

public String this[Int32 x] {

 

get { return null; }

 

set { }

 

}

 

 

// An Event

 

event EventHandler AnEvent;

 

}

 

Kiedy kompilator kompiluje ten kod, wynikiem jest typ, który ma wiele określonych w tym pól i metod. Możemy łatwo zobaczyć to używając narzędzia dezasemblera IL (ILDasm.exe) dostarczonego z .NET Framework SDK dla zbadania wynikowego zarządzanego modułu:

 

 

Ta tablica pokazuje jak konstrukcje języka programowania są mapowane na ekwiwalenty pól i metod CLR:

 

 

Dodatkowe nodes pod Test type, które nie są wymienione w powyższej tabeli– .class, .custom, AnEvent, AProperty i Item–identyfikują dodatkowe metadane o tym typie. Te nodes nie mapują na pola lub metody, one po prostu oferują pewne dodatkowe informacje o tym typie, że CLR, języki programowania lub narzędzia mogą mieć dostęp do tego. Np. narzędzie może widzieć, że Test type oferuje zdarzenie zw. AnEvent, które jest ujawniane przez te dwie metody (add_AnEvent i remove_AnEvent).

 

 

Interoperacyjność i niezarządzany kod

 

 

.NET Framework oferuje wiele korzyści nad innymi platformami programistycznymi. Jednak jest bardzo mało firm, które mogą pozwolić sobie na przeprojektowanie i przeimplementowanie całego swojego kodu. Microsoft realizuje to i zbudował CLR, aby to zaoferowało mechanizmy, które pozwalają aplikacji składać się z zarówno zarządzanych i niezarządzanych części. Konkretnie CLR wspiera trzy interoperacyjne scenariusze:

 

 

– Zarządzany kod może wywoływać niezarządzaną funkcję w DLL. Zarządzany kod może łatwo wywoływać funkcje zawarte w DLLs używając mechanizmu zw. P/Invoke (Platform Invoke). Jednak wiele typów zdefiniowanych w FCL wewnętrznie wywołuje funkcje eksportowane z Kernel32.dll, User32.dll itd. Wiele języków programowania będzie ujawniać mechanizm, który ułatwia dla zarządzanego kodu wywołanie dla niezarządzanych funkcji zawartych w DLLs.

 

 

Zarządzany kod<——————–P/Invoke<—————-niezarządzane funkcje DLLs

 

 

Np. Aplikacja C# lub VB może wywoływać funkcję CreateSemaphore eksportowaną z Kernel32.dll.

 

– Zarządzany kod może używać istniejącego komponentu COM (server). Wiele firm już zaimplementowało wiele niezarządzanych komponentów COM. Używając biblioteki typu z tych komponentów, możemy stworzyć zarządzany zestaw składowy (assembly) tak, że opisuje komponent COM. Zarządzany kod może mieć dostęp do tego typu w zarządzanym zestawie (assembly) tak jak jakikolwiek inny zarządzany typ. Patrzymy na narzędzie TlbImp.exe, które jest z .NET Framework SDK. Jeśli nie mamy biblioteki typu (typy library) lub chcemy mieć większą kontrolę na tym, co wytwarza TlbImp.exe, możemy ręcznie zbudować typ w kodzie źródłowym, którego CLR może używać dla robienia odpowiedniej współpracy.

 

 

Zarządzany kod<————————komponent COM

 

 

Np. używając komponentów DirectX COM z aplikacji C# lub VB.

 

– Niezarządzany kod może używać zarządzanego typu (server). Wiele z istniejącego niezarządzanego kodu wymaga, aby dostarczać komponent COM, aby ten kod działał poprawnie. Możemy implementować te komponenty łatwo używając zarządzanego kodu, unikając całego tego kodu, który ma do czynienia z obliczniem odniesienia i interfejsów. Patrzymy narzędzia TlbExp.exe i RegAsm.exe, które są z .NET Framework SDK.

 

 

Niezarządzany kod<——————-zarządzany typ

 

 

Np. Tworzenie ActiveX control lub rozszerzenia shella w C# lub VB.

 

Dodatkowo do powyższego kompilator Microsoft Visual C++ (version 13) wspiera nowy przełącznik wiersza polecenia /clr. To każe kompilatorowi emitować kod IL zamiast natywnych instrukcji x86. Jeśli mamy większą ilość istniejącego niezarządzanego kodu C++, możemy przekompilować ten kod na zarządzany, używając tego nowego przełącznika kompilatora. Ten nowy kod będzie wymagał CLR do wykonania i możemy zmodyfikować ten kod z czasem, aby wykorzystać cechy specyficzne dla CLR. Przełącznik /clr nie może kompilować do IL jakiejkolwiek metody, która robi jedną z następujących rzeczy:

 

· zawiera inline assembly language (przez słowo kluczowe __asm),

 

· bierze różną liczbę argumentów

 

· wywołuje setjmp

 

· zawiera wrodzone procedury (takie jak __enable, __disable, _ReturnAddress i

 

_AddressOfReturnAddress).

 

Dla kompletności listy konstrukcji, które kompilator C++ nie może skompilować do IL, patrzymy dokumentację dla kompilatora Visual C++. Kiedy ten kompilator nie może kompilować tej metody do IL, to kompiluje tę metodę do x86, aby ta aplikacja ciągle działała.

 

Chociaż wytworzony kod IL jest zarządzany, te akurat dane nie są zarządzane. Czyli obiekty danych nie są alokowane z zarządzanej sterty (heap) i one nie podlegają zbieraczowi śmieci. W rzeczywistości te typy danych nie mają wytworzonych metadanych dla nich i te nazwy metod typów są maglowane.

 

Kod C poniżej wywołuje standardową bibliotekę C czasu uruchomienia funkcji printf i też wywołuje metodę WriteLine w System.Console. Typ System.Console jest określony w Framework Class Library.

 

Odpowiednio kod C/C++ może używać bibliotek dostępnych dla C/C++, a także zarządzane typy.

 

#include <stdio.h> // For printf

 

 

#using <mscorlib.dll> // For managed types defined in this assembly

 

using namespace System; // Easily access System namespace types

 

 

// Implement a normal C/C++ main function

 

void main () {

 

 

// Call the C-Runtime library’s printf function

 

printf(“Displayed by printf.\r\n”);

 

 

// Call System.Console’s WriteLine method

 

Console::WriteLine(“Displayed by Console::WriteLine.”);

 

}

 

Kompilowanie tego kodu nie mogłoby być łatwiejsze. Jeśli ten kod powyższy umieszczony byłby w pliku Test.cpp, skompilowalibyśmy to przez wykonanie następującej linii przy zachęcie:

 

cl /clr Test.cpp

 

Wynikiem jest plik zestawu składowego (assembly) Test.exe. Jeśli uruchomimy Test.exe, zobaczymy następujące dane wyjściowe:

 

C:\>Test

 

Displayed by printf.

 

Displayed by Console::WriteLine.

 

Jeśli używamy ILDasm dla zbadania tego pliku, zobaczymy następujące:

 

 

 

ILDasm pokazuje wszystkie globalne funkcje i globalne pola zdefiniowane w tym zestawie składowym (assembly). Ten kompilator wygenerował wiele materiału automatycznie. Jeśli kilkniemy dwa razy na metodę Main, ILDasm pokaże nam kod IL:

 

 

.method public static int32

 

modopt([mscorlib]System.Runtime.CompilerServices.CallConvCdecl)

 

main() cil managed

 

{

 

.vtentry 1 : 1

 

// Code size 28 (0x1c)

 

.maxstack 1

 

IL_0000: ldsflda valuetype

 

$ArrayType$0x0faed885 ‘?A0x44d29f64.unnamed-global-0’

 

IL_0005: call vararg int32

 

modopt([mscorlib]System.Runtime.CompilerServices.CallConvCdecl)

 

printf(int8

 

modopt([Microsoft.VisualC]Microsoft.VisualC.NoSignSpecifiedModifier)

 

modopt([Microsoft.VisualC]Microsoft.VisualC.IsConstModifier)*)

 

IL_000a: pop

 

IL_000b: ldsflda valuetype

 

$ArrayType$0x0e6cb2b2 ‘?A0x44d29f64.unnamed-global-1’

 

IL_0010: newobj instance void [mscorlib]System.String::.ctor(int8*)

 

IL_0015: call void [mscorlib]System.Console::WriteLine(string)

 

IL_001a: ldc.i4.0

 

IL_001b: ret

 

} // end of method ‘Global Functions’::main

 

 

To nie wygląda ładnie, bo ten kompilator generuje wiele specjalnego kodu dla wykonania całej tej pracy, aby wszystko (kod zarządzany i niezarządzany) działało jak trzeba. Możemy jednak zobaczyć, że powyższy IL wywołuje zarówno printf i metodę WriteLine w konsoli.

 

 

Microsoft .NET Framework SDK Version 2.0 ReadMe

 

 

SDK zawiera nowe przykłady pokazujące użycie nowych technologii .NET Framework. Te sample są w dokumentacji SDK, jako część QuickStart lub w folderze SDK LateBreaking.

 

.NET Framework SDK zawierają:

 

– documentation

 

– sample code

 

– tools

 

– reference assemblies

 

To umożliwia nam rozwój kodu, który ma na celu .NET Compact Framework. Aby zainstalować .NET Compact Framework reference assemblies i MSBuild files, instalujemy NETCFSetUpV2.msi zlokalizowany w podkatalogu CompactFramework w SDK.

 

 

Znane zagadnienia

 

 

Konfiguracja i ustawienie

 

SQL Server Express nie jest dostepny dla wersji SDK opartej na Itanium

 

 

Sample SQL Some QuickStart, które są zawarte w wersji SDK opartej na Itanium, wymagają użycia bazy danych sampli i są konfigurowane do użycia z SQL Server Express.

 

 

Rozwiazaniem jest instalacja wersji 64-bit dla Microsoft SQL Server 2005 i uruchomienie:

 

 

ConfigSamples.exe –sql_instance:<Microsoft SQL Server 2005 Instancename>

 

z wiersza polecenia dla ustawienia sampli QuickStart dla użycia Microsoft SQL Server 2005.

 

 

Nie jesteśmy w stanie zainstalować poprzednio odznaczone komponenty, kiedy naprawiamy SDK

 

 

Kiedy instalujemy SDK, możemy wybrać różne komponenty do instalcji. Kiedy ponownie uruchamiamy SDK ustawienie i wybieramy “Repair”, nie możemy zainstalować poprzednio odznaczone komponenty.

 

Rozwiazaniem jest odinstalowanie SDK i potem ponowna instalacja tego.

 

 

 

64 bit SDK nie może wykryć twardego dysku, bo jest zapełniony podczas instalacji

 

 

Jeśli dany dysk jest pełny, kiedy usiłujemy zainstalować 64 bit SDK, program Setup zatrzyma się przy “Setup is configuring the install” zamiast wyświetlenia wiadomości o błędzie, że dysk jest zapełniony.

 

Rozwiązaniem

 

jest użycie cancel w ustawieniu SDK, utworzenie wymaganej przestrzeni dyskowej i pomowna instalacja.

 

 

SignTool.exe w 64 bit SDK wyświetla błąd wersji CAPICOM, kiedy jest wykonywany

 

 

Jeśli zainstalowaliśmy SDK, ale nie Visual Studio 2005, na maszynie 64 bit, SignTool.exe, kiedy użyty dla podpisywania, da następujący błąd:

 

 

 

SignTool Error: Signtool requires CAPICOM version 2.1.0.1 or higher. Please copy the latest version of CAPICOM.dll into the directory that contains SignTool.exe. If CAPICOM.dll exists, you may not have proper permissions to install CAPICOM.

 

 

 

To jest ponieważ CAPICOM.dll nie zostało zarejestrowane poprawnie.

 

 

Rozwiązaniem jest skopiowanie CAPICOM.dll z Program Files\Common\Microsoft Shared\CAPICOM do katalogu SignTool.exe.

 

 

ConfigSample.exe nawala, jeśli Internet Information Server jest zainstalowany po instalacji Visual Studio 2005 lub SDK

 

 

Jeśli zainstalowaliśmy sample dla SDK w następującym porządku:

 

– Instalowanie Visual Studio 2005 lub SDK

 

– Instalowanie Internet Information Server

 

– Wykonanie ConfigSample.exe dla ustawienia sampli dla zobaczenia, czy ConfigSample.exe nawali.

 

Rozwiazaniem jest uruchomienia z wiersza polecenia SDK:

 

 

aspnet_regiis.exe -u

 

 

Jeszcze raz uruchomić ConfigSamples.exe

 

 

Sample

 

 

Pewne sample wymagają nagłówków Platform SDK

 

 

Następujące sample wymagają nagłówków Platform SDK:

CLR Versioning
GCDemo
Callback
ClassMethods
PInvoke

 

Te sample muszą być zbudowane przy użyciu plików headera Windows. Pliki headera Windows są dostępne zarówno z

 

Visual C++ (używając wiersza polecenia Visual Studio 2005 z odpowiednio ustawioną ścieżką include) lub przez użycie Platform SDK i ustawienie ścieżki include. To jest ponieważ .NET Framework nie ma wszystkich niezarządzanych nagłówków, które mogłyby być znalezione w Visual C++ i platformie SDK. Możemy ściągnąć Platform SDK, które zawrze wszystkie pliki headera Windows w Download Center.

 

 

Pewne sample nie działają z okna wiersza polecenia

 

 

Następujace sample nie działają w środowisku wiersza polecenia i muszą być uruchamiane w Visual Studio 2005:

Application samples
SecureString

Technology samples
CLR Version Detection

 

 

1. Otwieramy Windows Explorer i nawigujemy do pliku .exe (SecureStringConsoleDemo.exe dla sampla SecureString i CLRVer.exe dla sampla CLR Version Detection) w katalogu sampli.
2. Dwa razy klikamy .exe.

 

 

Sampl SQL CE ResultSet wymaga SQL CE

 

 

Aby użyć sampla SQL CE ResultSet, technologia sampla z samplami .NET Compact Framework, musimy zainstalować SQL CE, które jest zawarte w Visual Studio 2005.

 

Rozwiazaniem jest instalacja

 

Visual 2005, która instaluje SQL CE domyślnie, kiedy “smart device projects” podczas ustawienia.

 

 

Nadpisanie konfiguracji CPU dla zbudowania sampli C++ używając MSBuild

 

 

Pewne sample C++ są z domyślną konfiguracją CPU są inne od tego, co nasz kompilator w rzeczywistośvi wspiera, dając błąd.

 

Aby zbudować sampl C++ używając

 

64-bit .NET Framework 2.0 SDK, wpisujemy następujące polecenia:

 

 

Dla systemów opartych na x64:
Msbuild mySolution.sln /p:Platform=x64

Dla systemów opartych na Itanium:
Msbuild mySolution.sln /p:Platform=Itanium
Aby crosskompilować celując do innej platformy, niż tej, na której programujemy, musimy zainstalować Visual Studio 2005.

 

 

Pewne sample C++ samples z Project-to-Project nie kompiluje się z Msbuild

 

 

QuickStart samples
Wszystkie implementacje C++ sampli zdalnych (Remoting samples) pod sekcją “How To”.

Technology samples
Remoting Through Configuration

 

 

 

 

 

Używamy VCbuild zamiast Msbuild na pliku rozwiązania dla zbudowania danego sampla.

 

Np.
VCbuild mySolution.sln

 

 

Sampl aplikacji nie kompiluje się

 

 

Następujący sampl nie kompiluje się, bo to pokazuje cechy .NET Framework 2.0, które nie są już dłuzej dostępne.

 

Application sample
CoopFiber

 

 

Nie ma sposobu na to

 

 

Sampl technologii (technology sample) nie kompiluje się

 

 

Następujacy sampl nie kompiluje się, bo to pokazuje cechy .NET Framework 2.0, które nie są już dostępne.

 

 

 

Technology sample
IXmlSerializable (tylko implementacja Visual Basic)

 

 

Usuwamy atrybut Method w tym samplu i budujemy jeszcze raz.

 

 

W ReadMe w samplach SQL CLR brakuje wpisów

 

 

Sample SQL CLR w rzeczywistości mają plik ReadMe.txt, który w pełni nie wyjaśnia jak budować i instalować dany sampl.

 

Sample ReadMe.txt dla SQL CLR powinny komunikować, że możemy użyć albo Visual Studio 2005 albo MSBuild w oknie wiersza polecenia .NET Framework 2.0 SDK dla kompilacji tych sampli i potem powinniśmy użyć SQL Server 2005 Manager Studio, SQL Express Manager lub SQLCMD z wiersza polecenia dla wykonania skryptów instalacji.

 

 

W ReadMe w samplach SQL CLR brakuje wpisów

 

 

Sample SQL CLR w rzeczywistości mają plik ReadMe.txt, który w pełni nie wyjaśnia jak budować i instalować dany sampl.

 

Sample

 

ReadMe.txt dla SQL CLR powinny komunikować, ze możemy użyć albo Visual Studio 2005 albo MSBuild w oknie wiersza polecenia .NET Framework 2.0 SDK dla kompilacji tych sampli i potem powinnismy użyć SQL Server 2005 Manager Studio, SQL Express Manager lub SQLCMD z wiersza poelcenia dla wykonania skryptów instalacji.

 

 

Sampl “Working with Databases in VWD” w QuickStart wyświetla błąd, kiedy sortujemy kolumny

 

 

Sampl “Working with Database in VWD” pod sekcją “Performing Data Access” w QuickStart wyświetla błąd “Cannot find column id”, kiedy próbujemy posortować tablicę przez kliknięcie albo na nagłówek kolumy “ID” albo na nagłówek kolumny “Name”.

 

 

Aby to naprawić, edytujemy SQLExpress_cs.aspx i SQLExpress_vb.aspx in <sdk Install Path>\QuickStart\aspnet\samples\data z następującym:

 

 

 

Zastępujemy następujące w zarówno SQLExpress_cs.aspx i SQLExpress_vb.aspx

 

<Columns>
<asp:BoundField DataField=”ContactID” HeaderText=”ID” ReadOnly=”True” SortExpression=”ID” />
<asp:BoundField DataField=”ContactName” HeaderText=”Name” SortExpression=”Name” />
</Columns>

 

z następującym:

 

<Columns>
<asp:BoundField DataField=”ContactID” HeaderText=”ID” ReadOnly=”True”
SortExpression=”ContactID” />
<asp:BoundField DataField=”ContactName” HeaderText=”Name” SortExpression=”ContactName” />
</Columns>

 

 

Naprawa instalacji

 

 

Możemy potrzebować naprawy instalacji .NET Framework SDK po uaktualnieniu naszego SO lub jeśli nasz system zostanie zniszczony.

 

Aby naprawić .NET Framework SDK

 

  1. Otrzymujemy źródło oryginalnej instalacji. Np. jeśli instalujemy .NET Framework SDK z CD lub DVD, wkładamy ten dysk. Lub jesli ściagnęliśmy .NET Framework SDK, ściągamy znowu i wybieramy zapisanie na dysku twardym w PC. Jeśli zainstalowaliśmy z udziału sieci, jeszcze raz łączymy się.

  2. W menu Start, wybieramy Run. Wpisujemy:

 

cmd

 

  1. W oknie wiersza polecenia:

 

n:\<Installation Source>\setup.exe /t:%temp% /c:”msiexec.exe /fvecms %temp%\netfxsdk.msi”

 

Np.

 

d:\dotNetFrameworkSDK\setup.exe /t:%temp% /c:”msiexec.exe /fvecms %temp%\netfxsdk.msi”

 

 

Microsoft .NET Framework Tools

 

 

Narzędzia Microsoft .NET Framework SDK są przeznaczone dla ułatwienia tworzenia, stosowania i zarządzania aplikacjami i komponentami, które mają na celu CLR. Możemy uruchamiać te narzędzia z wiersza polecenia z wyjątkiem Assembly Cache Viewer (Shfusion.dll) i Microsoft CLR Debugger (DbgCLR.exe). Musimy mieć dostęp do Assembly Cache Viewer (Shfusion.dll) z Windows Explorer. Narzędzia są w katalogu SDK \bin. Aby te narzędzia dobrze funkcjonowały, muszą być ustawione zmienne środowiskowe: Path, Include, i Lib.

 

Ustawiamy zmienne środowiskowe Path, Include i Lib przez uruchomienie SDKVars.bat, zlokalizowanego w katalogu <SDK>\v2.0\Bin. SDKVars.bat musi być wykonany w każdej powłoce polecenia.

 

 

Narzędzia konfiguracji i rozmieszczenia

 

 

ASP.NET IIS Registration Tool (Aspnet_regiis.exe)

 

Pozwala administratorowi lub instalacji programu na uaktualnienie scriptmaps dla aplikacji ASP.NET dla wskazania na wersję ASP.NET ISAPI skojarzoną z tym narzędziem. Możemy też użyć tego narzędzia dla wykonania innych operacji konfiguracji ASP.NET.

 

Aspnet_regiis.exe może być znaleziony w:

 

“%windir%\Microsoft.NET\Framework\v2.0.xxxx” gdzie xxxx jest build number dla .NET Framework, którego używamy.

 

 

Assembly Cache Viewer (Shfusion.dll)

 

Pozwala nam przejrzeć i manipulować zawartością global assembly cache przez użycie Windows Explorer.

 

Shfusion.dll może być znaleziony w

 

“%windir%\Microsoft.NET\Framework\v2.0.xxxx” gdzie xxxx jest build number dla .NET Framework, którego używamy.

 

 

Assembly Linker (Al.exe)

 

Generuje plik z manifestem zestawu składowego z jednego lub wielu plików, które są albo plikami zasobów albo plikami Microsoft intermediate language (MSIL).

 

Al.exe może być znaleziony w “%windir%\Microsoft.NET\Framework\v2.0.xxxx” gdzie xxxx jest build number dla .NET Framework, którego używamy.

 

 

Assembly Registration Tool (Regasm.exe)

 

Odczytuje metadane w zestawie składowym i dodaje potrzebne wpisy do rejestru, co pozwala klientom COM na stworzenie klas .NET Framework przejrzyście.

 

Regasm.exe może być znaleziony w %windir%\Microsoft.NET\Framework\v2.0.xxxx” gdzie xxxx jest build number dla .NET Framework, którego używamy.

 

 

Assembly Binding Log Viewer (Fuslogvw.exe)

 

 

Wyświetla szczegóły dla nieudanych wiązań (binds) zestawu składowego. Te informacje pomagają nam diagnozować dlaczego .NET Framework nie może lokować zestaw składowy w czasie uruchomienia.

 

 

Global Assembly Cache Tool (Gacutil.exe)

 

Pozwala nam przeglądać i manipulować zawartością global assembly cache i download cache. Podczas gdy Shfusion.dll dostarcza podobnej funkcjonalności, możemy używać Gacutil.exe z build scripts, plików makefile files i plików batch.

 

 

Installer Tool (Installutil.exe)

 

Pozwala nam zainstalować i odinstalować zasoby serwera przez wykonanie komponentów instalera określonego zestawu składowego.

 

Installutil.exe może być znaleziony w “%windir%\Microsoft.NET\Framework\v2.0.xxxx” gdzie xxxx jest build number dla .NET Framework, którego używamy.

 

 

Manifest Tool (Mt.exe)

 

Pozwala nam generować i scalać niezarządzane manifesty komponentu winSxS i zarządzane manifesty zestawu składowego.

 

 

Isolated Storage Tool (Storeadm.exe)

 

 

Listuje i usuwa wszystkie istniejące miejsca przechowywania dla bieżącego zalogowanego użytkownika.

 

 

Native Image Generator Tool (Ngen.exe)

 

 

Tworzy natywny obraz z zarządzanego zestawu składowego i instaluje to w natywnym image cache na lokalnym PC.

 

Ngen.exe może być znaleziony w “%windir%\Microsoft.NET\Framework\v2.0.xxxx” gdzie xxxx jest build number dla .NET Framework, którego używamy.

 

 

.NET Framework Configuration Tool (Mscorcfg.msc)

 

Dostarcza graficznego interfejsu dla zarządzania strategią bezpieczeństwa .NET Framework i aplikacjami, które używają zdalnych usług. To narzędzie też pozwala nam zarządać i konfigurować zestawy składowe w global assembly cache.

 

Mscorcfg.msc moze być znaleziony w “%windir%\Microsoft.NET\Framework\v2.0.xxxx” gdzie xxxx jest build number dla .NET Framework, którego używamy.

 

 

.NET Services Installation Tool (Regsvcs.exe)

 

Dodaje zarządzane klasy do Windows 2000 Component Services przez załadowanie i rejestrację zestawu składowego i generowanie, rejestrowanie i instalowanie biblioteki typu w istniejacą aplikację COM+ 1.0.

 

Regsvcs.exe moze być znaleziony w “%windir%\Microsoft.NET\Framework\v2.0.xxxx” gdzie xxxx jest build number dla .NET Framework, którego używamy.

 

 

Soapsuds Tool (Soapsuds.exe)

 

Ponaga nam kompilować aplikacje klienta, ktore komunikują się z XML Web services przez używanie techniki zw. remoting.

 

 

Type Library Exporter (Tlbexp.exe)

 

 

Generuje bibliotekę typu z CLR zestawu składowego.

 

 

Type Library Importer (Tlbimp.exe)

 

 

Konwertuje definicje typu znalezione w bibliotece typu COM na definicje ekwiwalentu w zarządzanym formacie metadanych.

 

 

Web Services Description Language Tool (Wsdl.exe)

 

 

Generuje kod dla XML Web services i klientów XML Web services z plików contract dla z Web Services Description Language (WSDL), plików schema XML Schema Definition (XSD) i dokumentów discovery dla .discomap.

 

 

Web Services Discovery Tool (Disco.exe)

 

Odkrywa URLs of XML Web services zlokalizowane na Web server i zapisuje dokumenty związane z każdą XML Web service na lokalnym dysk.

 

 

XML Schema Definition Tool (Xsd.exe)

 

Generuje XML schemas, które idą za językiem XML Schema Definition (XSD) zaproponowanym przez World Wide Web Consortium (W3C). To narzędzie generuje klasy czasu uruchomienia CLR i klasy DataSet z pliku schema XSD.

 

 

XML Serialization Pre-generation Tool (Sgen.exe)

 

Generuje serializację zestawów składowych do użycia z XmlSerializer. To narzędzie pozwala programistom przedgenerować zestawy składowe dla serializacji i wykorzystanie tych zestawów składowych w aplikacji.

 

 

Narzędzia debuggera

 

 

Microsoft CLR Debugger (DbgCLR.exe)

 

Dostarcza usług debugowania z GUI dla pomocy deweloperom aplikacji w znalezieniu i naprawieniu błędów w programach, które mają na celu agenta czasu uruchomienia.

 

Microsoft CLR Debugger (DbgCLR.exe) jest zlokalizowany w fodlerze SDK\v2.0\GuiDebug.

 

 

Managed Code Debugger (Mdbg.exe)

 

 

Dostarcza usług debugowania wiersza polecenia dla pomocy deweloperom aplikacji w znalezieniu i naprawieniu błędów w programach napisanych z użyciem .NET Framework, które mają na celu agenta czasu uruchomienia.

 

 

Runtime Debugger (Cordbg.exe)

 

Dostarcza usług debugowania wiersza polecenia używając CLR Debug API. Używamy tego narzędzia do znalezienia i naprawienia błedów w programach, które mają na celu agenta czasu uruchomienia.

 

 

Narzędzia bezpieczeństwa

 

 

Certificate Creation Tool (Makecert.exe)

 

 

Generuje certyfikaty X.509 tylko dla celów testowania.

 

 

Certificate Manager Tool (Certmgr.exe)

 

 

Zarządza certyfikatami, certificate trust lists (CTLs) i certificate revocation lists (CRLs).

 

 

Code Access Security Policy Tool (Caspol.exe)

 

 

Pozwala nam badać i modyfikować strategie bezpieczeństwa dostępu do kodu na poziomie maszyny, użytkownika i korporacji.

 

Caspol.exe może być znalezione w “%windir%\Microsoft.NET\Framework\v2.0.xxxx” gdzie xxxx jest build number dla .NET Framework, której używamy.

 

 

PEVerify Tool (PEverify.exe)

 

 

Wykonuje sprawdzania weryfikacji bezpieczeństwa typu bezpiecznego MSIL i sprawdzania walidacji metadanych na określonym zestawie składowym.

 

 

Secutil Tool (Secutil.exe)

 

Wyciaga informacje publicznego klucza dla strong name lub certyfikaty wydawcy Authenticode z zestawu składowego, w formacie, który może być wcielany do kodu.

 

 

Software Publisher Certificate Test Tool (Cert2spc.exe)

 

Tworzy tylko dla celów testowania Software Publisher’s Certificate (SPC) z jednego lub więcej certyfikatów X.509.

 

 

Strong Name Tool (Sn.exe)

 

Pomaga tworzyć zestawy składowe z strong names. Sn.exe dostarcza opcji dla key management, signature generation i signature verification.

 

 

Narzędzia ogólne

 

 

License Compiler (Lc.exe)

 

Odczytuje pliki tekstowe, które zawierają informacje o licencjonowaniu i dają plik .licenses, który może być osadzony w wykonywalnym CLR.

 

 

Management Strongly Typed Class Generator (Mgmtclassgen.exe)

 

Pozwala nam szybko generować klasę wczesnego wiązania w C#, Visual Basic lub JScript dla określonej klasy Windows Management Instrumentation (WMI).

 

 

MSIL Assembler (Ilasm.exe)

 

Generuje plik PE z Microsoft intermediate language (MSIL). Możemy uruchomić wynikowy kod wykonywalny, który zawiera kod MSIL i wymagane metadane dla ustalenia, czy kod MSIL wykonuje, jak oczekujeym.

 

Ilasm.exe może być znaleziony w “%windir%\Microsoft.NET\Framework\v2.0.xxxx” gdzie xxxx jest build number dla .NET Framework, którego używamy.

 

 

MSIL Disassembler (Ildasm.exe)

 

 

Bierze plik PE, który zawiera kod MSIL i tworzy odpowiedni plik tekstowy jak dane wejściowe dla MSIL Assembler (Ilasm.exe).

 

 

Resource File Generator Tool (Resgen.exe)

 

Konwertuje pliki tekstowe i pliki .resx (format zasobu oparty na XML) na binaria plikow zasobów CLR w .NET., które mogą być osadzone w binariach wykonywalnych agenta czasu uruchomienia lub skompilowane na satelickie (podrzędne) zestawy składowe.

 

 

Visual J# Binary Converter Tool (JbImp.exe)

 

To konwertuje pewne pliki kod bajtowy języka Java (.class) na Microsoft® intermediate language (MSIL). To narzędzie umożliwia programistom konwertowanie większość bibliotek na poziomie JDK 1.1.4 i aplikacji dostępnych tylko jako pliki kodu bajtowego na zestawy składowe MSIL i uruchamianie ich na .NET Framework z Visual J# Redistributable Package. Używamy tego narzędzia, tylko jeśli źródła języka Java dla aplikacji lub bibliotek nie są dostępne. Jeśli źródła języka Java są dostępne, zaleca się używania zamiast tego kompilatora vjc.exe.

 

Aby użyć tego narzędzia, Visual J# Redistributable Package 2.0 musi być zainstalowany.

 

 

Windows Forms ActiveX Control Importer (Aximp.exe)

 

Konwertuje definicje typu w bibliotece typu COM dla ActiveX control na Windows Forms control.

 

 

Windows Resource Localization Editor (Winres.exe)

 

 

Pozwala nam szybko i łatwo lokalizować Windows Forms.

 

 

ASP.NET 2.0 z C# jako E-Commerce

 

 

Magia architektury trzypoziomowej

 

 

Generalnie ta architektura odnosi się do dzielenia każdego kawałka funkcjonalności aplikacji na oddzielne komponenty oparte na tym, co one robią i grupując każdy rodzaj komponentu w pojedynczy poziom.

 

Funkcjonalność aplikacji dzielimy na trzy logiczne poziomy:

 

 

– The presentation tier

 

– The business tier

 

– The data tier

 

 

The presentation tier

 

 

Zawiera elementy UI witryny i zawiera cały logic, który zarządza interakcją między gościem a biznesem klienta. Ta ranga ożywia całą witrynę i to jest ważne dla sukcesu witryny. Ponieważ nasza aplikacja jest witryną web, jej poziom prezentacji jest złożony z dynamicznych stron web.

 

 

The business tier (middle tier)

 

 

Dostaje prośby od presentation tier i zwraca wynik do presentation tier zależnie od tego, jaki logic biznesowy to zawiera. Prawie każde zdarzenie, które zdarzy się w presentation tier daje rezultaty w business tier zw. (poza zdarzeniami, które mogą być obsługiwane lokalnie przez presentation tier, takie jak prosta walidacja danych wejściowych). Np. jeśli gość szuka produktu, presentation tier wywołuje business tier i mówi Proszę przyślij produkty, które pasują do kryteriów wyszukiwania.

 

Prawie zawsze business tier musi wywoływać data tier dla informacji dla odpowiedzenia na prośbę presentation tier.

 

 

The data tier (database tier)

 

 

Jest odpowiedzialny za przechowywanie danych aplikacji i wysłanie ich do business tier, kiedy są proszone. Dla witryny e-commerce zw. BalloonShop będziemy przechowywali dane dotyczące produktów (w tym ich kategorie i oddziały), użytkowników, wózki itd. Prawie każda prośba klienta ostatecznie daje wynik w data tier, będącym pytanym dla informacji (poza tym, kiedy poprzednio odzyskane dane zostają scachowane na poziomach business tier lub presentation tier), więc jest ważne mieć szybki system bazy danych.

 

 

Te poziomy są czysto logiczne–nie ma ograniczeń fizycznych dla lokacji każdego poziomu. Możemy je umieścić na pojedynczej maszynie serwera. Możemy też umieścić każdy poziom na oddzielnej maszynie lub nawet podzielić na komponenty pojedynczy poziom na wiele maszyn. Nasz wybór zależy od konkretnych wymagań dla wydajności aplikacji. Ten rodzaj elastyczności wymaga od nas osiągnięcia wielu korzyści.

 

 

Ograniczeniem w tej trzypoziomowej architekturze jest to, że informacje muszą płynąć w porządku sekwencyjnym między poziomami. Presentation tier może być dostępny tylko dla business tier, a nigdy bezpośrednio dla data tier. Business tier jest mózgiem w środku, który kontaktuje się obu poziomami i posiada oraz koordynuje cały przepływ informacji.

 

Jeśli presentation tier ma dostęp bezpośredni do data tier, zasady architektury trzypoziomowej zostałyby zniszczone. Kiedy implementujemy architekturę trzypoziomową, musimy być temu wierni.

 

 

Figure 2-1 is a simple representation of how data is passed in an application that implements the three-tier architecture.

 

 

Figure 2-1. Simple representation of the three-tier architecture

 

 

Prosty scenariusz

 

 

Jak większość witryn komercyjnych (e-commerce), BalloonShop będzie miał wózek. Gość doda produkty do tego wózka przez klikanie guzika Add to Cart.

 

Figure 2-2 shows how the information flows through the application when that button is clicked.

 

 

Figure 2-2. Internet visitor interacting with a three-tier application

 

 

Kiedy użytkownik klika guzik Add to Cart dla określonego produktu (Krok 1), poziom prezentacji (który ma guzik) wysyła prośbę do poziomu biznesu–Hej, chcę ten produkt, aby był dodany do wózka gościa (Krok 2). Poziom biznesu otrzymuje tę prośbę, rozumie, że ten użytkownik chce konkretnego produktu, aby był dodany do wózka i obsługuje prośbę przez kazanie poziomowi danych, aby zaktualizował wózek gościa przez dodanie wybranego produktu (Krok 3). Poziom danych musi być wywołany, bo to przechowuje i zarządza całymi danymi witryny web, w tym informacje o wózku użytkowników.

 

Poziom danych uaktualnia bazę danych (Krok 4) i ostatecznie zwraca kod sukcesu do poziomu biznesu. Ten poziom biznesu (Krok 5) obsługuje kod zwrócony i jakiekolwiek błędy, które mogłyby zdarzyć się na poziomie danych podczas uaktualnienia bazy danych i potem zwraca dane wyjściowe do poziomu prezentacji.

 

Ostatecznie poziom prezentacji generuje uaktualniony widok wózka (Krok 6). Wyniki wykonania są zawijane przez wygenerowaną stronę web HTML, która jest zwracana do gościa (Krok 7), gdzie uaktualniony wózek może być widziany w ulubionej przeglądarce gościa.

 

Poziom biznesu nie robi dużo przetwarzania i jego logic biznesu nie jest zbyt skomplikowany. Jednak jeśli nowe zapasy biznesu pojawiają się dla naszej aplikacji, zmienimy poziom biznesu. Np. jeśli logic biznesu określił, że produkt mógłby tylko być dodany do wózka, jeśli jego ilość w ofercie jest większa niż zero, dodatkowo wywołanie poziomu danych byłoby uczynione dla ustalenia tej ilości. Poziom danych tylko byłby poproszony o uaktualnienie wózka, jeśli produkty byłyby w ofercie. W jakimkolwiek wypadku poziom prezentacji jest informowany o stanie i dostarcza informacji zwrotnej odczytywanej dla człowieka dla gościa.

 

 

Co jest w Number?

 

 

Interesujące jak różnie każdy poziom interpretuje ten sam kawałek kodu informacji. Dla poziomu danych liczby i informacje, które przechowuje nie mają znaczenia, bo ten poziom jest silnikiem, który zapisuje, zarządza i odzyskuje liczby, ciągi i inne typy danych–nie ilości produktów lub nazwy produktów.

 

W kontekście poprzedniego przykładu, ilość produktu 0 reprezentuje prosta, zwykła liczba bez żadnego znaczenia dla poziomu danych (jest to po prostu 0 w liczbie całkowitej 32-bitowej).

 

Te dane zyskują na znaczeniu, kiedy ten poziom biznesu odczytuje to. Kiedy poziom biznesu prosi poziom danych o ilość produktu i dostaje w rezultacie 0, czyli jest interpretowany przez poziom biznesu jako Hej, nie ma żadnych produków w ofercie. Te dane są ostatecznie zawijane (wrapped) w miłą, wizualną formę przez poziom prezentacji np. etykietę Przykro mi, w tym momencie produkt jest niedostepny.

 

Nawet gdy to jest nieprawdopodobne, że chcemy zabronić klientowi dodawania produktu do wózka, jeśli produkt nie jest w ofercie, przykład jest dobry, aby zaprezentować jeszcze inny sposób jak każdy z trzech poziomów ma różny cel.

 

 

Figure 2-3. Internet visitor interacting with a three-tier application

 

 

Właściwy Logic dla właściwego poziomu

 

 

Ponieważ każda warstwa zawiera swój własny logic, czasami to może być skomplikowane, aby zadecydować, gdzie dokładnie nakreślimy linie między poziomami.

 

W poprzednim scenariuszu zamiast odczytu ilości produktu na poziomie biznesu i decydowaniu czy ten produkt jest dostępny w oparciu o tę liczbę (wynikającą w wywoływaniach dwóch poziomach danych i całkowicie bazę danych), moglibyśmy mieć metodę pojedynczego poziomu danych zw. AddProductIfAvailable, która dodaje produkt do wózka tylko jeśli to jest dostępne w ofercie.

 

W tym scenariuszu pewien logic jest transferowany z poziomu biznes do poziomu danych. W wielu innych okolicznościach moglibyśmy mieć opcję do umieszczenia tego samego logic w jednym poziomie lub innym, lub może w dwóch. W większości wypadków nie ma pojedynczej dobrej drogi do implementacji architektury trzypoziomowej i będziemy potrzebowali kompromis lub wybór w oparciu o osobiste preferencje lub zewnętrzne ograniczenia.

 

Czasami jeśli nawet znamy właściwą drogę (w odniesieniu do architektury) do zaimplementowania czegoś, moglibyśmy wybrać złamanie zasad dla zwiększenia wykonania. Jako generalna zasada, jeśli wykonanie może być ulepszone w ten sposób, jest w porządku złamać nieco ostre granice między poziomami (np. dodajemy pewne zasady biznesu do poziomu danych lub odwrotnie), jeśli te zasady nie są skłonne do zmiany w czasie. Inaczej trzymanie wszystkich tych zasad biznesu w środkowym poziomie jest preferowane, bo to generuje czystszą aplikację, która jest łatwiejsza do utrzymania.

 

Ostatecznie nie ulegajmy pokusie dostępu bezpośredniego do poziomu danych z poziomu prezentacji. To jest powszechna pomyłka. Dane mogą być zapisane do krótkiego, pojedynczego pliku zamiast oddzielnych poziomów.

 

 

Trzypoziomowa architektura dla BalloonShop

 

 

Implementowanie architektury trzypoziomowej dla witryny web BalloonShop pomoże nam osiagnąć cele wylistowane na początku. Zasada kodowania może być nałożona na system, który może wydawać się sztywny na początku, pozwala na elastyczność i rozszerzalność poziomów w dalszej perspektywie.

 

Dzielenie głównych części aplikacji na oddzielne mniejsze komponenty też zachęca do ponownego używania. Więcej niż raz kiedy dodajemy nowe cechy do tej witryny, zobaczymy, że możemy ponownie użyć pewne istniejące bity. Dodajemy nową cechę bez potrzeby zmiany wiele z tego, co już istnieje jest samo w sobie dobrym przykładem ponownego użycia. Także mniejsze części kodu umieszczane w swoich właściwych miejscach są łatwiejsze do dokumentacji i analizy potem.

 

Inną korzyścią architektury trzech poziomów jest to, że jeśli należycie zaimplementowane, cały system jest odporny na zmiany. Kiedy bity w jednym z poziomów się zmienią, inne poziomy zazwyczaj pozostaną nietknięte, czasami nawet w krańcowych przypadkach. Np. jeśli dla pewnego powodu system końcowy bazy danych jest zmieniony (powiedzmy, że menadżer decyduje o użyciu Oracle zamiast SQL Server), tylko musimy uaktualnić poziom danych. Istniejący poziom biznesu powinen pracować tak samo z nową bazą danych.

 

 

Dlaczego nie więcej poziomów?

 

 

Trzypoziomowa architektura jest najbardziej popularna wśród architektur n-poziomów (n-Tier Architecture), Odnosi się to do dzielenia rozwiązania na wiele (n) logicznych poziomów. W skomplikowanych projektach czasami to ma sens podzielić warstwę biznesu na więcej niż jedną warstwę, w ten sposób dającą wynik w architekturze z więcej niż trzema warstwami.

 

Jednak dla tej witryny web to lepiej pozostać przy trzech poziomach, co oferuje większość korzyści.

 

Dwupoziomowa architektura zw. architekturą klient-serwer jest odpowiednia dla mniej skomplikowanych projektów. Wymaga mniej czasu, ale potem taka aplikacja jest trudniejsza w utrzymaniu i rozszerzaniu.

 

Teraz utworzymy podstawy poziomu prezentacji i poziomu danych przez stworzenie pierwszej strony tej witryny i część końcową, czyli bazę danych.

 

 

Technologie i narzędzia

 

 

Tutaj używamy

 

ASP.NET 2.0 (Active Server Pages .NET 2.0) i C#.

 

Narzędzia: Visual Web Developer 2005 Express Edition i SQL Server 2005 Express Edition.

 

To jest to samo, co:

 

PHP 5

 

MySQL

 

 

Używanie ASP.NET 2.0

 

 

ASP.NET 2.0 jest do budowania dynamicznych, interaktywnych zawartości web. Konkurencją jest PHP (Hypertext Preprocessor), JSP (JavaServer Pages), ColdFusion, a nawet przestarzały ASP 3.0 and CGI (Common Gateway Interface).

 

Wspólną ich cechą jest to, że strony napisane z tymi technologiami są złożone z podstawowego HTML, który kreśli statyczną część strony (szablon) i kod, który generuje tę dynamiczną część

 

 

Web Clients i Web Servers

 

 

 

Figure 2-4. Web server processing client requests

 

 

Po prośbie strona jest najpierw przetwarzana na serwerze zanim jest zwracana do klienta (dlatego ASP.NET i inne wymienione technologie są zw. technologiami po stronie serwera). Kiedy taka strona jest proszona, jej podległy kod jest najpierw wykonywany na serwerze. Potem ostateczna strona jest składana i wynikowy HTML jest zwracany do przeglądarki gościa.

 

Zwrócony HTML może opcjonalnie zawierać kod skrypt (JavaScript, VBScript) po stronie klienta, który jest bezpośrednio interpretowany przez przegladarkę. Innymi technologiami po stronie klienta są Macromedia Flash i apletyJava, ale one są nieco inne, bo przeglądarka web nie parsuje ich–Flash wymaga specjalnego plug-inu a aplety Javy wymagają JVM. Internet Explorer też wspiera ActiveX controls i .NET assemblies.

 

 

Kod za stroną

 

 

ASP.NET zachęcał programistów do trzymania kodu strony web oddzielnie od HTML strony. Trzymając kod dający stronie życie w oddzielnym pliku od HTML było ważnym ulepszeniem nad innymi technologiami, które mieszały kod i HTML w tym samym pliku, co było trudne w utrzymaniu i w modyfikacji.

 

ASP.NET 2.0 modelu code-behind, gdzie Visual Studio NET generuje od razu dwa oddzielne pliki dla Web Form: układ HTML umieszczany w pliku .ASPX i kod umieszczany w pliku typu code-behind.

 

Ponieważ ASP.NET pozwalało programiście pisać kod w wybranym języku programowania, plik z kodem musiał mieć odpowiednie rozszerzenie do danego języka.

 

 

nazwa_pliku.ASPX.CS

 

nazwa_pliku.ASPX.VB

 

 

Mamy więc dwa pliki:

 

 

plik HTM.aspx

 

plik kodu.aspx.cs lub plik kodu.aspx.vb

 

 

Cechy ASP.NET:

 

– Kod po stronie serwera może być napisany w wybranym języku .NET. Domyślnie możemy wybrać z C#, VB .NET i J#, ale cała struktura jest przeznaczona do wsparcia dodatkowych języków. Te języki są silne i OOP.

 

– Kod stron ASP.NET jest w pełni kompilowany i wykonywany po stronie serwera–to jest inne niż interpretowanie linia za linią– co daje w wyniku optymalne wykonanie i oferuje możliwość wykrycia wielu błędów w czasie kompilacji zamiast w czasie uruchomienia.

 

– Koncept plików code-behind pomaga oddzielić część wizualną strony od logic stojącego za tym po stronie serwera. To jest korzyść w porównaniu z innymi technologiami, gdzie zarówno HTML i kod po stronie serwera jest w tym samym pliku (często dając tzw. “spaghetti code”).

 

– Visual Web Developer 2005 jest dobrym edytorem.

 

 

ASP.NET Web Forms, Web User Controls i Master Pages

 

 

ASP.NET web sites są rozwijane wokół ASP.NET Web Forms. ASP.NET Web Forms mają rozszerzenia .aspx i są standardowym sposobem do dawania funkcjonalności web dla klientów.

 

Prośba do zasobu ASPX taka jak

 

http://web.cristiandarie.ro/BalloonShop/default.aspx

 

daje w wyniku plik default.aspx wykonywany na serwerze (razem z plikiem code-behind) i te wyniki są składane jako kompletna strona HTML, która jest przysyłana do klienta. Zazwyczaj plik .aspx ma skojarzony plik code-behind (.aspx.cs lub .aspx.vb), który jest też traktowany jako część Web Form.

 

 

Web Forms– ASP.NET page framework, która składa się z programowalnych stron Web (zw. stronami Web Forms), które zawierają kontrole serwera (Server Controls) do wielokrotnego użytku.

 

 

Web User Controls i Master Pages są podobne do Web Forms w tym, że one są też złożone z HTML i kodu (one też wspierają model code-behind), ale one nie mogą być bezpośrednio dostępne przez klientów. Zamiast tego one są używane do składania zawartości Web Forms.

 

 

Web User Controls są plikami z rozszerzeniem .ascx, które mogą być zawarte w Web Forms, z rodzicem Web Form stającym się kontenerem tej kontroli. Web User Controls pozwalają nam łatwo ponownie używać kawałki funkcjonalności w wielu Web Forms.

 

 

Master Pages są nową cechą ASP.NET 2.0. Master Page jest szablonem, który może być stosowany do wielu Web Forms w witrynie dla zapewnienia zwięzłego wyglądu i funkcjonalności przez różne strony danej witryny. Uaktualnienie Master Page ma natychmiastowy efekt na każdej Web Form zbudowanej na tej Master Page.

 

 

Web User Controls, Web Server Controls i HTML Server Controls

 

 

Trzeba spojrzeć na Web User Controls z innej perspektywy. Web User Controls są konkretntym typem kontroli po stronie serwera. Odnoszą się one ogólnie do trzech rodzajów kontroli: Web User Controls, Web Server Controls i HTML Server Controls. Wszystkie te rodzaje kontroli mogą być użyte do ponownego użycia kawałków funkcjonalności w Web Forms.

 

Web User Controls są plikami z rozszerzeniem .ascx, które ma strukturę podobną do struktury Web Forms, ale one nie mogą być proszone bezpośrednio przez kliencką przeglądarkę web, natomiast one są przeznaczone do zawarcia w Web Forms lub innych Web User Controls.

 

Web Server Controls są kompilowanymi klasami .NET, które, kiedy wykonane, generują dane wyjściowe HTML (ostatecznie zawierając skrypt po stronie klienta). Możemy użyć ich w Web Forms lub w Web User Controls..NET Framework dostarczany jest z wielką liczbą Web Server Controls (z których wiele jest nowa w wersji 2.0), w tym proste kontrole takie jak Label, TextBox lub Button i bardziej skomplikowane kontrole takie jak walidacja kontroli, kontrola danych, sławna kontrola GridView (która ma zastąpić starą DataGrid) itd. Web Server Controls są silne, ale one są bardziej skomplikowane dla kodowania, bo cała ich funkcjonalność musi być implementowana ręcznie. Między innymi cechami możemy programistycznie deklarować i mieć dostęp do ich właściwości, czynić te właściwości dostępnymi przez projektanta Visual Web Developer i dodawać te kontrole do skrzynki z narzędzami (toolbox) takiej jak aplikacje Windows Forms lub stare programy VB6.

 

HTML Server Controls pozwalają nam na programistyczny dostęp do elementów HTML strony z kodu (takiego jak plik code-behind).

 

Przekształcamy kontrolę HTML na HTML Server Control przez dodanie do tego atrybutu:

 

runat=”server”

 

Większość HTML Server Controls jest dublowana przez Web Server Controls (takie jak etykiety, guziki itd.). Dla zwięzłości pozostaniemy przez większość czasu Web Server Controls, ale będziemy musieli używać w pewnych przypadkach HTML Server Controls.

 

Dla projektu BalloonShop będziemy używali wszystkich rodzajów kontroli i stworzymy wiele Web User Controls.

 

Ponieważ możemy rozwijać niezależnie Web User Controls głównej witryny web i potem włączamy je, kiedy są gotowe, mając strukturę witryny opartą na Web User Controls, dostarczamy doskonałego poziomu elastyczności i ponownej używalności.

 

 

ASP.NET i architektura trzypoziomowa

 

 

Kolekcja Web Forms, Web User Controls i Master Pages formuje poziom prezentacji danej aplikacji. One są częścią, która tworzy kod HTML załadowany przez przeglądarkę gościa. Logic UI jest przechowywany w plikach code-behind dla Web Forms, Web User Controls i Master Pages. Chociaż nie musimy używać plików code-behind z ASP.NET (możemy mieszać kod i HTML jak to robiliśmy z ASP), będziemy jednak używali tylko modelu code-behind dla logic poziomu prezentacji.

 

W kontekście aplikacji trzypoziomowej ten logic w poziomie prezentacji zazwyczaj odnosi się do różnych handlerów zdarzenia takich jak Page_Load i someButton_Click. Te handlery zdarzeń powinny wywoływać metody poziomu biznesu, aby ich praca była wykonana (i nigdy nie wywołujemy poziomu danych bezpośrednio).

 

 

Używanie C# i VB .NET

 

 

C# i VB .NET są językami, które mogą być użyte do kodowania plików code-behind Web Forms. Używamy C#, ale można też VB. W przeciwieństwie do poprzedniej wersji (VB6), VB .NET jest w pełni OOP i korzysta z cech dostarczanych przez .NET Framework.

 

ASP.NET 2.0 nawet pozwala zapisać kod do różnych elementów w projekcie w różnych językach, ale nie będziemy tego tu używać. Oddzielne projekty napisane w różnych językach .NET mogą dowolnie interoperować tak długo, jak idą za podstawowymi zasadami.

 

Nie możemy nadużywać cechy, gdzie używamy wielu języków w jednym projekcie, jeśli mamy wybór. Bycie zwięzłym jest ważniejsze niż bawienie się z różnorodnością, jeśli nie chcemy mieć problemów.

 

Poza używaniem C# dla plików code-behind będziemy używali tego samego języka dla kodowania klas środkowego poziomu. Stworzymy te pierwsze klasy potem, przy budowaniu katalogu produktu i dowiemy się więcej szczegółów, w tym wiele nowych cech, które są z .NET 2.0.

 

Visual Studio 2005 i Visual Web Developer 2005 Express Edition jest jak dodtąd najsilniejszym narzędziem, którym rozwijamy aplikacje .NET.

 

Visual Studio jest kompletnym programistycznym środowiskiem zdolnym do pracy z wieloma typami projektów i plików, w tym projekty Windows i Web Forms, ustawienie i rozwój projektów i wiele innych.

 

Visual Studio też może być użyty jako interfejs do bazy danych dla stworzenia tablic i przechowywanych procedur, implementowania relacyjnej tablicy itd.

 

Visual Web Developer 2005 Express Edition jest darmową wersją Visual Studio 2005, skupioną na rozwoju Web Applications z ASP.NET 2.0. Ponieważ ten kod może być zbudowany z jakichkolwiek z tych produków, będziemy zamiennie stosować Visual Web Developer i Visual Studio.

 

Znaczącą nową cechą w Visual Studio .NET 2005 i Visual Web Developer 2005 jest obecność zintegrowanego web serwera, który pozwala nam wykonać nasze Web Applications na ASP.NET, nawet gdy nie mamy IIS (Internet Information Services) zainstalowanego na PC. To są dobre wiadomości dla XP Home Edition, bo nie możemy zainstalować tu IIS.

 

Używamy Visual Web Developer 2005 Express Edition dla napisania projektu BalloonShop, jest ważne, aby wiedzieć, że nie musimy. Kompilatory ASP.NET i C# i VB .NET są dostępne w .NET Framework SDK (Software Developers Kit) i możemy prosty edytor Notepad, aby stworzyć każdą stronę web.

 

Visual Studio 2005 i Visual Web Developer 2005 ma wiele cech.

 

 

Używanie SQL Server 2005

 

 

Razem z .NET Framework 2.0 i Visual Studio 2005, Microsoft też stworzył nową wersję Relational Database Management Systems (RDBMS)—SQL Server 2005.

 

To skomplikowane software służy do przechowywania, zarządzania i odzyskiwania danych szybko i pewnie. Będziemy używać SQL Server dla przechowywania wszystkich informacji dotyczących naszej strony web przez logic aplikacji. Wszystkie dane dotyczące produktów, działów, użytkowników, wózków itd. są przechwywane w bazie danych i zarządzane przez SQL Server.

 

Wersja light SQL Server 2005 zw. SQL Server 2005 Express Edition, jest darmowa.

 

SQL Server 2005 Express Edition nie ma żadnych narzędzi graficznego zarządzania. Jednak jest narzędzie zw. SQL Server Express Manager też darmowe.

 

 

SQL Server i architektura trzypoziomowa

 

 

SQL Server jest związany z poziomem danych. Przechowuje dane, logic w formie przechowywanych procedur, utrzymujących relacje tablic, zapewniając, że zasady integralności danych są zachowane itd.

 

Możemy komunikować się z SQL Server przez język zw. T-SQL (Transact-SQL), który jest dialektem SQL rozpoznawanym przez SQL Server. SQL, Structured Query Language, jest językiem używanym do interakcji z bazą danych. SQL jest używany do transmisji instrukcji do bazy danych takich jak np. Wyślij mi ostatnie dziesięć zamówień lub Skasuj produkt #123. Chociaż składamy instrukcje T-SQL w naszym kodzie C# i potem przedkładamy je do wykonania, to jest zła praktyka, bo to jest przeciw bezpieczeństwu, zwięzłości i wykonaniu. Tutaj przechowujemy cały logic poziomu danych używając przechowywanych procedur. Historycznie przechowywane procedury były programami przechowywanymi wewnętrznie w bazie danych i zapisywane w T-SQL. To jest ciągle prawdziwe z SQL Server 2005, co też pokazuje zarządzanymi procedurami przechowywania, które mogą być zapisane w języku .NET takim jak C# i VB.NET i są w rezultacie kompilowane zamiast interpretowania.

 

Zapisanie przechowywanych procedur w C# też zw. zarządzanymi proceduramiprzechowywania. Jednak zarządzane procedury przechowywania są bardzo silne. Typowo to ma sens używać zarządzanych procedur przechowywania, kiedy musimy wykonać skomplikowane operacje matematyczne lub skomplikowany logic, który może być łatwo implementowany z T-SQL. Jednak nauczenie się jak robić te zadania we właściwy sposób wymaga wiele badań, które są poza tym tematem. Logic danych nie usprawiedliwia dodawania jakichkolwiek zarządzanych procedur przechowywania i w rezultacie nie zobaczymy żadnej z nich. Nauczenie się jak programować zarządzane procedury przechowywania zajmuje czas i możemy chcieć sprawdzić to w innych książkach o pisaniu zarządzanego kodu pod SQL Server.

 

Przechowywane procedury są przechowywane wewnętrznie w bazie danych i mogą być wywoływane z zewnętrznych programów. W naszej architekturze przechowywane procedury będą wywoływane z poziomu biznesu. Te przechowywane procedury z kolei manipulują lub mają dostęp do przechowywanych danych, otrzymują wyniki i zwracają je do poziomu biznesu (lub wykonują potrzebne operacje).

 

Figure 2-5 shows the technologies associated with every tier in the three-tier architecture.

 

 

 

Figure 2-5. Using Microsoft technologies and the three-tier architecture

 

 

SQL Server zawiera poziom danych aplikacji (przechowywane procedury, które zawierają logic dla dostępu i manipulacji danymi) i też bieżące przechowywane dane.

 

 

Idąc za standardami kodowania (Coding Standards)

 

 

Chociaż standardy kodowania i nazywania mogą wydawać się tak ważne na początku, one ostatecznie nie powinny być pominięte. Nie idąc za zestawem reguł naszego kodu prawie zawsze mamy w wyniku kod, który jest trudny do odczytu, zrozumienia i utrzymania. Z drugiej strony kiedy idziemy za zwięzłym sposobem kodowania, możemy powiedzieć, że nasz kod jest już w połowie udokumentowany, co jest ważnym wkładem w utrzymanie danego projektu, zwłaszcza kiedy wielu ludzi pracuje nad tym samym kodem w tym samym czasie.

 

Pewne firmy mają swoje własne polityki dotyczące standardów kodowania i nazewnictwa, gdy w innych przypadkach mamy elastyczność w użyciu naszych preferencji. W każdym przypadku zasadą jest bycie konsekwentnym w naszym kodzie.

 

Konwencje nazewnictwa odnoszą się do wielu elementów w projekcie, po prostu ponieważ prawie wszystkie z elementów projektu mają nazwy–sam projekt, przestrzenie nazw, Web Forms, Web User Controls, instancje Web User Controls i elementy interfejsu, klasy, zmienne, metody, parametry metod, tablice bazy danych, kolumny baz danych, przechowywane procedury itd.

 

Tutaj mamy konwencje nazewnictwa Microsoftu. Teraz nazwa zmiennej powinna wyrażać co obiektem robi, a nie jego typ danych.

 

 

Tworzenie projektu Visual Web Developer

 

 

Używamy Visual Web Developer 2005 Express Edition. To pozwala nam stworzyć wszystkie rodzaje projektów, w tym Web Site projects (wcześniej znane jako Web Application projects). Inną potrzebną rzeczą jest SQL Server Express Edition, co będzie trzymać nasze dane dla witryny web.

 

Otwieramy Visual Web Developer i tworzemy nowy projekt ASP.NET Web Site. Przy poprzednich wersjach Visual Studio potrzebujemy zainstalowanego IIS z powodu zaintegrowanego serwera web Visual Studio .NET 2005 (zw. Cassini), możemy uruchomić ASP.NET Web Application z jakiegokolwiek fizycznego foldera na naszym dysku. W rezultacie tworząc projekt witryny Web, możemy określić przeznaczenie albo lokację web (http://localhost/BalloonShop) lub fizyczny folder na naszym dysku (C:\BalloonShop).

 

Jeśli mamy wybór, zazwyczaj preferowanym rozwiązaniem jest ciągle IIS, bo ma lepsze wykonanie i gwarantuje, że strony będą wyświetlone tak samo jak nasz projekt zakłada. Cassini (zintegrowany web server) doskonale symuluje IIS.

 

 

Tworzenie projektu BalloonShop

 

 

1. Startujemy Visual Web Developer 2005 Express Edition, wybieramy FileNewWeb Site. W otwartym oknie dialogowym wybieramy ASP.NET Web Site z panelu Templates, i Visual C# dla Language.

 

2. W pierwszej Location, możemy wybrać File System, HTTP i FTP, co ustala jak nasz projekt jest wykonywany. Jeśli wybierzemy projekt na File System, musimy wybrać fizyczną lokację na naszym dysku (system plików), taką jak C:\BalloonShop\. W tym wypadku Web Application jest wykonywana używając zintegrowanego web serwera Cassini w Visual Web Developer.

 

Jeśli wybierzemy lokację HTTP (http://localhost/BalloonShop), Web Application będzie wykonana przez IIS. Trzeba mieć zainstalowany IIS. Tworzymy projekt na lokacji http://localhost/BalloonShop, as shown in Figure 2-6.

 

Figure 2-6. Creating the Visual Studio .NET project

 

 

 

Kiedy tworzymy projekt na lokacji HTTP z lokalnym serwerem IIS, ten projekt jest fizycznie tworzony domyślnie w fodlerze \InetPub\wwwroot. Jeśli inny folder, to wybieramy Control PanelAdministrative Tools dla stworzenia wirtualnego folderu wskazującego na ten fizyczny folder zanim stworzymy Web Application z Visual Web Developer.

 

3. Klikamy OK. Visual Studio teraz tworzy nowy projekt w folderze BalloonShop, którego określimy. W nowym projekcie nowy Web Form zw. Default.aspx jest tworzony domyślnie jak jest w Figure 2-7.

 

Figure 2-7. The BalloonShop project in Visual Web Developer 2005 Express Edition

 

 

 

4. Wykonujemy projekt w trybie debugowania przez naciśnięcie F5. Teraz Visual Web Developer będzie narzekał (as shown in Figure 2-8), że to nie może debugować projektu tak długo jak debugowanie nie jest włączone w web.config (teraz plik web.config nawet nie istnieje). Klikamy OK dla zezwolenia Visual Studio na włączenie trybu debugowania.

 

Figure 2-8. Debugging must be enabled in web.config

 

 

5. Kiedy wykonujemy nowy i pusty projekt Internet Explorer powinien się pojawić. Zamknięcie okna też zatrzyma projekt od wykonania (symbole Break and Stop Debugging znikną z pasku narzędzi Visual Web Developer i ten projekt stanie się znowu w pełni edytowalny).

 

Kiedy mamy wykonanie projektu, witryna web jest ładowana do naszej domyślnej przegladarki systemowej. Dla celów debugowania naszego kodu polecamy konfigurację Visual Web Developer dla użycia z Internet Explorer, bo to działa lepiej niż Mozilla Firefox.

 

Visual Web Developer wie, kiedy zamykamy IE i automatycznie zatrzymuje projekt z trybu debugowania, więc możemy kontynuować programowanie normalnie, a z innymi przeglądarkami musimy zatrzymać debugowanie ręcznie Stop Debugging (klikamy Stop

 

lub naciskamy Shift+F5).

 

 

Działanie Visual Web Developer Project

 

 

Nie potrzebujemy wirtualnego katalogu IIS lub wcale IIS, aby uruchomić Web Application, bo możemy stworzyć projekt ASP.NET Web Site w fizycznej lokacji na naszym dysku. Kiedy jest IIS, wskazujemy na adres jak:

 

http://localhost:5392/BalloonShop/Default.aspx

 

który odpowiada lokacji zintegrowanego web serwera. W tym momencie nasz projekt zawiera trzy pliki:

 

Default.aspx jest naszym Web Form, czyli statyczny HTML.

 

Default.aspx.cs jest plikiem code-behind dla Web Form, czyli kod dynamiczny.

 

web.config jest plikiem konfiguracyjnym projektu.

 

 

Implementacja szkieletu witryny (Site Skeleton)

 

 

Wizualny projekt naszej witryny jest zazwyczaj po dyskusji z klientem i w porozumieniu z profesjonalnym projektantem web. Alternatywnie możemy kupić szablon witryny web z firm.

 

 

All pages in BalloonShop, including the first page, will have the structure shown in Figure 2-9. Do tego dodamy więcej komponentów jak okienko logowania lub wózek kupowania.

 

 

Figure 2-9. Structure of web pages in BalloonShop

 

 

Implementujemy tę strukturę przez stworzenie:

 

 

– Master Page zawierającą generalną strukturę wszystkich stron witryny web, jak pokazano w Figure 2-9

 

– Wiele Web Forms, które używają Master Page dla implementacji różnych lokacji tej witryny web, takich jak strona główna, strony działów, strona wyszukjąca wyniki itd.

 

– Wiele Web User Controls dla uproszczenia ponownego użycia określonych kawałków funkcjonalności (takich jak lista działów, lista kategorii, okienko wyszukiwania, nagłówek itd.)

 

Figure 2-10 shows a few of the Web User Controls you’ll create while developing BalloonShop.

 

 

Figure 2-10. Using Web User Controls to generate content

 

 

Używanie Web User Controls dla implementacji różnych kawałków funkcjonalności ma korzyści. Logicznie oddzielając różne, niezwiązane kawałki funkcjonalności jeden od drugiego daje nam elastyczność do modyfikacji ich niezależnie i nawet ponowne użycie ich w innych stronach bez przymusu napisania kodu HTML i wsparcie znowu pliku code-behind. Łatwo rozszerzamy tę funkcjonalność lub zmieniamy miejsce cechy zaimplementowanej jak kontrola użytkownika w rodzicielskiej stronie web, zmiana lokacji Web User Control jest niczym więcej, jak skomplikowanym i długim procesem.

 

Napiszemy Master Page tej witryny, Web Form dla tej pierwszej strony, która używa Master Page i Header Web User Control. Stworzymy bazę danych BalloonShop, która będzie podstawą projektu.

 

 

Building the First Page

 

 

Mamy pojedynczą Web Form w witrynie, Default.aspx, którą stworzy automatycznie Visual Web Developer, kiedy stworzymy projekt. Domyślnie Visual Web Developer nie wygeneruje Master Page dla nas, więc zrobimy to niżej:

 

 

Tworzenie strony głównej Web

 

 

1. Klikamy WebsiteAdd New Item (lub Ctrl+Shift+A). W oknie dialogowym wybieramy Master Page z zainstalowanej listy Visual Studio Installed Templates.

 

2. WybieramyVisual C# dla języka, sprawdzamy kod Place w oddzielnym pliku i zmieniamy nazwę strony na BalloonShop.master (domyślna nazwa MasterPage.master nie jest dobra). Okienko dialogowe Add New Item teraz wyglada jak Figure 2-11.

 

 

Figure 2-11. Adding a new Master Page to the project

 

 

3. Klikamy Add dla dodania nowej Master Page dla projektu. Nowa Master Page będzie otwarta z pewnym domyślnym kodem w Source View. Jeśli przełączymy na Design View, zobaczymy obiekt ContentPlaceHolder, który to zawiera. Podczas gdy Source View uaktualnia swój kod jak ten:

 

<%@ Master Language=”C#” AutoEventWireup=”true”

 

CodeFile=”BalloonShop.master.cs” Inherits=”BalloonShop” %>

 

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.1//EN”

 

http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd”&gt;

 

<html xmlns=”http://www.w3.org/1999/xhtml”&gt;

 

<head runat=”server”>

 

<title>BalloonShop</title>

 

</head>

 

<body>

 

<form id=”Form1″ runat=”server”>

 

<table cellspacing=”0″ cellpadding=”0″ width=”770″ border=”0″>

 

<tr>

 

<td width=”220″ valign=”top”>

 

List of Departments

 

<br />

 

List of Categories

 

<br />

 

</td>

 

<td valign=”top”>

 

Header

 

<asp:ContentPlaceHolder ID=”contentPlaceHolder” runat=”server”>

 

</asp:ContentPlaceHolder>

 

</td>

 

</tr>

 

</table>

 

</form>

 

</body>

 

</html>

 

4. teraz znowu przełączamy na Design View; powinniśmy zobaczyć jak w Figure 2-12. Jeśli nie zmieniliśmy domyślnego zachowania Visual Web Developer, zobaczymy, że obiekt ContentPlaceHolder jest oznaczony znakiem małej zielonej strzałki. To wskazuje, że ta kontrola jest oznaczona do wykonania po stronie serwera (na serwerze). Wszystkie kontrole po stronie serwera (w tym Labels, TextBoxes itd.) na tej stronie będą oznaczone tą samą zieloną strzałką. Jesli spojrzymy na kod HTML dla ContentPlaceHolder, zobaczymy zdanie runat=”server”:

 

<asp:contentplaceholder id=”contentPlaceHolder” runat=”server”>

 

</asp:contentplaceholder>

 

 

Figure 2-12. Your New Master Page in Design View

 

 

Master Pages nie są przeznaczone dla bezpośredniego dostępu przez klientów, ale aby być zaimplementowanymi w Web Forms. Używamy Master Page, które stworzyliśmy dla ustalenia szablonu dla Default.aspx Web Form. Ponieważ strona Default.aspx, którą stworzyło Visual Web Developer dla nas nie jest dla użycia z Master Pages (zawiera ona kod, który powinien być dziedziczony z Master Page), jest łatwiej skasować i ponownie stworzyć ten plik.

 

5. Klikamy prawym przyciskiem Default.aspx w Solution Explorer i wybieramy Delate. Potwierdzamy kasowanie.

 

6. Prawym przyciskiem klikamy root projektu w Solution Explorer i wybieramy Add New Item. Wybieramy szablon Web Form, zostawiamy domyślną nazwę jako Default.aspx, upewniamy się, że zarówno są zaznaczone opcje Place codein separate file i

 

Select Master Page, weryfikujemy czy językiem jest Visual C# i klikamy Add. Kiedy prosimy o plik Master Page, wybieramy BalloonShop.master i klikamy OK. Nasza nowa strona będzie stworzona tylko z kilkoma liniami kodu, cała reszta będzie dziedziczona z Master Page:

 

<%@ Page Language=”C#” MasterPageFile=”~/BalloonShop.master”

 

AutoEventWireup=”true” CodeFile=”Default.aspx.cs” Inherits=”_Default”

 

Title=”Untitled Page” %>

 

<asp:Content ID=”Content1″ ContentPlaceHolderID=”contentPlaceHolder”

 

Runat=”Server”>

 

</asp:Content>

 

Kiedy przełączamy na Design View, Default.aspx będzie wyglądał jak Figure 2-13.

 

 

Figure 2-13. Default.aspx in Design View

 

 

7. Zmieniamy tytuł strony z “Untitled Page” na “Welcome to BalloonShop!” przez albo użycie okna Properties w Design View (see Figure 2-14) albo przez edytowanie kodu w Source View jak to:

 

<%@ Page Language=”C#” MasterPageFile=”~/BalloonShop.master”

 

AutoEventWireup=”true” CodeFile=”Default.aspx.cs” Inherits=”_Default”

 

Title=”Welcome to BalloonShop!” %>

 

 

Figure 2-14. Changing the form name using the Properties window

 

8. Naciskamy F5 dla wykonania tego projektu. Powinnismy dostać stronę podobną do tej w Figure 2-15.

 

 

Figure 2-15. Default.aspx in action

 

Trzeba zamknąć okno przeglądarki lub recznie zatryzmać projekt zanim użyjemy okna Designer dla edycji naszych form w pełnej sile znowu.

 

 

How It Works: The Main Web Page

 

 

Jak mamy szkilete pierwszej strony BalloonShop page w miejscu. Praca z Master Pages zaoszczędzi nam wiele kłopotów potem, kiedy rozszerzamy witrynę.

 

Master Page ustala rozkład stron, które to implementują i te strony mają dowolność w uaktualnianiu zawartości elementów ContentPlaceHolder. W naszym przypadku nagłówek, lista działów i lisat kategorii są standardowymi elementami , które pojawiają się na każdej stronie web. Dlatego zawieramy te elementy bezpośrednio w Master Page, i one nie są do edytowania, kiedy projektujemy Default.aspx. Bieżąca zawartość każdej sekcji witryny web (taka jak strona wyników wyszukiwania, strony działu i kategorii itd.) będzie generowane przez oddzielne Web Forms, które będą rozrózniane przez kod w obiekcie ContentPlaceHolder.

 

Master Page może zawierać wiecej niż jeden obiekt ContentPlaceHolder. Lista działów i lista kategorii będzie implementowana jako Web User Controls, które generują ich dane wyjściowe oparte na danych odczytywanych z bazy danych.

 

 

Adding the Header to the Main Page

 

 

Kontrola nagłówka będzie zapełniać górną prawą część strony głównej i będzie wyglądać jak Figure 2-16.

 

 

Figure 2-16. The BalloonShop logo

 

Aby nasz folder witryny był porządny, tworzymy oddzielny folder dla wszystkich kontroli użytkownika. Trzymanie tego w centralnej lokacji jest pomocne, zwł. kiedy projekt rozrasta się i zawiera wiele plików.

 

 

Creating the Header Web User Control

 

Tworzenie Web User Control i dodanie doMaster Page:

 

 

1. Ściagmy kod dla tej książki z obszaru Source Code http://www.apress.com, rozpakowujemy go na dysku i kopiujemy folder ImageFolders\Images do katalogu naszego projektu (który będzie \Inetpub\wwwroot\BalloonShop\, jeśli uzylibyśmy domyślnych opcji, kiedy tworzymy projekt). Folder Images zawiera m.in. plik zw. BalloonShopLogo.png, który jest logiem witryny web. teraz jesli zapiszemy, zamkniemy i przeładujemy nasze rozwiazanie, fodler Images pokaże się w Solution Explorer.

 

2. Upewniamy się, że projekt nie jest w działaniu (jesli tak, edycyjne mozliwości są ograniczone) i to okno Solution Explorer jest widoczne (jesli nie jest, wybieramy View ➤ Solution Explorer lub uzywamy Ctrl+Alt+L). Kliknięcie prawym przyciskiem myszy roota wpisu i wybranie Add Folder ➤ Regular Folder.

 

3. Wprowadzamy UserControls jko nazwę nowego foldera, jak pokazano w Figure 2-

 

 

Figure 2-17. Adding a new folder to the BalloonShop project

 

4. Tworzymy kontrolę użytkownika Header.ascx w folderze UserControls. Kliknięcie prawym przyciskiem UserControls w Solution Explorer i kliknięcie Add New Item. Pojawi się forma, gdzie wybieramy szablon Web User Control i zmieniamy domyślną nazwę na

 

Header.ascx. Pozostawiamy inne opcje nietknięte i klikamy Add.

 

 

Figure 2-18. Creating the Header.ascx Web User Control

 

 

5. Automatycznie Header Web User Control otwiera w Source View. Modyfikujemy kod HTML tak:

 

<%@ Control Language=”C#” AutoEventWireup=”true” CodeFile=”Header.ascx.cs”

 

Inherits=”Header” %>

 

<p align=”center”>

 

<a href=”Default.aspx”>

 

<img src=”Images/BalloonShopLogo.png” border=”0″>

 

</a>

 

</p>

 

Jesli przełączymy kontrolę na Design View, nie zobaczymy obrazka, bo ścieżka względna do folderu Images wskazuje na różną ścieżkę absolutną w czasie projektowania niż w czasie uruchomienia. W czasie uruchomienia ta kontrola jest zawarta i działa z BalloonShop.master, nie z bieżącej lokacji (folder UserControls).

 

6. Otwieramy BalloonShop.master w Design View, przeciągamy Header.ascx z Solution Explorer, opuszczamy to blisko tekstu „Header” i potem kasujemy tekst „header” z komórki. Design view z BalloonShop.master powinien wyglądać jak w Figure 2-19.

 

 

Figure 2-19. Adding Header.ascx to the Master Page

 

7. Klikamy Debug ➤ Start (F5) dla wykonania projektu. Strona web bedzie wyglądać jak w Figure 2-20.

 

 

Figure 2-20. BalloonShop in action

 

 

How It Works: The Header Web User Control

 

 

Nasza witryna web na działający header. Ostatnim krokiem jest stworzenie bazy danych BalloonShop, więc wszystko będzie ustawione dla stworzenia naszego katalogu produktu.

 

Web User Control, którego stworzyliśmy, jest zawarty w BalloonShop.master Master Page, więc to odnosi się do wszystkich stron, które używają tej Master Page, takiej jak Default.aspx.

 

Mając napisany ten kawałek HTML jako oddzielna kontrola, uczyni nasze życie nieco łatwiejszym, kiedy musimy ponownie użyć tego nagłówka w innych częściach witryny. Jeśli zdecydujemy się zmienić logo, robimy to w jednym miejscu (Header.ascx control) będzie miało wpływ na wszystkie strony, które używają tego.

 

Tym razem stworzyliśmy kontrol przez bezpośrednią edycję źródła HTML, ale jest zawsze możliwe użyć Design View i stworzyć kontrol wizualnie. Tablica HTML z okna Toolbox w Visual Studio zawiera wszystkie podstawowe elementy HTML, w tym Image, który generuje element HTML img.

 

 

Tworzenie bazy danych SQL Server

 

 

Teraz tworzymy bazę danych SQL Server. SQL Server 2005 Express Edition, nie jest z SQL Server Management Studio (wcześniej znany jako Enterprise Manager). Jednak możemy też stworzyć bazy danych używajżc cech Visual Web Developer. Wszystkie te informacje, które muszą być przechowywane w witrynie, takie jak dane o produktach, klienci itp. będą przechowywane w bazie danych zw. BalloonShop.

 

 

Tworzenie nowej bazy danych SQL Server

 

 

Tworzymy bazę danych BalloonShop przy użyciu Visual Studio. Jednak używamy narzędzia, którego chcemy.

 

1. W naszym projekcie Visual Web Developer, upewniamy się, że okno Database Explorer jest otwarte. Jeśli nie jest, albo wybieramy View ➤ Database Explorer albo naciskamy Ctrl+Alt+S.

 

2. W Server Explorer, klikamy prawym klawiszem wpis Data Connections i wybieramy Create New SQL Server Database. W oknie, które się pojawia (see Figure 2-21), wprowadzamy nazwę instancji SQL Server, gdzie chcemy stworzyć bazę danych (możemy użyć (local) zamiast lokalnej nazwy komputera), informacje loginu i nazwa nowej bazy danych. Jeśli zainstalowaliśmy SQL Server Express używając domyślnych opcji, wtedy nasza nazwa serwera powinna być (local)\SqlExpress;w procesie instalacji dostajemy potrzebne dane dla połączenia z naszą bazą danych. Wprowadzamy BalloonShop dla nazwy bazy danych.

 

 

Figure 2-21. Creating a new SQL Server database using Visual Web Developer

 

Używając Windows Authentication, nasze lokalne konto Windows będzie użyte do logowania do SQL Server. Jeśli zainstalowlaiśmy sami SQL Server, będziemy mieli pełne przywileje do SQL Server i wszystko pójdzie jak trzeba; inaczej będziemy potrzebować upewnić się, że mamy administracyjne przywileje w instancji SQL Server. Z SQL Server Authentication, musimy dostarczyć nazwę uzytkownika i hasło, ale ten tryb autentykacji jest wyłączony domyślnie w SQL Server.

 

 

Baza danych SQL Server

 

 

Teraz stworzyliśmy nową bazę danych SQL Server. Okno Server Explorer w Visual Studio pozwoli nam kontrolować wiele szczegołów instancji SQL Server. Po stworzeniu bazy danych BalloonShop, pojawi się ona pod węzłem Data Connections w Server Explorer. Rozwinięcie tego węzła ujawni szeroki obszar funkcjonalności, do której możemy mieć dostęp bezpośrednio z Visual Web Developer (see Figure 2-22). Ponieważ ta baza danych, którą stworzyliśmy, jest pusta, jej podwęzły są też puste, ale zapełni się ją potem.

 

 

Figure 2-22. Accessing the BalloonShop database from the Database Explorer

 

 

Downloading the Code

 

 

Napisany przez nas kod jest w obszarze Source Code w witrynie Apress web na http://www.apress.com lub na stronie autora http://www.CristianDarie.ro.

 

 

 

 

.NET Tutorial for Beginners

 

 

Historia .NET

 

 

July 2000, Microsoft obwieścił nowy software development framework dla Windows zw. .NET w Professional Developer Conference (PDC). Microsoft March 2002 wypuścił ostetczną wersję .NET framework.

 

 

Smak .NET

 

 

To nie jest pojedyncza technologia, a cały zestaw technologii, które pracują razem dla rozwiązywania problemów.

 

I\ Jaki typ aplikacji rozwijamy?

 

.NET daje solidną podstwę dla rozwoju aplikacji internetowych i sieciowych, to jednak możemy tworzyć różne rodzaje aplikacji.

 

1. ASP.NET Web–zawierają dynamiczne dane napędzane przez aplikacje oparte na przeglądarce.

 

2. Windows Form–odnoszą się do tradycyjnych bogatych aplikacji klienta.

 

3. Console–tradycyjne aplikacjie DOS jak skrypty Batch.

 

4. Component Libraries–komponenty, które typowo enkapsulują pewne logic biznesowe.

 

5. Windows Custom Controls–Jak w tradycyjnych ActiveX controls, możemy rozwijać nasze własne windows controls.

 

6. Web Custom Controls–Kontrole dostosowane mogą być rozszerzone do aplikacji web, pozwalajac kodowi na wielokrotne użycie i modularyzację.

 

7. Web services–one są funkcjonlanością do wezwania przez web dostępną przez standardy przemysłowe jak HTTP, XML i SOAP.

 

8. Windows Services–aplikacje działające jako usługi w tle. Kiedy system bootuje, mogą być ustawiane do uruchomienia automatycznego.

 

Mamy tu prawie wszystkie rodzaje aplikacji, jakie są pod Windows.

 

 

II\ NET Framework SDK

 

 

NET ma kompletny Software Development Kit (SDK)–zw..NET Framework SDK–dostarcza klas, interfejsów i kompilatorów jezyków dla programowania. Ma też dobrą dokumentację i podręczniki Quick Start. Wystarczy .NET Framework i edytor tekstu dla programowania.

 

 

III\ Development Tools

 

 

Kiedy nasze aplikacje wymagają szybkiego dostarczenia dla naszych klientów i cech jak integracja z pewnymi wersjami kontroli software, wtedy prosty edytor nie wystarczy. Potrzebujemy Integrated Development Environment (IDE), które pzowala na Rapid Action Development (RAD). Nowe Visual Studio.NET jest takim IDE. VS.NET jest silnym i elastycznym IDE, które ma cechy:

 

– Drag and Drop design

 

– IntelliSense features

 

– Syntax highlighting and auto-syntax checking

 

– Excellent debugging tools

 

– Integration with version control software such as Visual Source Safe (VSS)

 

– Easy project management

 

 

Kiedy instalujemy Visual Studio.NET, .NET Framework jest automatycznie instalowana na maszynie.

 

 

IV\ Visual Studio.NET Editions

 

 

Visual Studio.NET ma różne edycje:

 

– Professional

 

– Enterprise Developer

 

– Enterprise Architect

 

 

Visual Studio .NET Professional edition offers a development tool for

 

creating various types of applications mentioned previously. Developers can

 

use Professional edition to build Internet and Develop applications quickly

 

and create solutions that span any device and integrate with any platform.

 

 

Visual Studio .NET Enterprise Developer (VSED) edition contains all the

 

features of Professional edition plus has additional capabilities for enterprise

 

development. The features include things such as a collaborative team

 

development, Third party tool integration for building XML Web services and

 

built-in project templates with architectural guidelines and spanning

 

comprehensive project life-cycle.

 

 

Visual Studio .NET Enterprise Architect (VSEA) edition contains all the

 

features of Visual Studio .NET Enterprise Developer edition and additionally

 

includes capabilities for designing, specifying, and communicating application

 

architecture and functionality. The additional features include Visual designer

 

for XML Web services, Unified Modeling Language (UML) support and

 

enterprise templates for development guidelines and policies.

 

 

Specyficzne dla języka:

 

– Visual Basic.NET Standard Edition

 

– Visual C# Standard Edition

 

– Visual C++ .NET Standard

 

Te edycje są dla początkujacych, bo mają podstawowe cechy.

 

V\ .NET Redistributable

 

 

Aby uruchomić aplikację rozwiniętą używając .NET Framework, maszyna musi mieć zainstalowane pewne pliki ‘runtime’. One są razem zw. .NET redistributable. To jest jak tradycyjne aplikacje Visual Basic wymagają zainstalowanego środowiska uruchomieniowego Visual Basic. .NET redistributable dostarcza redystrybutowanego instalatora, który ma CLR i komponenty Microsoft .NET Framework, które są potrzebne do uruchomienia. Jest dostępny jako samodzielny plik wykonywalny i może być zainstalowany ręcznie lub jako część uruchamianej aplikacji.

 

Jeśli mamy .NET Framework SDK, nie musimy oddzielnie instalować pakietu redystrybuowanego. Jest różnica między .NET Framework SDK i .NET redistributable w kategoriach dostarczanych narzędzi, dokumentacji i celu. .NET Framework SDK ma rozwijać, gdy .NET redistributable uruchamia aplikacje .NET.

 

 

VI\ .NET i mobile development

 

 

Dzisiaj mamy PDAs, mobile phones, Smartphones, handheld PCs and HTML pagers. Mają one ograniczenia w zasobach.

 

 

Urządzenia mobilne mogą być dzielone na dwie kategorie:

 

 

1) Które mają pewne zasoby po stronie klienta jak PDAs, Smartphones i Handheld PCs. One mogą uruchamiać samodzielne aplikacje z bogatym interfejsem użytkownika.

 

2) Które nie mają zasobów po stronie klienta takie jak mobile phones. One nie mogą uruchamiać bogatych i interaktywnego interfejsu użytkownika.

 

Microsoft rozwinął dwie technologie:

 

 

– Microsoft .NET Compact Framework (.NET CF)

 

– Microsoft Mobile Internet Toolkit (MMIT)

 

 

Microsoft .NET Compact Framework

 

 

.NET compact framework jest podzestawem całej .NET framework i celuje w mobile devices mające pewne zasoby po stronie klienta. Dostarcza wsparcia dla zarządzanego kodu i usług XML Web.

 

 

Microsoft tworzy rozszerzenia dla Visual Studio .NET zw. Smart Device Extensions, które pozwolą programistom Visual Studio .NET dla programowania .NET Compact Framework. Czyli programiści obeznani z Visual Studio.NET mogą programować dla mobile devices.

 

 

Microsoft Mobile Internet Toolkit

 

 

Microsoft Mobile Internet Toolkit (MMIT) jest przeznaczony do rozwijania aplikacji po stronie serwera dla mobile devices takich jak cell phones, PDAs i pagers. To jest inne niż .NET compact Framework w tym, że jest technologia po stronie serwera. To jest dobre dla urządzeń, które mogą uruchamiać aplikacje samodzielne.

 

MMIT w zasadzie używa ASP.NET jako technologii dostarczjącej znacznika dla szerokiego spektrum mobile devices. Każdy mobile device ma swój własne podległe standardy i znacznik. MMIT zestawia te szczegóły dla programisty i pozwala na ‘uniform code’ dla jakiegokolwiek docelowego urządzenia. Na podstawie tych zdolności urządzenia docelowego dane wyjściowe są dostarczane.

 

 

1.3 Cechy .NET

 

 

– .NET framework dostarcza bogatego zestawu funkcjonalności. To zawiera setki klas, które mają funkcjonalności gotowe do użycia w naszych aplikacjach.

 

– ASP.NET jest technologią dostępną na .NET dla rozwijania dynamicznych i napędzanych danymi aplikacji web. ASP.NET dostarcza modelu programowania napędzanego zdarzeniem (jak Visual Basic 6 ułatwia rozwój skomplikowanego interfejsu użytkownika) ze skomplikowanym interfejsem użytkownika. ASP.NET server controls dostarcza zaawansowanych elementów interfejsu użytkownika (jak kalendarz i siatkę)

 

– .NET dostarcza środowiska OOP. Obiekt jest matką wszystkiego. Języki jak Visual Basic.NET teraz wspierają cechy OO. Nawet pierwotne typy jak integer czy characters mogą być traktowane jako obiekty–nawet w językach takich jak C++, które nie są w pełni OO.

 

– Teraz bezpośrednio mamy cztery języki–Visual Basic.NET, C# (C-sharp), JScript.NET i Managed C++ (dialekt Visual C++). Ale inni sprzedawcy dodają swoje z kompilatorami (ponad dwadzieścia dzisiaj 20). Składnia języków jest inna, ale podstawowe możliwości każdego języka są podobne.

 

– .NET Compact Framework i Mobile Internet Toolkit są rozwiązaniem.

 

– Wyciekanie pamięci powoduje często fiasko aplikacji. .NET dba o zarządzanie pamięcią. Zbieracz śmieci uwalnia pamięć z obiektów co pewien czas.

 

– Przed wprowadzeniem .NET, COM było standardem dla rozwoju software z komponentów. Firmy zainwestowały dużo w rozwój komponentów COM i kontroli. Ciągle możemy używać komponentów COM i kontroli ActiveX pod .NET. To pozwala używać istniejące już aplikacje. .NET ciągle polega na COM+ dla cech jak zarządzanie transakcją i gromadzenie obiektów w pulę. To dostarcza wsparcia dla konfigurowania aplikacji COM+ wprost z kodu źródłowego. Nasza wiedza COM+ ciągle jest więc cenna.

 

– Przy komponentach COM konflikty DLL. Komponenty COM wymagają rejestracji w rejestrze SO. .NET kończy z tym, pozwalając aplikacjom używać ich własnej kopi zależnych DLLs. Nie wymagają też rejestracji w rejestrze SO.

 

– Silny udział w rynku. .NET jako jedyna platforma ma wbudowany XML w jądro SO. .NET korzysta z siły XML w każdy możliwy sposób. .NET dostarcza usług web XML, które są oparte na standardach HTTP, XML i SOAP.

 

– Konfiguracja jest robiona przez specjalne pliki mające specjalne słownictwo XML. Nie ma potrzeby ręcznego konfigurowania.

 

– Platforma Windows zapewnia bezpieczeństwo przez .NET. Cechy takie jak: bezpieczeństwo typu (type safety), bezpieczeństwo dostępu do kodu (code access security) i rola oparta na autentykacji (role based authentication) czynią to.

 

 

1.4 Wymagania dla .NET Framework SDK

 

 

• Wymaganie co do Software

 

– Microsoft Internet Explorer 5.01 lub późniejszy

 

– Microsoft Data Access Components 2.6 (Microsoft Data Access Components 2.7 jest zalecany)

 

– SO :

 

Microsoft Windows XP Professional jeśli chcemy uruchomić ASP.NET. Jeśli chcemy tylko uruchamiać aplikacje, wtedy możemy je też uruchomić na Microsoft Windows XP Home Edition.

 

Jeśli mamy wcześniejsze wersje .NET, wtedy je odinstalowujemy przed instalacją nowszej. Te pliki zawierają cenne informacje co do instalacji, wymagań systemowych i troubleshooting.

 

 

.NET framework ma tutoriale, któr uczą technologii takich jak ASP.NET i windows forms. Aby skonfigurować taki tutorial

 

Start menu -> Program -> Microsoft .NET Framework SDK -> Samples and Quick Start Tutorials. To otwiera dokument HTML, który prowadzi przez proces konfigurowania sampli i tutoriali. Samples and Quick Start Tutorials

 

Plik logowania dla instalacji

 

09:25:58 24 kwietnia 2011: [Begin Samples Configuration]

 

09:25:58 24 kwietnia 2011: [Info] ConfigSamplesDll_DoTasks: Starting

 

09:25:58 24 kwietnia 2011: [Info] Config_NETSDK_Detect: .NET Framework SDK installation (detecting): SOFTWARE\Microsoft\.NETFramework

 

09:25:59 24 kwietnia 2011: [Info] Config_NETSDK_Detect: .NET Framework SDK installation (found): SOFTWARE\Microsoft\.NETFramework

 

09:26:02 24 kwietnia 2011: [Info] ConfigSamplesDll_DoTasksWithGUI: Starting

 

09:27:08 24 kwietnia 2011: [Info] Config_ASPNET_Detect: ASP.NET installation (detecting): IIS://localhost/W3SVC

 

09:27:08 24 kwietnia 2011: [Info] Config_ASPNET_Detect: ASP.NET installation (not found): [Info] Config_ASPNET_Detect: ASP.NET installation (not found)

 

09:27:08 24 kwietnia 2011: [Info] Config_ASPNET_Detect: ASP.NET installation (not found): IIS://localhost/W3SVC

 

09:27:09 24 kwietnia 2011: [Info] Config_SSE_DNLD_Detect: SQL Express service instance (detecting): MSSQL$SQLEXPRESS

 

09:27:12 24 kwietnia 2011: [Info] Config_SSE_DNLD_Detect: SQL Express service instance (found): MSSQL$SQLEXPRESS

 

09:27:12 24 kwietnia 2011: [Info] Config_SSE_INST_Detect: SQL Express service instance (detecting): MSSQL$SQLEXPRESS

 

09:27:13 24 kwietnia 2011: [Info] Config_SSE_INST_Detect: SQL Express service instance (found): MSSQL$SQLEXPRESS

 

09:27:14 24 kwietnia 2011: [Info] Config_IIS_Detect: IIS (Internet Information Services) installation (detecting): IIS://localhost/w3svc/1/root,IIS://localhost/w3svc/AppPools

 

09:27:14 24 kwietnia 2011: [Info] Config_IIS_Detect: IIS (Internet Information Services) installation (not found). Setup has detected that IIS is not installed. Virtual directories will not be created.

 

The QuickStart tutorials are written in ASP.Net and require IIS.

 

Please refer to the ‘Installing IIS’ section of the Samples\Setup\HTML\ConfigDetails.htm document for further information: Unknown error (0x80005000)

 

09:27:14 24 kwietnia 2011: [Info] Config_IIS_Detect: IIS (Internet Information Services) installation (not found). Setup has detected that IIS is not installed. Virtual directories will not be created.

 

The QuickStart tutorials are written in ASP.Net and require IIS.

 

Please refer to the ‘Installing IIS’ section of the Samples\Setup\HTML\ConfigDetails.htm document for further information: IIS://localhost/w3svc/1/root,IIS://localhost/w3svc/AppPools]

 

Nie ma IIS, który jest konieczny, ale na Home Edition nie można go zainstalować.

 

Microsoft .NET Framework SDK QuickStart Tutorials

 

 

QuickStarts są najszybszą drogą do zrozmienia co technologia .NET Framework musi zaoferować dla wiodących programistów. Tutaj znajdziemy informacje o dobrych cechach .NET Framework i dowiemy się jak ich uzywać. Aby zacząć, wypełniamy instrukcje poniżej. Kiedy klikamy linki i mamy Open albo Save dany plik, wybieramy Open.

 

Set up the QuickStarts

 

Ponieważ QuickStarts pokazują szeroką gamę technologii .NET Framework, jest wymagana pewana konfiguracja maszyny. Quickstart Configuration Wizard instaluje SQL Server Express, importuje sample baz danych do SQL Server Express, tworzy kilka wirtualnych katalogów Internet Information Services (IIS) i kompiluje sample the SDK Quickstart.

 

Aby zakończyć te operacje, musimy być zalogowani jako administratorzy. Dla kompletnej listy zadań, w tym ręczen isntrukcje dla konfigurowania QuickStarts, patrzymy dokument Configuration Details.

 

Visual J# Samples

 

SampleVisual J# samples nie są gotowe do natychmiastowego użycia. Aby uruchomić sample, musi być zainstalowany Visual J# samples, the Visual J# Redistributable Package version 2.0. Installing the Visual J# Redistributable Package.

 

ASP.NET 2.0 QuickStarts

 

Common Tasks QuickStarts

 

Web Services Quickstarts

 

 

Sample Notes

 

Caution

 

 

Jeśli uzywamy sampli w środowisku produkcji (production environment), trzeba być pewnym, że usuwamy ten kod , który wyświetla wiadomości o wyjątkach i stack traces. Jakiś użytkownik mógłby użyć tych informacji do zagrożenia naszego SO.

 

 

Additional Information

 

Dla dodatkowych sampli ASP.NET, artykułów i ściągnietego kodu, dyskusji i FAQs patrzymy The Official Microsoft ASP.NET Site.

 

.NET Framework SDK zawiera zasoby dla rozwoju z .NET Compact Framework redistributable..NET Compact Framework umożliwia rozwój bezpiecznych, ściągalnych aplikacji na urządzeniach takich jak personal digital assistants (PDAs), mobile phones i set-top boxes.

 

Dodatkowe informacje technicznego wsparcia dla sampli .NET Framework SDK są na Microsoft Support Knowledge Base.

 

 

Konfiguracja szczegółów

 

 

Szczegółowy opis kroków konfiguracji wykonanej przez narzedzie konfiguracji sampli jes w dokumencie configuration details. Ten dokument zawiera:

 

  1. Instrukcje ręcznej konfiguracji.

  2. Ogólne ustawienie maszyny i informacje konfiguracyjne.

  3. Rozwiązanie problemów dla ustawienia sampli.

 

Dodatkowe wsparcie na Microsoft Support Knowledge Base.

 

 

Microsoft .NET Framework SDK QuickStart Web Site nie może być uruchomiony.

 

 

Aby uruchomić web site:

 

  • Otwieramy IIS manager lub wprowadzamy polecenie inetmgr w wierszu polecenia.

  • Przechodzimy do węzła Default Web Site będącego na IIS\<computerName>\WebSites\Default Web Site

  • Klikamy prawym przyciskiem myszy na ten węzeł i wybieramy start.

 

Kiedy web site jest startowany, uruchamiamy quickstarts przez otwarcie Quickstart Tutorials ze Start Menu.

 

 

Microsoft .NET Framework SDK QuickStart Configuration Details

 

 

Szczegółowe listowanie kroków konfiguracyjnych wykonanych przez program konfiguracyjny QuickStart w .NET Framework.

 

General SQL Server/SQL Server Express Information

 

 

Aby sample bazy danych miały dostęp do funkcji nalezycie, wymagana jest instancja Microsoft® SQL Server Express™.  Aby ściągnąć i zainstalować Microsoft SQL Server Express, idziemy za instrukcjami w Microsoft SQL Server Express http://go.microsoft.com/fwlink/?LinkId=31766.

 

 

Instalacja SQL Server 2005 zamiast SQL Server Express

 

 

Użytkownik może użyć też ConfigSamples.exe dla instalacji nazwanej instancji lub domyslnej instancji SQL Server 2005 przez przekazania w przełączniku /sql_instance:<named_instance>.

 

<sdk Install Path>\samples\setup\configsamples.exe /sql_instance:<MyInstanceName>

 

Nazwaną instancją SQL Server Express użytą przez sample SDK jest ‘SQLExpress‘.  Aby mieć dostęp do bazy danych, uzywamy nazwy serwera: (local)\SQLExpress.

 

<SDK Prompt> sqlcmd -S (local)\SQLExpress -E -d <database>

 

 

Installing the SDK Quickstart Tutorials Manually

 

 

Tutoriale SDK Quickstart wymagają Internet Information Server. Dla pomocy w instalacji Internet Information Server Patrzymy Windows Help documentation.

 

  1. Instalujemy i rejestrujemy ASP.NET z IIS

    1. Z wiersza polecenia SDK uruchamiamy aspnet_regiis -ir -enable

  2. Opcjonalnie instalujemy SQL Server Express lub SQL Server 2005.

  3. Instalujemy bazę danych Quickstart Sample. Z wiersza polecenia SDK zmieniamy do foldera SDK\v2.0\samples\setup i uruchamiamy następujące polecenia

    1. sqlcmd -E -S (local)\SQLExpress -i InstPubs.sql

    2. sqlcmd -E -S (local)\SQLExpress -i InstNwnd.sql

    3. sqlcmd -E -S (local)\SQLExpress -i InstGrocer.sql

    4. sqlcmd -E -S (local)\SQLExpress -i InstContacts.sql

    5. sqlcmd -E -S (local)\SQLExpress -i InstPhotos.sql

    6. sqlcmd -E -S (local)\SQLExpress -i Inst_FileSystemSQL.sql

    7. aspnet_regsql.exe -S (local)\SQLExpress -E -A all

  4. Przydzielamy konto użytkownika ASP.NET dla dostępu do baz danych. Na Windows Server 2003 proces ASP.NET uruchamia się pod NT AUTHORITY\NETWORK SERVICE. We wszystkich pozostałych typach to działa pod MACHINENAME\ASPNET.

    1. sqlcmd -E -S (local)\SQLExpress -Q “sp_grantlogin <ASP.NET User Account>”

    2. sqlcmd -E -S (local)\SQLExpress -d Pubs -Q “sp_grantdbaccess <ASP.NET User Account>”

    3. sqlcmd -E -S (local)\SQLExpress -d Pubs -Q “sp_addrolemember ‘db_owner’, <ASP.NET User Account>”

    4. sqlcmd -E -S (local)\SQLExpress -d NorthWind -Q “sp_grantdbaccess <ASP.NET User Account>”

    5. sqlcmd -E -S (local)\SQLExpress -d NorthWind -Q “sp_addrolemember ‘db_owner’, <ASP.NET User Account>”

    6. sqlcmd -E -S (local)\SQLExpress -d GrocerToGo -Q “sp_grantdbaccess <ASP.NET User Account>”

    7. sqlcmd -E -S (local)\SQLExpress -d GrocerToGo -Q “sp_addrolemember ‘db_owner’, <ASP.NET User Account>”

    8. sqlcmd -E -S (local)\SQLExpress -d Contacts -Q “sp_grantdbaccess <ASP.NET User Account>”

    9. sqlcmd -E -S (local)\SQLExpress -d Contacts -Q “sp_addrolemember ‘db_owner’, <ASP.NET User Account>”

    10. sqlcmd -E -S (local)\SQLExpress -d Photos -Q “sp_grantdbaccess <ASP.NET User Account>”

    11. sqlcmd -E -S (local)\SQLExpress -d Photos -Q “sp_addrolemember ‘db_owner’, <ASP.NET User Account>”

    12. sqlcmd -E -S (local)\SQLExpress -d FileSystemSQL -Q “sp_grantdbaccess <ASP.NET User Account>”

    13. sqlcmd -E -S (local)\SQLExpress -d FileSystemSQL -Q “sp_addrolemember ‘db_owner’, <ASP.NET User Account>”

    14. sqlcmd -E -S (local)\SQLExpress -d ASPNETDB -Q “sp_grantdbaccess <ASP.NET User Account>”

    15. sqlcmd -E -S (local)\SQLExpress -d ASPNETDB -Q “sp_addrolemember ‘db_owner’, <ASP.NET User Account>”

  5. Modyfikujemy plik Web.config file dla wskazania lokacji, gdzie jest zainstalowany QuickStart na:

 

. . .
<sourceview>
<add key=”root” value=”C:\Program Files\Microsoft.NET\SDK\v2.0\QuickStart” />
</sourceview>
. . .

 

Jeśli zamierzamy hostować QuickStart dla umożliwienia innym masyznom przegladanie i uruchamianie QuickStart, ustawiamy wartość klucza RemoteHosted appSetting na true w pliku web.config. To uniemozliwi naszemu komputerowi hostowanie pewnych sampli, które nie zostały zaprojektowane dla użycia z niezaufanymi źródłami.

 

<appSettings>
     <add key=”RemoteHost” value=”true” />
</appSettings>

 

  1. Jeśli zainstalowalismy SQL Server 2005 zamiast SQL Express, będziemy potrzebować uaktualnienia ciągu połączenia używanego przez wszystkie sample. Szukamy katalogu SDK\v2.0\QuickStart\ i zastępujemy wszystkie instancje “(local)\SQLExpress” z ciągiem połączenia potrzebnym dla naszej instancji SQL.

  2. Instalujemy wszystkie SDK Quickstart Virtual Directories na IIS. Setup.xml zainstalowany do folderu SDK\v2.0\Samples\setup listuje wszystkie wirtualne katalogi SDK Quickstart, które musimy zainstalować. Kreator konfiguracji SDK Quickstart domyślnie instaluje wiertualne katalogi do ścieżki wirtualnego katalogu QuickstartV20.

  3. Jeśli uruchamiamy IIS 6.0, powinniśmy stworzyć oddzielną unikalną pulę aplikacji dla sampli SDK Quickstart samples. SDK Quickstart Configuration Wizard tworzy “QuickstartV20AppPool” domyślnie. Kojarzymy tę pulę aplikacji z wirtualnym katalogiem QuickstartV20.

  4. Ustawiamy wszystkie odpowiednie prawa bezpieczeństwa na tę pulę aplikacji, którą stworzyliśmy i na wirtualne katalogi Quickstart dla odpowiedneigo chronienia naszego serwera IIS przed atakami.

  5. Po stworzeniu wszystkich wirtualnych katalogów, uruchamiamy “aspnet_regiis -s W3SVC/1/ROOT/QuickstartV20” z wiersza polecenia SDK dla rejestracji mapy skryptu asp.net 2.0 dla Quickstart Virtual Directory.

  6. Opcjonalnie budujemy wszystkie sample Quickstart w folderze sdk\v2.0\Quickstart\ przez wywołanie msbuild na każdym pliku solution sampla z wiersza polecenia SDK.

 

 

Uruchomienie QuickStart na Windows Server 2003, 64-bit Windows XP i nowszych SOs Windows

 

 

Jeśli instalujemy QuickStart na Windows Server 2003, 64-bit Windows XP lub nowszych SOs Windows, ASP.NET Web Server Extensions muszą być ‘Allowed’ dla QuickStart, aby działać. Patrzymy sekcję ‘Enabling and Disabling Dynamic Content’ dla dokumentacji pomocy dla IIS, aby uzyskać więcej dokumentacji.

 

 

Rozwiązanie błędu “.NET Framework SDK installation (not found)” w ConfigSamples.Exe

 

 

Narzędzie konfiguracji sampli zwróci błąd “.NET Framework SDK installation (not found)”, jeśli to nie wykryje instalacji odpowiedniej wersji .NET Framework SDK. Jeśli otrzymamy taki błąd, potwierdzamy, że klucz rejestru stworzomy przez .NET Framework SDK (HKLM\SOFTWARE\Microsoft\.NETFramework\sdkInstallRootv2.0) istnieje. Jeśli ten klucz rejestru nie istnieje, to wskazuje, że.NET Framework SDK nie zostało zainstalowane lub że ta instalacja nie zakończyła się z powodzeniem. W takim wypadku ponownie instalujemy .NET Framework SDK.

 

 

Instalowanie dodatkowych czcionek

 

 

Sample ASP.NET Quickstart Localization wymagają kilka czionek (np. Japońskiego) dla przeglądania właściwie tych sampli. Ta procedura instalacji dla tych czionek może wymagać oryginalnego Windows CD. Aby zainstalować nowe czionki:

 

Na Windows XP lub Windows 2003

 

  • Otwieramy Control Panel

  • Otwieramy Regional and Language Options

  • Wybieramy Languages tab

  • Zaznaczamy np. ‘Install files for East Asian Languages’

 

 

Instalowanie SQL Server Express

 

 

1. ERROR: SQL Server Express Installation Failed

 

To jest ogólna wiadomość o błędzie instalacji SSE. Idziemy do Start -> Settings -> Control Panel -> Administrative Tools -> Services i szukamy “SQL Server (SQLEXPRESS)”. Jeśli zobaczymy to tam, uruchamiamy to. Jesli tego nie ma, jeszcze raz uruchamiamy ConfigSamples.exe.

 

 

2. ERROR: SQL Server Express Download Failed

 

Ręcznie ściagamy pakiet instalacyjny SSE. Aby ściagnąć 32-bit-only SSE (32MB), idziemy do http://go.microsoft.com/fwlink/?LinkId=47324. Aby ściagnąć 32/64 bit SSE (70MB), idziemy do http://go.microsoft.com/fwlink/?LinkId=39581. Potem jeszcze raz uruchamiamy ConfigSamples.exe i kiedy mamy tę stronę, która ustawia opcje dla SQL Server Express, wybieramy drugą opcje “Download from the local machine” i wyszukujemy lokacji, z której ściagamy.

 

 

Parametry wiersza poelcenia ConfigSamples

 

 

Narzędzie SDK Quickstart Setup dostarczanastępujących parametrów wiersza polecenia dla łatwiejszego zrobienia setup i odinstalowania QuickStart.

 

Użycie:

 

ConfigSamples [-?] [-q] [-v] [-sql_instance:name]

 

Parameter

Details

-?

Show parameter usage information

-q

Run in quiet mode. No UI is displayed. Default values will be selected if not specified by a switch. By default SQL Express is downloaded and installed by ConfigSamples.

-v

Show verbose information. Verbose log information will be displayed to the console instead of the standard log file is this switch is specified.

-i

Ignore install failures. Do not rollback changes. The -i switch can be to force ConfigSamples to install the QuickStart even when there are installation problems.

-uninstall

This option will cause ConfigSamples to remove the Quickstart Virtual directories and compiled binaries from you computer. It will not remove SQL Server Express or uninstall the sample databases.

-enable_aspnet

This option will enable ASP.NET in IIS if it was not previously installed and enabled.

-skip_sqlexpress

Skips the download and installation of SQL Server Express

-sql_instance:<name>

This option allows you to specify your own SQL Server instance name. If you do not specify an instance name as the parameter ConfigSamples will attempt to install to the default SQL Server instance. By default ConfigSamples will try to install the SQLServerExpress named SQL instance.

 

 

Parametry wiersza poelcenia ConfigSSE

 

 

ConfigSSE zostal zaprojektowany dla instalacji SQL Server Express i baz danych dla SDK Sample bez ustawienia reszty z QuickStart.

 

Użycie:

 

ConfigSSE [-?] [-q] [-v] [-sql_instance:name]

 

Parameter

Details

-?

Displays usage information

-q

Runs in silent mode. No UI is displayed and defaults are selected. By default SQL Server Express is downloaded and installed.

-v

Verbose mode. Logging information is displayed in the command prompt.

-i

Ignores all setup errors.

-sql_instance:<name>

This option allows you to specify your own SQL Server instance name. If you do not specify an instance name as the parameter ConfigSamples will attempt to install to the default SQL Server instance. By default ConfigSamples will try to install the SQLServerExpress named SQL instance.

 

 

Scrubbing Pre-Existing Data Files

 

 

Jeśli pliki bazy danych z tą samą nazwą pliku już istnieją na twardym dysku, to narzedzie konfiguracji tych sampli nadpisze/zastapi te pliki. Są dwa sposoby poprawienia tego problemu:

 

1.  Kasujemy lub przemianowujemy następujące pliki z C:\Program Files\Microsoft SQL Server\MSSQL$SQLExpress\Data directory.

 

  • Pubs.mdf

  • Pubs_log.ldf

  • northwind.mdf

  • northwind.ldf

  • GrocerToGo.mdf

  • GrocerToGo.ldf

  • ASPNETDB.mdf

  • ASPNETDB_log.ldf

 

2a.  Kompletujemy instrukcje opisane w powyższych sekcjach Adding the SQL Server Databases to SQL Server Express i Granting Access to the ASPNET user.

 

2b.  Lub uruchamiamy znowu to narzędzie konfiguracji sampli (ConfigSamples.exe).

 

Ustawienie zmiennej środowiskowej NetSamplePath

 

 

Zmienna środowiskowa NetSamplePath jest wymagana dla kompilacji sampli QuickStart.  Ustawiamy zmienną środowiskową NetSamplePath do katalogu <SDK>.  Nazwa katalogu <SDK> musi być w formie ktrótkiej (bez spacji).  Np. jak NetSamplePath powinna być ustawiona, widzimy plik SDKVars.bat zlokalizowany w katalogu <SDK>\Bin. Proces ustawienai zmiennej środowiskowej różni się zależnie od naszego SO. Ogólnie jest to:

 

SET NetSamplePath=D:\PROGRA~1\MICROS~1.NET\SDK\v2.0\

 

 

Przydzielamy nowe konto użytkownika dostępu do bazy danych

 

 

Zastępujemy DATABASE NAME nazwą bazy danych i zastępujemy USER NAME nazwą naszego konta użytkownika.

 

  1. sqlcmd -E -S (local)\SQLExpress -Q “sp_grantlogin < USER NAME >”

  2. sqlcmd -E -S (local)\SQLExpress -d DATABASE NAME -Q “sp_grantdbaccess < USER NAME >”

  3. sqlcmd -E -S (local)\SQLExpress -d DATABASE NAME -Q “sp_addrolemember ‘db_owner’, < USER NAME >”

 

 

Jak uruchamiać Quickstarts jako zwykły użytkownik

 

 

Jeśli musimy połączyć się do SSE używając konta zwykłego użytkownika dla wszystkich instancji , gdzie normalnie użylibyśmy (administrator)

 

sqlcmd -E …..

 

używamy zamiast tego

 

sqlcmd -U <Username> -P <Password> …..

 

Także skoro już nie używamy Integrated security dla naszej witryny web, wtedy ciągi połączenia zlokalizowane w plikach web.config muszą być zmienione na następujący format:

 

<add name=”DatabaseName” connectionString=”Server=ServerName; Database=DatabaseName;User ID=UserName;Password=Password;” providerName=”System.Data.SqlClient” />

 

z poprzedniego formatu:

 

<add name=”DatabaseName” connectionString=”Server=ServerName;Integrated Security=True;Database=DatabaseName;Persist Security Info=True” providerName=”System.Data.SqlClient” />

 

 

Jak nadać Write Access dla Network Service

 

 

Jeśli nasza bieżąca tożsamość, czyli identity (NT AUTHORITY \ NETWORK SERVICE) nie ma prawa zapisu, w tym katalogu tymczasowego, uruchamiamy następujace polecenie dla nadania odpowiednich praw:

 

<SDK Prompt>aspnet_regiis -ga “NT Authority\Network Service”

 

 

Instalowanie MSDE

 

 

Sample i tutoriale szybkiego startu .NET framework wymagają Microsoft SQL Server Desktop Engine (MSDE). MSDE jest skalowaną wersją SQL Server. Sample używają bazy danych z MSDE. Aby pracować z samplami trzeba mieć instancję MSDE. Możemy użyć MSDE dla tworzenia baz danych dla testowanych aplikacji.

 

 

Instalowanie QUICKSTARTS

 

 

Otwieramy:

 

 

Start > Programs > Microsoft .NET Framework SDK v2.0 > Quickstart Tutorials

 

 

 

Drukowanie QUICKSTARTS

 

 

Aby wydrukować tematy QuickStart, klikamy link “Hide TOC” w głównym nawigacyjnym menu, potem klikamy link ciało zagadnienia i wybieramy “Print”. Quickstarts są dobrze drukowane w trybie “Portrait” lub “Landscape”.

 

 

Hosting QUICKSTARTS online (MIXED MODE)

 

 

Sample Quickstart są przeznaczane do zainstalowania i uruchomienia z naszej lokalnej maszyny. Jeśli uruchamiamy Windows 2000, bedziemy musieli też odczytać dokumentację z naszej lokalnej maszyny. Jeśli uruchamiamy NT 4.0, powinniśmy odczytać dokumentację ze zdalnego serwera, który uruchamia Quickstarts na Windows 2000. W tym wypadku będziemy w stanie uruchomić sample Windows Forms i konsoli lokalnie, ale strony ASP.NET uruchamiac się będą ze zdalnego serwera- to jest zw. “mixed mode”.

 

 

Mircosoft hostuje sample Quickstart na następujacym zdalnym serwerze dla anszej wygody:

 

http://go.microsoft.com/fwlink/?linkid=516&clcid=0x409

 

 

Mozemy też ustawić nasz własny zdalny serwer dla naszej organziacji przez następujące instrukcje poniżej:

 

 

A. Konfigurowanie serwera

 

 

Będziemy musieli edytować ustawienia bezpieczeństwa dla każdego wirtualnego katalogu w quickstart dla nadania dostepu do maszyn innych niż “localhost” (maszyna lokalna). Aby to zrobić:

 

– Startujemy Internet Services Manager przez wybranie Start->Run i wpisanie “inetmgr“.

 

– Rozwinięcie pozycji “Default Web Site” po lewej stronie drzewa.

 

– Klikamy prawym przyciskiem katalog wirtualny “quickstart” i wybieramy “Properties”.

 

– Wybieramy zakładkę “Directory Security” i edytujemy “IP address and domain name restrictions.”

 

– Dodajemy maszyny, którym chcemy przydzielić dostęp lub przydzielamy dostęp wszystkim maszynom.

 

Przez udzielenia dostępu do zdalnych maszyn możemy narazić bezpieczeństwo naszego serwera. Tylko doaje dostęp do IPs, którym ufamy.

 

 

B. Konfigurowanie Klienta

 

 

Kiedy czytamy dokumentację quickstart ze zdalnego serwera, musimy konfigurować Quickstart dla zrodzenia sampli na naszej lokalnej maszynie. Wybieramy link “Configure Installation” na stronie domowej Quickstart lub nawigujemy bezpośrednio do /quickstartV20/setup.aspx. Tren krok nie jest potrzebny, jeśli czytamy dokumentację na naszej lokalnej maszynie.

 

 

Hostowanie QUICKSTARTS online(REMOTE-ONLY MODE)

 

 

Mixed mode (powyżej) zakłada, że zawsze mamy lokalną kopię tych sampli, nawet jeśli odczytujemy tą dokumentację online. To pozwala samplom Windows Forms i console na uruchomienie z lokalnej maszyny kliemta, skoro one nie mogą być uruchamiane zdalnie. jednak nie możemy chcieć wymagać od klienta instalacji sampli a zatem quickstart wspiera remote-only modegdzie sample są zawsze uruchamiane online. Aby włączyć remote-only mode, robimy następujące ustawienia konfiguracyjne w pliku web.config w katalogu roota:

 

 

<appsettings>

 

<add key=”RemoteHost” value=”true” />

 

</appsettings>

 

 

To ma wpływ na nizszych rangą sampli, które nie mogą być uruchamiane z Web tylko dla “View Source”.

 

 

Ręczne budowanie QUICKSTARTS

 

 

Domyślnie sample Quickstart są już zbudowane, kiedy instalujemy je na naszej maszynie. jednak jesli modyfikujemy u chcemy przebudować jakiekolwiek z sampli, możemy zrobić to przez nastepujące dwa kroki:

 

 

1. Ustawiamy zmienną środowiskową NETSAMPLEPATH na katalog rodzicielski dla Quickstarts, np.:

 

 

> set NETSAMPLEPATH=C:\Program Files\Microsoft.Net\SDK\v2.0

 

 

2. Budujemy sample używając MSBuild. Możemy wpisać “msbuild buildall.proj” z HowTo\Samples pod drzewem katalogu Quickstart dla rekursywnego budowania sampli przy lub poniżej tej lokacji.

 

Możemy potrzebować wstawić narzędzia SDK do naszej PATH, aby MSBuild działał jak należy. Narzędzia SDK są ulokowane w katalogu:

 

 

%WINDIR%\Microsoft.Net\Framework\<version_dir>

 

 

Działanie i opcje MSBuild

 

Microsoft Windows XP [Wersja 5.1.2600]

 

(C) Copyright 1985-2001 Microsoft Corp.

 

 

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild>msbuild

 

Microsoft (R) Build Engine Version 2.0.50727.42

 

[Microsoft .NET Framework, Version 2.0.50727.42]

 

Copyright (C) Microsoft Corporation 2005. All rights reserved.

 

 

MSBUILD : error MSB1003: Specify a project or solution file. The current working

 

directory does not contain a project or solution file.

 

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild>help

 

Aby uzyskać więcej informacji o poleceniu, wpisz HELP nazwa_polecenia

 

ASSOC Wyświetla lub modyfikuje skojarzenia rozszerzeń plików.

 

AT Planuje wykonanie poleceń i programów.

 

ATTRIB Wyświetla lub zmienia atrybuty pliku.

 

BREAK Wyłącza lub włącza rozszerzone sprawdzanie klawiszy CTRL+C.

 

CACLS Wyświetla lub modyfikuje listy kontroli dostępu (ACL) plików.

 

CALL Wywołuje jeden program wsadowy z innego.

 

CD Wyświetla lub zmienia nazwę bieżącego katalogu.

 

CHCP Wyświetla lub ustawia numer aktywnej strony kodowej.

 

CHDIR Wyświetla lub zmienia nazwę bieżącego katalogu.

 

CHKDSK Sprawdza dysk i wyświetla raport o jego stanie.

 

CHKNTFS Wyświetla lub modyfikuje stan sprawdzania dysku przy rozruchu.

 

CLS Czyści ekran.

 

CMD Uruchamia nowe wystąpienie interpretera poleceń systemu Windows.

 

COLOR Ustawia domyślny kolor tła i pierwszego planu konsoli.

 

COMP Porównuje zawartość dwóch plików lub zestawów plików.

 

COMPACT Wyświetla i pozwala na modyfikację listy plików. skompresowanych na

 

partycji NTFS.

 

CONVERT Konwertuje woluminy FAT na woluminy NTFS. Nie można konwertować

 

bieżącego dysku.

 

COPY Kopiuje jeden lub wiele plików w inne miejsce.

 

DATE Wyświetla lub ustawia datę.

 

DEL Usuwa jeden lub wiele plików.

 

DIR Wyświetla listę plików i podkatalogów katalogu.

 

DISKCOMP Porównuje zawartość dwóch dyskietek.

 

DISKCOPY Kopiuje zawartość jednej dyskietki na drugą.

 

DOSKEY Edytuje wiersze poleceń, przywraca polecenia Windows i tworzy makra.

 

ECHO Wyświetla komunikaty lub wyłącza i włącza echo poleceń.

 

ENDLOCAL Kończy lokalne zmiany środowiska w plikach wsadowych.

 

ERASE Usuwa jeden lub wiele plików.

 

EXIT Kończy działanie programu CMD.EXE (interpretera poleceń).

 

FC Porównuje dwa pliki lub zestawy plików i wyświetla różnice między

 

nimi.

 

FIND Wyszukuje ciąg tekstowy w pliku lub plikach.

 

FINDSTR Wyszukuje ciągi znaków w plikach.

 

FOR Uruchamia podane polecenie dla każdego pliku z zestawu plików.

 

FORMAT Formatuje dysk do użytku w systemie Windows.

 

FTYPE Wyświetla i modyfikuje typy plików używane w skojarzeniach rozszerzeń

 

plików.

 

GOTO Przekazuje sterowanie interpretera poleceń systemu Windows do wiersza

 

o podanej etykiecie w pliku wsadowym.

 

GRAFTABL Włącza wyświetlanie przez system Windows znaków rozszerzonych w

 

trybie graficznym.

 

HELP Podaje informacje o poleceniach systemu Windows.

 

IF Dokonuje warunkowego przetwarzania w plikach wsadowych.

 

LABEL Tworzy, zmienia lub usuwa etykietę(etykiety) woluminu dysku.

 

MD Tworzy katalog.

 

MKDIR Tworzy katalog.

 

MODE Konfiguruje urządzenia systemowe.

 

MORE Wyświetla informacje ekran po ekranie.

 

MOVE Przenosi jeden lub wiele plików z jednego katalogu do drugiego.

 

PATH Wyświetla lub ustawia ścieżkę przeszukiwania dla plików wykonywalnych.

 

PAUSE Wstrzymuje przetwarzanie pliku wsadowego i wyświetla komunikat.

 

POPD Przywraca katalog zapisany przez PUSHD.

 

PRINT Drukuje plik tekstowy.

 

PROMPT Zmienia znak zachęty wiersza polecenia systemu Windows.

 

PUSHD Zapisuje bieżący katalog, a następnie zamienia go.

 

RD Usuwa katalog.

 

RECOVER Odzyskuje możliwe do odczytania informacje z uszkodzonego dysku.

 

REM Oznacza komentarze w pliku wsadowym lub pliku CONFIG.SYS.

 

REN Zmienia nazwę pliku lub plików.

 

RENAME Zmienia nazwę pliku lub plików.

 

REPLACE Zamienia pliki.

 

RMDIR Usuwa katalog.

 

SET Wyświetla, ustawia lub usuwa zmienne środowiskowe systemu Windows.

 

SETLOCAL Rozpoczyna lokalne zmiany środowiska w plikach wsadowych.

 

SHIFT Zmienia pozycje parametrów w pliku wsadowym.

 

SORT Sortuje wprowadzone dane.

 

START Uruchamia program lub polecenie w oddzielnym oknie.

 

SUBST Przypisuje ścieżce literę dysku.

 

TIME Wyświetla lub ustawia czas systemowy.

 

TITLE Ustawia tytuł okna dla sesji CMD.EXE.

 

TREE Wyświetla strukturę katalogów dysku lub ścieżki.

 

TYPE Wyświetla zawartość pliku tekstowego.

 

VER Wyświetla wersję systemu Windows.

 

VERIFY Instruuje system Windows, aby sprawdzał poprawność zapisu plików na

 

dysku.

 

VOL Wyświetla etykietę oraz numer seryjny dysku.

 

XCOPY Kopiuje pliki i katalogi.

 

 

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild>

 

4 thoughts on “.NET Framework

    1. tomaszzackiewicz Post author

      Please bookmark this article. I’m gad you find it useful. My work isn’t in vain. But it is in Polish🙂. Now I’m trying to write all my articles in English, so that the people in the world can use my articles.

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s