Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

Visual C# 2012 Grundkurs

C#-Anwendungen

Testen Sie unsere 2021 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
C#-Anwendungen basieren auf einer Common Language Infrastructure. Dabei kommuniziert die Anwendung nicht direkt mit dem darunterliegenden Betriebssystem. Diese Aufgabe wird von einer .NET-Runtime-Umgebung übernommen.

Transkript

Die Entscheidung für C# als Sprache ist eine sehr weitreichende Entscheidung. Sie definieren damit nämlich nicht nur die Art und Weise, wie Sie programmieren wollen, sondern Sie treffen eine Entscheidung der Architektur, also der Plattform, auf der Sie arbeiten wollen. C# ist ein Standard, eingereicht und verabschiedet bei der ECMA, das ist eine europäische Standardisierungsorganisation, und da ist festgelegt, dass C# für etwas kompiliert, was sich Common Language Infrastructure nennt. Und diese Common Language Infrastructure ist ein eigener Standard für sich. Es ist vielleicht auch mal ganz interessant zu sehen, wie man diese Standards finden kann. Also geben Sie in Google einfach mal ein "C# Standard", da ist gleich mal der erste Standard, ECMA 334, der eben die Sprache C# beschreibt. Wenn man ein kleines bisschen herunter scrollt auf der Seite, dann findet man ein Link auf ein PDF-Dokument, und dieses Dokument beschreibt komplett die Sprache C# und ihre Abhängigkeiten zur Common Language Infrastructure. Wenn wir schon mal da sind, dann gehen wir mal in diese Standards-List und suchen einmal diesen C# Standard 334. Hier haben wir ihn. Gleich der Nachbar, der Standard daneben, ist die Common Language Infrastructure. Hier ist jetzt auch noch einmal ein Link zu der Seite. Es ist also, wie gesagt, der Standard mit der Nummer 335. Dort finden Sie verschiedene PDF-Dokumente, die Ihnen diesen Standard beschreiben. Ich habe die Dokumente jetzt mal runtergeladen. Ich will ganz kurz mal in eines dieser Dokumente reingehen. Das ist der Standard für die Sprache C#. Hier können Sie sich nach Herzenslust über alle Konstrukte der Sprache C# informieren. Diese Common Language Infrastructure ist also jetzt ein Sammelsurium an Technologien, die Sprachen unterstützen können. Es gibt verschiedene Sprachen, die darauf aufsetzen können. Einige der bekanntesten: Visual Basic, .NET, F# — eine ziemlich ausgeflippte Sprache, von Microsoft Research seinerzeit entwickelt. Es gibt COBOL, es gibt Python, es gibt alle möglichen Sprachen, die auf der CLI aufsetzen. Diese CLI, als Standard, kann jetzt von verschiedenen Interessengruppen, Personen, Firmen implementiert werden. Microsoft hat natürlich seine eigene Implementierung, die nennt sich Microsoft .NET. Aber die haben nicht nur eine gemacht. Die haben mit Silverlight eine komplett eigenständige Implementierung von .NET nochmal vorgenommen. Ebenso scheint es mit der Programmierumgebung der Xbox zu sein. Das Microsoft Compact Framework, das ist die abgespeckte Version des Standards. Es gibt eine Implementierung, die nennt sich Mono, die ist völlig unabhängig von Microsoft und bringt also jetzt die im Standard beschriebenen Technologien auf andere Plattformen, wie z.B. Linux, Mac OS oder die mobilen Plattformen, Android und iOS. Ich kann sagen, es ist durchaus eine Erwägung wert, mobile Applikationen, die auf Android oder iOS laufen sollen mit einer dieser Monoimplementierungen für diese Betribessyssteme zu entwickeln. Das kann durchaus Sinn machen. Microsofts .NET ist eine sehr umfangreiche Implementierung dieser Standards, die natürlich wesentlich mehr enthält als diese Standard geschrieben hat. Der C#-Compiler ist ein Bestandteil eben dieser Implementierung, ein notwendiger Bestandteil natürlich auch, in die Implementierung der Common Language Infrastructure. Aber darüber hinaus gibt es auch noch eine sehr ausgiebige Klassenbibliothek. Bei .NET 3.5 waren es irgendwie 23.000 Klassen. Und mit jeder .NET Version, die rauskommt, werden es mehr. Es sind verschiedenste Klassen für alle Zwecke, die Sie für Ihre Applikationen einsetzen können. Das macht Microsoft .NET als Plattform natürlich sehr interessant und attraktiv. Dann gibt es diese Global Assembly Cache, wenn Sie eine Applikation kompilieren. Die Komponenten, aus denen diese Applikation besteht, nennen sich Assemblies. Die können Sie in diese Global Assembly Cache tun, so dass die Komponente für verschiedenste Applikationen zur Verfügung steht. Dann gibt es eine ganze Reihe an Tools zur Verwaltung dieses Assemblycache und so Tools wie "Ilasm" oder "Ildasm". Wir werden in der Folge noch mal diesen "Ilasm" kennenlernen, wo man ein erzeugtes Assembly disassemblieren kann. Die Tatsache, dass Anwendungen, die in C# geschrieben werden, auf einer Common Language Infrastructure basieren, lässt erahnen, dass Anwendungen, die mit C# geschrieben werden und dann ausgeführt werden, nicht direkt mit dem darunterliegenden Betriebssystem kommunizieren, sondern es liegt etwas dazwischen. Im Fall von .NET ist es die .NET-Runtime. Sie hat verschiedene Komponenten zur Ausführung der Applikationen und sie bildet das Betriebssystem für ihre Applikationen ab. Diese Abbildung, die ist nicht ganz vollständig, das ist klar. Nicht alle Funktionalität von einem Betriebssystem kann durch einen Wrapper, der über diesem Betriebssystem liegt, abgebildet werden. Es wird immer ein Stück bleiben, was jetzt nicht abgebildet ist. Und diese nicht-abgebildeten Stücke, für die gibt es dann Technologien wie man sie, selbst wenn man sie benötigt, in das .NET-Framework integrieren kann. Jetzt gehen wir nun mal ganz zurück und schauen uns an, wie früher Applikationen erzeugt wurden. Also man hat in irgendeiner Hochsprache wie C oder C++ einen Code geschrieben. Der Compiler hat diesen Code kompiliert und herausgekommen ist Maschinencode, den Sie direkt auf der Maschine ausführen konnten. Dieser Maschinencode hat dann direkt mit dem Betriebssystem kommuniziert, wie man das hier sehen kann. Also das heißt, Sie haben den Code kompiliert, den Maschinencode, haben Sie ausgeliefert an den Kunden, auf der Kundenmaschine wird er ausgeführt und interagiert jetzt mit dem Betriebssystem. Das hat Vorteile in dem Sinn, dass nichts zwischen Ihren Anwendungen und dem Betriebssystem liegt. Das ist alles sehr direkt und damit sehr schnell. Der Nachteil daran ist aber, dass man beim Kompilieren ja nicht wissen kann, auf welcher Umgebung die Applikation laufen wird. Man kann vielleicht gewisse Mindestanforderungen stellen, auf denen die Applikation laufen soll, wie die Betriebssystem-Version und vielleicht auch so eine Mindestanforderung an den Speicherbedarf oder den Prozessor. Aber im Prinzip kann man zu einer Zeit, zu der meine Applikation kompiliert, nicht wissen, welche Prozessoren Morgen auf den Markt kommen und welche Optimierungen die mitbringen. Noch schlimmer sieht es aus, wenn Sie irgendwelche Services haben wollen, die zwischen der Anwendung und dem Betriebssystem vermitteln. Ich erinnere mich da z. B. an die Kopfstände, die man seinerzeit gemacht hat, um mit Hilfe von COM transaktionale Services zwischen Applikationen und den Transaction-Server zu bringen, so dass automatisch Transaktionen erfasst werden konnten. Also, man tut sich sehr, sehr schwer bei diesem alten Modell einer Interception, so nennt sich das nämlich, irgendeinen Layer zwischen Ihre Applikation und dem Betriebssystem zu bringen, und dann irgendwelche Anfragen Ihrer Applikation abzufangen, um die z. B. zu loggen oder um sie transaktional zu erfassen oder irgendwelche Sicherheitstests z. B auszuführen. All dies ist mit dem herkömmlichen Prozessmodell überhaupt nicht machbar. Hier sieht man jetzt die Kompilierung in .NET. Sie haben also wieder Ihren Hochsprachen-Code, diesmal in C#. Der Compiler nimmt diesen Code und kompiliert ihn zu etwas. Es ist so ein Zwischending zwischen einer Hochsprache und dem Assembler. Das nennt sich "intermediate language", eben weil es dazwischen liegt, zwischen den Welten. Und diesen Intermediate-Language-Code, den liefern Sie aus. Wenn der Intermediate-Language-Code jetzt auf der Zielmaschine ausgeführt wird, dann muss er erst in den Maschinencode übersetzt werden. Dazu ist ein sogenannter Just-In-Time-Compiler da. Der kompiliert also jetzt Ihren IL-Code in Maschinencode und dieser Maschinencode wird jetzt ausgeführt. Aber er interagiert nicht direkt mit dem Betriebssystem, sondern er läuft verwaltet, in der .NET-Runtime. Jetzt werden Sie sich vielleicht fragen, wie das mit dieser Just-In-Time Kompilierung funktioniert. "Wird denn jetzt jedes Mal, wenn ich so eine Applikation aufrufe, dann erstmal 10 Sekunden fürs Kompilieren der Applikation verbracht, oder wie muss man sich das vorstellen?" Das ist also nicht so, sondern das ist nach Methoden, also nach ausführbaren Einheiten sortiert. Eine Methode in .NET ist eine aufrufbare Einheit, die Anweisungen enthält, IL-Anweisungen. Und so eine Methode, wenn die von einem Aufrufer aufgerufen wird, dann nimmt der Chip-Compiler die Methode und macht daraus Maschinencode. Und der kann jetzt ausgeführt werden. Ich will das in dieser Grafik nochmal ein bisschen präzisieren. Wir haben also einen Aufrufer. Das kann z. B. das Betriebssystem sein, weil es gerade die Methode Main von meiner neuen C#-Applikation aufrufen will. Wie auch immer, dieser Aufruf hat jetzt die Adresse meiner Methode und ruft diese Adresse direkt auf. In meiner Methode ist so ein kleines Stück Maschinencode drinnen, dieses Stück nennt sich "Stab". Und dieser Stab enthält nichts anderes als einen Sprung, hin zu einem anderen Code, der jetzt im JIT-Compiler liegt. Der JIT-Compiler wird dadurch jetzt eben zum Leben erweckt, nimmt die Methode und konvertiert sie in Maschinencode, indem er sie kompiliert. Und jetzt kann er die Ausführung des Codes an diesen Maschinencode weiterreichen. Der Aufrufer bekommt also gar nicht mit, dass da dazwischen der Compiler läuft. Die produzierte Methode, die fertig kompilierte Methode, kommt jetzt in einen Cache, die wird aufgehoben, auf gut Deutsch, und bei dem letzten Aufruf dieser Methode, brauchen wir den JIT-Compiler nicht mehr, sondern der Aufruf wird direkt sofort an den kompilierten Maschinencode weitergeleitet. Die .NET-Runtime liegt also jetzt zwischen Ihrer Applikation und dem Betriebssystemen und stellt verschiedene Services zur Verfügung. Und den ersten Service haben Sie bereits kennengelernt, nämlich die Just-in-Time-Kompilierung. Das heißt, Ihre Anwendung will laufen, und die .NET Runtime stellt sicher, dass Ihre Anwendung für den Prozessor, auf dem sie gerade läuft, kompiliert wird. Es gibt jetzt noch mehr Services, wie z. B. die Sicherheit und die Speicherverwaltung. Ich möchte hier nochmal die Sicherheit ein bisschen rausgreifen. In Windows ist es z. B. so, dass die Sicherheit immer an so einem Securitytoken hängt. Der Securitytoken ist eine Eigenschaft des Threads, also des Programmablauf-Fadens, in dem eine Anwendung läuft. Der Thread erbt den Securitytoken vom Prozess. Normalerweise ist es so, dass ein Benutzer einen Prozess startet. Der Prozess erbt den Securitytoken vom Benutzer und seine Threads erben den Securitytoken vom Prozess. Diese Threads führen also jetzt irgendwelche Anweisungen aus, und was sie im Betriebssystem dürfen oder nicht dürfen hängt also praktisch immer vom Benutzer ab, der diesen Prozess gestartet hat. Man hat festgestellt, dass dieses Sicherheitsmodells zwar sehr leistungsfähig  ist, aber einfach nicht alle Anwendungsfälle abdecken kann, die in Sachen Sicherheit auf uns zukommen können. Ich gebe mal ein Beispiel: Was ist, wenn Sie eine Anwendung aus dem Internet herunterladen? Da wäre es ja jetzt vielleicht ganz interessant, die Rechte, die so eine Anwendung hat, beschränken zu können. Einfach schon mal aufgrund der Tatsache, aus welcher Zone diese Anwendung stammt. Nämlich aus der unsicheren Internetzone. Und genau das ist mit der .NET-Runtime möglich. Die .NET-Runtime kann also jetzt eine Komponente Ihrer Anwendung untersuchen, kann sehen, von wem ist die? Wer hat die signiert? Solche Komponenten lassen sich nämlich signieren. Und entsprechend, aufgrund dieser Signatur können z. B. Entscheidungen getroffen werden, was diese Anwendungen dürfen, und was sie nicht dürfen. Ob sie überhaupt geladen werden, ob sie ausgeführt werden, ob sie Dateizugriffe ausführen dürfen etc. pp. All das lässt sich jetzt mit so einem Sicherheitsservice steuern. Sie sehen also, es kann Vorteile haben, wenn zwischen Ihrer Applikation und im Betriebssystem eine Serviceschicht liegt. Und .NET-Runtime versteht sich dort auch genauso. Das Ausführungsmodell für Anwendungen unter .NET unterscheidet sich als sehr stark von dem, was wir vom traditionellen Ausführungsmodell kennen. Das hat Vor- und Nachteile: Die Vorteile liegen darin, dass die JIT-Kompilierung eine Anwendung immer auf die jeweilige CPU auslegen kann, auf der die Anwendung läuft. Ist es eine sehr fortschrittliche CPU, können vielleicht Optimierungen eingebaut werden, die auf anderen Systemen gar nicht möglich wären. Und die Anwendungen laufen immer in einer verwalteten Umgebung. Services, die, die .NET Runtime zur Verfügung stellt, eben wie die Code Access Security oder eine automatische Speicherverwaltung, machen das Leben des Programmierers wesentlich einfacher. Der Nachteil ist, dass der Übertritt in die jeweiligen Schichten, also von der Anwendung in den JIT-Compiler und von dem JIT-Compiler wieder in den Maschinencode, rein vom Maschinencode in das Betriebssystem usw., dass das alles Overhead ist, die ein bisschen Zeit kostet. Den meisten Overhead verursacht natürlich die JIT-Kompilierung selbst, aber das könnte man ausgleichen, wenn es denn nun wirklich mal zeitkritisch wird. Dazu gibt es im .NET-Framework ein Tool, das nennt sich NGen. Und dieses Tool folgt der Idee, dass die Ergebnisse, die der JIT-Compiler während des Ausführens einer Applikation erzeugt, also das heißt den Maschinencode, dass man den irgendwo in einer Datei ablegen könnte und beim nächsten Start der Anwendung wieder verwenden könnte. NGen ist genau so ein Tool. Das macht eine Kompilierung nach allen Regeln der Kunst des JIT-Compilers und erzeugt daraus eine native Datei, die sozusagen Maschinencode für den jeweiligen Prozessor des Systems enthält, der denn auf dem System ausführbar ist. Dieses NGen könnten Sie jetzt z. B. als Bestandteil der Installation Ihrer Applikation mitliefern. Dann könnten eben zeitkritische Teile Ihrer Applikation mit NGen direkt während der Installation in Maschinencode überführt werden und dieser Maschinencode könnte dann zeitoptimiert ablaufen, ohne die Verzögerung durch die JIT-Kompilierung. Es gibt also einige Vorteile der Verwendung von Microsoft.NET. Der größte Vorteil ist in meinen Augen immer noch die Klassenbibliothek. Sie enthält mittlerweile zigtausende an Klassen für die verschiedensten Zwecke, die Sie dann als Software-Entwickler verwenden können. Unter anderem lässt es keine Wünsche mehr offen von dem, was Sie an Services vom Betriebssystem in Anspruch nehmen können. Es gibt Klassen für: Collections, Sammlungen von Objekten in Listen, in Stacks, in Thread-save und Thread-unsave. Sie können Netzwerkfunktionen auf den verschiedenen Ebenen verwenden, bis hoch zum WebRequest- und WebResponse-Objekt, mit dem Sie eine ganze Webseite mit einer Programmzeile laden können, wenn Ihnen danach ist. Aber auch runter bis hin zu den Sockets, wo man auf Socketebene Netzwerkverbindungen erstellen und beeinflussen kann; für Input/Output, für XML, für Datenbankzugriffe, für Webanwendungen, Webservices. Dann gibt es 2 komplette Bibliotheken für Desktop-Applikationen, für die Benutzeroberfläche von Desktop-Applikationen. Windows Forms, die im Prinzip eine Art Wrapper sind, um die Windows-Controls. Und dann gibt es etwas Moderneres, was einen völlig neuen Ansatz verfolgt: Das ist WPF, oder Windows Presentation Foundation, eine Bibliothek für Benutzeroberfläche, die sehr leistungsfähig ist. Das alles sind ein Haufen Gründe, sich für .NET als Plattform zu entscheiden. Und wenn Sie das getan haben, Sie sagen: "Diese Plattform, die möchte ich verwenden, die ist es, die bringt es für meine Applikation", dann ist die Sprache C# die Sprache Ihrer Wahl.

Visual C# 2012 Grundkurs

Schreiben Sie eigene Programme in C# und lernen Sie dazu alle Schlüsselwörter und die meisten Konstrukte kennen, um sicher mit dieser Programmierspreche umzugehen.

7 Std. 1 min (44 Videos)
Derzeit sind keine Feedbacks vorhanden...
 

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!