Startseite Index << >>
1 - Einleitung
Microsoft stellt mit dem .NET Framework mehrere Programmiersprachen zur Verfügung, mit denen Anwendungen für .NET entwickelt werden können.
Dazu gehörten seit dem .NET Framework 1.0 Visual C++, Visual Basic und die beiden "neueren" Sprachen C# (mit Wurzeln aus C/C++ und Java) und J# (basierend auf
Java, ab dem Visual Studio 2008 nicht mehr darin enthalten, läuft 2015 aus). Mit dem .NET Framework 4.0 kommt nun F# hinzu (auch als Erweiterung von Visual
Studio 2008 möglich). Im Folgenden wird nur Bezug auf die Entwicklung mit C# (sprich Si Scharp) genommen. Aber bevor Sie Ihre ersten Programmiererfahrungen damit
sammeln können, soll kurz die Software vorgestellt werden, die das überhaupt möglich macht, das .NET Framework.
1.1 Das .NET Framework
Ein Framework stellt in der Softwareentwicklung ein Gerüst zur Lösung einer bestimmten Aufgabe dar. So kann ein Framework z.B. dazu dienen, Fenster- oder
Webanwendungen zu erstellen, wobei schon ein Rahmen für eigene Erweiterungen (Komponenten) vorgegeben wird. Das .NET Framework bietet zum einen eine Klassenbibliothek,
die .NET Framework Class Library (auch Base Class Library genannt), zum anderen eine Laufzeitumgebung (als Laufumgebung können Sie sich z.B. Ihr Betriebssystem vorstellen,
unter dem Ihre Anwendungen ausgeführt werden) für die fertigen Anwendungen, die Common Language Runtime, kurz CLR. Mit einem klassischen Framework hat dies nur noch
indirekt etwas zu tun, da die Klassenbibliothek sehr viele Einsatzgebiete abdeckt und die CLR - untypisch für ein Framework - die Basis zum Ablauf der .NET-Anwendungen
mitliefert. Mit .NET (der Kurzform für das .NET Framework) können Sie verschiedene Anwendungstypen erstellen:
Konsolenanwendungen: Sie besitzen keine grafische Oberfläche und werden auch als Textbildschirmanwendungen bezeichnet.
Windows-Anwendungen: Sie besitzen eine grafische Oberfläche.
Dienstanwendungen: Diese stellen eine bestimmte Funktionalität bereit, die über das Betriebssystem verwaltet wird.
Webanwendungen: Diese dienen zur dynamischen Generierung von Webseiten.
Web Services: Sie stellen Dienste über das Netz/Internet zur Verfügung.
Anwendungen, welche die Frameworks WPF (Windows Presentation Foundation - Grafik), WCF (Windows Communication Foundation - Kommunikation) und WF (Windows Workflow Foundation - Arbeitsabläufe) nutzen.
Anwendungen für mobile Geräte
INFO
Das .NET Framework 4.0 führt weiterhin die Dynamic Language Runtime (DLR) ein. Darüber wird die CLR erweitert, so dass Sie mit
dynamische Sprachen zusammenarbeiten kann (in solchen Sprachen können Typinformationen z.B. zur Laufzeit der Anwendung ermittelt werden).
Das kostenfrei verfügbare .NET Framework SDK (Software Development Kit) enthält zusätzliche Software, um Anwendungen für .NET zu entwickeln und auszuführen.
Das Redistributable Package (die .NET-Runtime) installiert dagegen nur die Software, um .NET-Anwendungen zu starten (es fehlen hier bestimmte Entwicklungstools und die Dokumentation).
Das SDK ist dabei deutlich größer (600MB) - allerdings gegenüber der Vorgängerversion um die hälfte geschrumpft. Die Datei für die Installation des .NET Frameworks heißt
dotNetFx40_Full_x86_x64.exe und ist in der Version 4.0 aktuell 48 Mbyte groß. Alle benötigten Dateien erhalten Sie ausgehend von dem
URL http://msdn.microsoft.com/de-de/netframework/aa569263.aspx. Das neue Windows SDK für Windows 7 und das.NET Framework 4.0 lag zur Drucklegung des Buches noch nicht vor.
INFO
Diesem Buch liegt mit Visual C# 2010 Express eine kostenfreie Entwicklungsumgebung bei, die außerdem auch das .NET Framework 4.0 installiert. Mehr dazu im dritten Kapitel.
11.1.1 Die Common Language Runtime (CLR)
Basis aller Anwendungen, die unter .NET laufen, ist die CLR. Ohne sie kann keine .NET-Anwendung ausgeführt werden. Sie liegt aktuell als Aufsatz eines vorhandenen Betriebssystems
vor (wie z.B. für Windows 2003/XP/Server 2008/Vista/7). Sie könnte sich aber auch bereits im Betriebssystemkern befinden, so dass keine Installation der .NET-Laufzeitumgebung mehr notwendig ist.
Die CLR ist für zahlreiche Dinge zuständig, wenn es um die Ausführung einer .NET-Anwendung geht.
Überwachung der Code-Ausführung
Speicherverwaltung und -freigabe
Thread-Management
Sicherheit, z.B. Ausführungsberechtigungen von lokalen, Internet- oder Netzwerkanwendungen
Sicherstellung der Typ- und Codeverifikation über das Common Type System (CTS)
Zusammenarbeit mit Unmanaged Code, d.h. Code, der nicht über die CLR ausgeführt wird
Code, der direkt über die CLR ausgeführt wird, wird als Managed Code (verwalteter Code) bezeichnet, d.h. die CLR kann sich um ihn kümmern. Sämtlicher anderer Code wird als
Unmanaged Code (unverwalteter Code) bezeichnet. Managed Code liegt in Form von Anweisungen der so genannten Intermediate Language (IL) vor. Die CLR kann diesen Code ausführen.
Abbildung Abbildung 1.1: Stark vereinfachte Architektur von .NET
Im Vergleich zu anderen Sprachen benötigt .NET nur einen Compiler zur Übersetzung von Sourcecode (als Sourcecode wird der Text bezeichnet, mit dem Sie Ihr Programm schreiben) in IL-Code,
wobei der Sourcecode beispielsweise in den Sprachen C# oder Visual Basic vorliegt. Das Besondere am IL-Code ist neben seiner Plattformunabhängigkeit die Tatsache, dass er zusätzlich durch
Metadaten beschrieben wird, die zusammen mit dem IL-Code verwaltet werden. Metadaten beschreiben, welche Typen im Quellcode enthalten sind (z.B. eine Klasse Mathe
) und zu welchen Daten
Referenzen (Verweise) benötigt werden (zum Beispiel zu einer anderen Bibliothek). Kurz gesagt, der IL-Code enthält zusammen mit den Metadaten sämtliche Informationen, damit man mit ihm, und er mit
anderen, zusammenarbeiten kann.
Das unter Windows erzeugte Format der ausführbaren Dateien (wie bei "normalen" *.exe-Dateien) ist so aufgebaut, dass nach dem Start einer .NET-Anwendung automatisch
die CLR aktiviert wird. Diese übernimmt dann die weitere Ausführung. Zur Ausführung einer .NET-Anwendung wird dadurch kein separater Interpreter (oder ein anderes Tool) benötigt.
Damit Implementierungen für das .NET Framework auch für andere Betriebssysteme möglich sind, wurde ein Großteil der Funktionalität der CLR in Form der CLI (Common Language Infrastructure)
standardisiert. Mehr dazu finden Sie unter dem URL http://msdn2.microsoft.com/de-de/netframework/aa569283(en-us).aspx). Die CLR ist damit eine spezielle Implementierung der CLI.
11.1.2 Dynamic Language Runtime
Die Sprache C# ist eine so genannte stark typisierte Sprache, d.h. es müssen während der Übersetzungszeit sämtliche Typen bekannt sein. In dynamischen Sprachen können Typen z.B. erst zur
Laufzeit bestimmt werden. Probleme gab es deshalb wenn Sie mit C# beispielsweise die Office-Produkte per COM (Common Object Model) ansprechen wollten oder wenn der Zugriff bzw. die
Kommunikation mit Sprachen wie JavaScript oder Python notwendig war - die wiederum dynamische Sprachen sind. Auch die Verwendung von Bibliotheken die mit dynamischen Sprachen entwickelt
wurden war vorher nicht so einfach zu bewerkstelligen.
Zur Lösung dieses Problems erhält die CLR mit dem .NET Framework 4.0 die Dynamic Language Runtime (DLR) als Aufsatz und kommuniziert über sie mit dynamischen Sprachen wie JavaScript, Python oder
Ruby. Auch wenn die Behandlung der DLR nicht Bestandteil dieses Buches ist sollen einige Anwendungsbeispiele gegeben werden:
Da dynamische Sprachen in der Regel Skriptsprachen sind (die Programme liegen in lesbarer Textform vor und werden zur Ausführungszeit ausgeführt) können sie auch einfach geändert werden. So können
Sie z.B. sich häufig ändernde Berechnungen durch Skripte ausführen lassen (die Steuerberechnung lässt grüssen), die selbst der Anwender notfalls ändern kann. Er müsste lediglich eine Textdatei bearbeiten.
Die Textdateien mit den Skriptdaten könnten sich auch zur Laufzeit ändern.
Durch die Änderung der Funktionsweise der Methoden ändern sich nicht nur die Datenteile sondern die gesamte Funktionalität kann zur Laufzeit ausgetauscht werden.
11.2 Common Type System (CTS)
Das CTS des .NET Frameworks definiert eine Menge an Grunddatentypen, ihren Aufbau und ihr Verhalten. Auch die CLR verwendet das CTS. Dies bedeutet auch, dass der Wertebereich eines Datentyps
in allen Sprachen und auf verschiedenen Plattformen immer gleich ist. Die Spezifikation des CTS ist eine Obermenge, d.h., eine .NET-Sprache muss nicht zwangsläufig alle Aspekte daraus
implementieren bzw. kann sich auch darüber hinaus bewegen. Allerdings stellt das CTS die Basis für eine Interoperabilität von Softwaremodulen dar, die mit verschiedenen Programmiersprachen erstellt wurden.
INFO
Auch wenn dies impliziert, dass nun die Entwickler einer Firma oder eines Projekts in der Sprache ihrer Wahl entwickeln können, ist dies sicher nicht von Vorteil, wenn es
um die Wartung von Code geht. Selbst wenn die Namensgebung und die Anwendung der Typen in allen Sprachen gleich sind (z.B. die Verwendung einer Klasse
Mathe
), hat doch jede Programmiersprache
ihre Eigenheiten. Es ist immer mit einem erhöhten Aufwand verbunden, wenn man den Code in einer anderen bzw. in mehreren Sprachen lesen und zusammenführen muss.
11.2.1 Common Language Specification (CLS)
Eine .NET-Anwendung kann grundsätzlich durch eine beliebige .NET Programmiersprache geschrieben werden, solange der zum Übersetzen notwendige Compiler die Anforderungen der
CLS erfüllt und .NET-kompatiblen IL-Code erzeugt. Die CLS definiert das Minimum an Funktionalität, die ein Compiler besitzen muss, um Sourcecode einer .NET-Sprache in IL-Code zu übersetzen.
Durch diese Spezifikation und das CTS wird außerdem sichergestellt, dass die .NET Class Library von allen Sprachen aus genutzt werden kann und dass z.B. eine mit Visual Basic erstellte Bibliothek
auch von C# oder von Delphi .NET aus genutzt werden kann. Selbst eine in Visual Basic erstellte Klasse kann deshalb beispielsweise über C# erweitert werden. Allerdings müssen sich dann auch
die Entwickler an bestimmte Dinge halten. So unterscheidet Delphi beispielsweise nicht zwischen Groß- und Kleinschreibung. Möchten Sie mit Delphi ein C#-Modul nutzen, müssen dort alle
Bezeichner eine andere Schreibweise besitzen, die unabhängig von der Groß-/Kleinschreibung ist.
Die CLS definiert also die Grundmenge von Eigenschaften, die eine Sprache mitbringen muss, um einerseits mit Modulen, die in anderen Sprachen geschrieben wurden, zu kommunizieren und
andererseits durch die CLR ausführbar zu sein. Eine Sprache kann aber über die CLS hinaus weitere Features besitzen.
11.2.2 Microsoft Intermediate Language
Durch das Kompilieren von Sourcecode einer .NET-Sprache entsteht ein Zwischencode, der so genannte IL-Code. IL steht hierbei für Intermediate Language (Zwischensprache) und wird auch
als MSIL (Microsoft IL) bezeichnet. Im Zuge seiner Standardisierung wird er nun auch CIL (Common IL) genannt. Die Besonderheit an diesem Zwischencode ist, dass er unabhängig vom konkreten Betriebssystem
ist. Soll IL-Code zur Ausführung gebracht werden, ist eine Übersetzung in nativen Code des spezifischen Betriebssystems bzw. des Prozessors notwendig. Dazu wird der IL-Code bei der
Ausführung durch einen JIT (Just In Time-Compiler - auch Jitter) in Code des ausführenden Betriebssystems übersetzt.
INFO
Unter Windows wird der MSIL-Code in einer
*.exe-Datei verpackt. Diese Dateien haben einen Aufbau, der durch das PE-Format (portable executable,
siehe auch
http://de.wikipedia.org/wiki/Portable_Executable) definiert ist. An einen Standard-PE-Header, der die Ausführung der Datei ohne das .NET Framework erlaubt,
schließen sich ein CLR-Header und ein CLR-Datenteil (MSIL-Code und Metadaten) an.
11.2.3 Just In Time-Compiler
Eine native Anwendung enthält bereits Anweisungen für einen konkreten Prozessor und ein bestimmtes Betriebssystem.
Nach dem Kompilieren von Sourcecode entsteht unter .NET keine nativ ausführbare Anwendung, sondern es wird der bereits erwähnte IL-Code erzeugt. Dies hat den Vorteil, dass eine
.NET-Anwendung (theoretisch) auf unterschiedlichen Betriebssystemen laufen kann. Ein JIT führt die Übersetzung des IL-Codes in den nativen Code durch. Für jede zu unterstützende Plattform
ist also ein JIT notwendig. Umgekehrt kann der IL-Code unter jeder Plattform ausgeführt werden, für die ein JIT vorliegt. Als einzige Einschränkung darf der IL-Code keine plattformspezifischen
Bibliotheken und Funktionen nutzen (z.B. den Zugriff auf die Registry unter Windows) und keine plattformspezifischen APIs verwenden (z.B. Unmanaged Code um auf bestimmte Hardwarekomponenten zuzugreifen).
Eine sehr interessante Eigenschaft des JITs ist, dass er eine Anwendung immer optimal für das aktuelle System übersetzt. So kann in diesem Fall auch Rücksicht auf die verwendete Hardware
(Prozessor, Grafikkarte) genommen werden und eine dafür geeignete Optimierung erfolgen.
Die Übersetzung durch den JIT schließt außerdem eine Verifizierung ein, welche die Typsicherheit und weitere sicherheitsrelevante Dinge prüft (darf die Anwendung in diesem Verzeichnis ausgeführt
werden, darf sie auf die Festplatte oder das Netzwerk zugreifen usw.). So hat eine über das Internet geladene Anwendung z.B. weniger Zugriffsrechte auf das lokale System als eine direkt
auf dem System gestartete Anwendung. Die Übersetzung wird für jede Codestelle maximal einmal durchgeführt und dies auch erst bei Bedarf. Wird der Code später erneut benötigt, kann auf den bereits
übersetzten Code zurückgegriffen werden.
INFO
Über das Tool
Ngen.exe (Native Image Generator) kann eine .NET-Anwendung dauerhaft in ein natives Format übersetzt werden.
Dies sollte aber immer auf dem Rechner erfolgen, auf dem die Anwendung später auch ausgeführt wird (denken Sie an die Optimierungsmöglichkeiten). Eine Anwendung kann jetzt schneller ausgeführt
werden, da die Übersetzung durch den JIT wegfällt. Weitere Informationen entnehmen Sie der Hilfe zum Stichwort
Ngen.
11.2.4 Speicherverwaltung
In vielen Programmiersprachen sind Sie selbst für die Beschaffung und Anforderung sowie die Freigabe von Speicher verantwortlich. Dadurch kann es zu verschiedensten Problemen kommen. Vergessen Sie
beispielsweise die Speicherfreigabe sehr häufig, führt dies bei großen Speichermengen dazu, dass bald kein Speicher mehr zur Verfügung steht.
Unter .NET wird zum Speichermanagement der Garbage Collector (GC) durch die CLR bereitgestellt. Bestehen auf einen Speicherbereich keine Verweise mehr (d.h. er kann nicht mehr über die
Anwendung erreicht werden), wird er vom GC eingesammelt und zur erneuten Verwendung bereitgestellt.
In der Abbildung 1.2 wird die Arbeitsweise schematisch gezeigt. Auf einen Speicherbereich existieren zwei Verweise. Zuerst wird der erste Verweis auf den Speicherbereich entfernt, dann der zweite.
Nachdem der Speicherbereich nicht mehr referenziert wird und somit auch nicht mehr erreichbar ist, wird er vom GC eingesammelt.
Abbildung 4.2: Arbeitsweise des Garbage Collectors
Für die Speicherbereinigung wird möglichst ein Zeitpunkt gewählt, bei dem die Anwendung nicht viel zu tun hat. Tritt dieser Fall nie ein, wird die Bereinigung nach ausgefeilten
Algorithmen durchgeführt. Damit nach der Bereinigung nicht zu viele kleine freie Speicherbereiche übrig bleiben, wird der freie Speicher ab und zu zusammengefasst.
INFO
Die Garbage Collection funktioniert nur mit Managed Code. Verwenden Sie in einer .NET-Anwendung Unmanaged Code, der nicht durch die CLR verwaltet wird, müssen Sie sich selbst um eine korrekte Speicherfreigabe kümmern.
Der GC läuft immer als Thread mit niedriger Priorität im Hintergrund einer Anwendung. Er kann sogar zirkuläre Referenzen auflösen und so Objekte beseitigen, die sich nur noch gegenseitig referenzieren,
aber selbst nicht mehr über die Anwendung erreichbar sind. Der Zeitpunkt des Aufrufs des GC und damit der genaue Zeitpunkt der Objektbeseitigung stehen nicht fest.
11.2.5 Die Klassenbibliothek
Was wäre ein Framework und eine Programmiersprache ohne eine mächtige Bibliothek an vorgefertigten Funktionen. Die .NET Class Library vereint sämtliche Typen (Klassen, Interfaces usw.),
welche die Grundlage aller Anwendungen des .NET Frameworks bilden. Die Typen sind in zahlreichen Namespaces (Namensräumen) organisiert, welche sie nach ihrem Anwendungsgebiet gruppieren.
Für die Klassenbibliothek existieren weiterhin die Begriffe Base Class Library (BCL) und Framework Class Library (FCL). Die BCL soll dabei eine Teilmenge der FCL darstellen, eine konkrete Information
dazu gibt es aber nicht. In der Regel ist einfach die gesamte Klassenbibliothek des .NET Frameworks gemeint.
Wegen des Common Type Systems und der Common Language Specification kann die Klassenbibliothek von allen Sprachen genutzt werden, die selbst CLS-konform sind und das CTS unterstützen.
Die Klassenbibliothek stellt unter anderem die folgende Funktionalität zur Verfügung:
Klassen zur Erzeugung von Fenstern und den darin verwendeten Steuerelementen wie Schaltflächen, Listen und Bäumen
Ein- und Ausgabefunktionalität von Daten, z.B. in Dateien oder auf die Konsole
Datenbankzugriff über ADO.NET
XML-Verarbeitung
Prozesssteuerung
Netzwerkkommunikation
Zugriff auf unterschiedlichste Datenspeicher mittels LINQ
Zusätzliche Frameworks wie WPF, WCF und WF für die Entwicklung anspruchsvoller grafischer Anwendungen, zur Kommunikation und die Erstellung von Arbeitsabläufen
11.2.6 Die Sprache C#
Mit dem Erscheinen des .NET Frameworks 1.0 im Jahre 2000 wurde auch eine neue, objektorientierte Sprache bereitgestellt, C#. Sie hat Ihren Ursprung in verschiedenen Elementen anderer Sprachen
wie C/C++ und Java und ist sogar standardisiert (http://www.ecma-international.org/publications/standards/Ecma-334.htm). Die umfangreiche Spezifikation kann als PDF-Datei
geladen werden. Woher der Name C# tatsächlich stammt, ist nicht sicher. Einige meinen, er kommt vom Ton "cis" aus der Musikwelt, andere sind der Auffassung, er ist die Übersetzung
von see sharp (scharf sehen). Es könnten natürlich auch die gegeneinander verschobenen Pluszeichen von C++ sein.
Bezüglich der Leistungsfähigkeit ist C# allen anderen aktuellen Sprachen ebenbürtig. Die ewigen Streitereien und Vergleiche, wer besser, einfacher, objektorientierter usw. ist, werden weder
hier noch an anderer Stelle in diesem Buch fortgeführt. Jede Programmiersprache hat in einem bestimmten Umfeld ihre Vorzüge. Allerdings liegt dies oft weniger an der Sprache, sondern an den Eigenschaften
des verwendeten Frameworks und an dem Umfang der mitgelieferten Bibliotheken. Manchmal kann es durchaus sein, dass sich mehrere Sprachen eignen. In diesem Fall müssen Sie weitere Aspekte hinzuziehen wie
eventuell benötigte Bibliotheken von anderen Herstellern und natürlich die Erfahrung der Programmierer.
11.3 Die Installation des .NET Frameworks
Der Start mit einer neuen Software beginnt immer mit der Installation (einige sollen ja vorher sogar die Dokumentation oder das Handbuch lesen). Diese soll und kann nicht bis ins kleinste
Detail beschrieben werden, da sich . Dennoch sollen ihr einige Zeilen gewidmet werden. Die Startseite für Informationen zum .NET Framework ist der
URL http://msdn2.microsoft.com/de-de/netframework/default.aspx. Von hier aus gelangen Sie über den Link .NET Framework 4.0 (Standalone) (Abbildung 1.3) im linken
Bereich der Webseite zum Download des .NET Frameworks 4.0. Der darunter befindliche Web Installer lädt die Installationsdaten dagegen direkt aus dem Internet.
Abbildung 1.3: Link zu den Download-Dateien
Um die Dateien zu laden und zu installieren:
Sie benötigen eines der folgenden Betriebssysteme für die Installation: Windows XP SP3, Windows Server 2003 SP2, Windows Vista SP1, Windows Server 2008, Windows 7.
Voraussetzung für die erfolgreiche Ausführung der Setup-Dateien ist weiterhin ein vorhandener Windows Installer in der Version 3.1. Dieser kann bei Bedarf von der
Download-Seite des .NET Frameworksbezogen werden. Fehlen weitere Dateien werden Sie darauf hingewiesen.
Laden Sie entweder den vollständigen Installer (Größe ca. 48MB, dotNetFx40_Full_x86_x64.exe) oder den WebInstaller (Größe ca. 1MB, dotNetFx40_Full_setup.exe).
Führen Sie den entsprechenden Installer aus und folgen Sie den Anweisungen.
Nach der Installation stehen die folgenden Verzeichnisse zur Verfügung (abhängig von Ihren Angaben).
| VerzeichnisInhalt |
[WindowsDir]\assembly | Globaler Assembly Cache (GAC) |
[WindowsDir]\Microsoft.NET\Framework\v4.0.30319 | Runtime-Komponenten und Anwendungen wie z.B. der C#-Compiler sowie Konfigurationsdateien |
Tabelle 1.1: Verzeichnisübersicht
Wenn Sie später nur mithilfe des .NET Framework sowie dem Windows SDKs Anwendungen erstellen möchten, sollten Sie die deren bin-Verzeichnisse in Ihre PATH-Umgebungsvariable aufnehmen.
Wenn Sie mit dem Visual Studio arbeiten, ist dies allerdings nicht notwendig, da in diesem Fall die Pfade automatisch ermittelt werden.
INFO
Die Webseiten, Links und Installationen zu den jeweiligen Frameworks ändern sich relativ häufig. Sehen Sie deshalb die hier gegebenen Anleitungen nur als Hilfestellung an,
aber niemals als Referenz.
11.4 Interessante Webseiten
Zum .NET Framework finden Sie sehr viele interessante Webseiten. Einige davon werden ohne Angabe einer Wertigkeit in der folgenden Tabelle aufgeführt. Alle Angaben sind natürlich ohne Gewähr.
URL | Inhalt |
http://www.codeproject.com/ | Sourcecodes und Artikel, nicht nur über .NET |
http://www.codezone.de/ | Deutschsprachige Entwicklerseite |
http://www.c-sharpcorner.com/ | Artikel und Informationen rund um C# |
http://code.msdn.microsoft.com | Sourcecode für verschiedenste Probleme |
http://www.icsharpcode.net/ | Kostenfreie Entwicklungsumgebung SharpDevelop |
http://msdn2.microsoft.com/de-de/netframework/default.aspx | Microsofts Startseite zum .NET Framework |
http://msdn.microsoft.com/de-de/windows/bb980924.aspx | Informationen und Downloads zum Windows SDK |
http://www.mono-project.com/Main_Page | Mono-Projekt für den Multiplattform-Einsatz von .NET |
http://www.microsoft.com/germany/express/default.aspx | Kostenfreie Express-Versionen des Visual Studios 2010 (C#, Visual Basic, C++, Web) |
http://it-republik.de/dotnet/ http://www.dotnetpro.de/ | Magazine zum Thema .NET |
Tabelle 1.2: Übersicht interessanter Webseiten zum Thema .NET
11.5 Übungsaufgaben
Aufgabe 1
Erklären Sie die Abkürzungen IL, CLS und CLR mit einem Satz.
Aufgabe 2
Wie wird eine .NET-Anwendung erstellt und ausgeführt.
Aufgabe 3
Wer ist für die Speicherverwaltung im .NET Framework verantwortlich?
Aufgabe 4
Was ist der Vorteil der Verwendung eines JIT?