Häufig gestellte Fragen zu Microsoft .NET Framework

Veröffentlicht: 01. Feb 2001 | Aktualisiert: 08. Nov 2004

Dieses Dokument enthält häufig gestellte Fragen zu Microsoft .NET und Microsoft .NET Framework.

Auf dieser Seite

Konzeptuelle Fragen Konzeptuelle Fragen
Technische Fragen zur Laufzeit Technische Fragen zur Laufzeit
Assemblies Assemblies
Weitergabe und Isolation einer Anwendung Weitergabe und Isolation einer Anwendung
Garbagecollection Garbagecollection
Remoting  Remoting
Interoperabilität Interoperabilität
Sicherheit Sicherheit

Konzeptuelle Fragen

Was ist .NET?

Einfach ausgedrückt ist Microsoft .NET die Strategie von Microsoft für die Weitergabe von Software als Dienst. Ausführliche Informationen finden Sie in einem Whitepaper zu diesem Thema.

In einem Auszug aus diesem Dokument werden die wichtigsten Aspekte von .NET beschrieben:

  • Microsoft .NET-Plattform
    Enthält die .NET-Infrastruktur und Tools für die Erstellung und den Betrieb einer neuen Dienstgeneration, .NET-Benutzerführung für die Aktivierung von komplexen Clients, .NET-Bausteindienste und .NET-Gerätesoftware für die Aktivierung einer neuen Generation intelligenter Internetgeräte.

  • Microsoft .NET-Produkte und -Dienste
    Enthält Microsoft Windows.NET (mit integrierter Reihe von Bausteindiensten), MSN.NET, persönliche Abonnementdienste, Microsoft Office.NET, Microsoft Visual Studio.NET und Microsoft bCentral™ für .NET.

  • .NET-Dienste von Drittanbietern
    Viele Partner und Entwickler haben die Möglichkeit, auf der Grundlage der .NET-Plattform firmeninterne und vertikale Dienste zu erstellen.

In diesem Dokument werden die Fragen zu .NET Framework, einem Teil der Infrastruktur der .NET-Plattform, beantwortet. Lesen Sie die nächste Frage, wenn Sie mehr über .NET Framework erfahren möchten.

Was ist .NET Framework?

.NET Framework ist eine Umgebung für die Erstellung, Weitergabe und Ausführung von Webdiensten und weiteren Anwendungen. Es besteht aus drei wichtigen Komponenten: Common Language Runtime (CLR, gemeinsame Sprachlaufzeit), Frameworkklassen und ASP.NET.

Wird .NET Framework nur zum Erstellen von Websites verwendet?

Mit .NET Framework können Sie erstklassige Webanwendungen erstellen. Sie können mit .NET Framework aber auch alltägliche Anwendungen erstellen. Wenn Sie (mit ATL/COM, MFC, Microsoft Visual Basic oder Microsoft Win32) Windows-Software schreiben, bietet .NET bei der Erstellung von Anwendungen viele Vorteile. Wenn Sie Websites entwickeln, verfügt .NET Framework über viele interessante Möglichkeiten, z.B. ASP.NET.

Wo erhalte ich das .NET Framework SDK?

Sie können die Beta 1-Version des .NET Framework SDKs jetzt unter MSDN Online Downloads downloaden. Aufgrund der Größe bieten wir diese Betaversion als einteiligen Download (106 MB) und als elfteiligen Download an. Sie können auch die CD beim Microsoft Developer Store bestellen.

Auf welchen Plattformen kann .NET Framework ausgeführt werden?

Die Beta 1-Version kann unter Microsoft Windows 2000, Windows 95/98/ME und Windows NT 4.0 ausgeführt werden.

Es gibt außerdem eine Version von .NET Framework mit dem Namen .NET Compact Framework. Diese Version wurde für die Bereitstellung einiger Funktionen von .NET Framework für Geräte (z.B. Mobiltelefone und "Enhanced TV") entwickelt. .NET Compact Framework kann unter Windows CE und anderen eingebetteten Betriebssystemen ausgeführt werden.

Welche Programmiersprachen werden von .NET Framework unterstützt?

.NET Framework ist sprachneutral. Praktisch jede Sprache kann als Objektsprache des .NET Framework verwendet werden. Zurzeit können .NET-Programme in zahlreichen Sprachen erstellt werden, einschließlich C++, Microsoft Visual Basic.NET, JScript und C#, der neuesten Sprache von Microsoft. Außerdem ist für die Erstellung von .NET Framework-Anwendungen eine große Anzahl von Drittanbietersprachen verfügbar. Zu diesen Sprachen gehören COBOL, Eiffel, Perl, Python, Smalltalk u.a.

Welche Beziehung besteht zwischen .NET Framework und COM+-Diensten?

.NET Framework gibt Ihnen vollständigen Zugriff auf COM+-Dienste und erleichtert gleichzeitig die Erstellung von mit Diensten versehenen Komponenten.

.NET Framework-Komponenten können in eine COM+-Anwendung eingefügt werden. Dort können sie die automatischen Komponentendienste (z.B. Transaktionen, Objektpooling, Queued Components, Ereignisse usw.) nutzen.

Welche Beziehung besteht zwischen .NET Framework und DCOM?

DCOM ist die COM-Infrastruktur für prozessübergreifende Kommunikation. .NET Framework unterstützt für die prozessübergreifende Kommunikation zahlreiche Plug-In-Channel und Formatierer. Bei Übergängen zwischen verwaltetem und nicht verwaltetem Code verwendet .NET Framework die COM-Infrastruktur, v.a. DCOM. Alle Szenarios, die COM+-Dienste verwenden, verwenden Übergänge zwischen verwaltetem und nicht verwaltetem Code und daher standardmäßig DCOM. Für die prozessübergreifende Kommunikation, bei der die Interoperabilität wichtig ist, unterstützt .NET Framework außerdem SOAP (Simple Object Access Protocol).

Ist .NET Framework nur ein neuer Name für Windows DNA?

Nein. Windows DNA ist eine Architektur für die Erstellung eng aneinander gekoppelter, verteilter Webanwendungen. Da die Anforderungen in verteilten Anwendungen sich änderten und lose gekoppelte Prinzipien erforderlich wurden, entwickelte Microsoft die .NET-Architektur. .NET Framework ist Teil der .NET-Architektur.

Technische Fragen zur Laufzeit

Terminologie

Was ist die Common Language Runtime (CLR)?

Common Language Runtime ist das Ausführungsmodul für .NET Framework-Anwendungen.

Es enthält zahlreiche Dienste, z.B.:

  • Codeverwaltung (Laden und Ausführung)

  • Isolation des Anwendungsarbeitsspeichers

  • Überprüfung der Typsicherheit

  • Konvertierung von IL (Intermediate Language) in systemeigenen Code

  • Zugriff auf Metadaten (erweiterte Typinformationen)

  • Verwalten des Arbeitsspeichers für verwaltete Objekte

  • Erzwingung von Codezugriffssicherheit

  • Ausnahmebehandlung, einschließlich sprachübergreifender Ausnahmen

  • Interoperabilität zwischen verwaltetem Code, COM-Objekten und bereits bestehenden DLLs (nicht verwalteter Code und nicht verwaltete Daten)

  • Automatisierung des Objektlayouts

  • Unterstützung für Entwicklerdienste (Profilierung, Debugging usw.)

Was ist das Common Type System (CTS)?

Das Common Type System (gemeinsames Typsystem) ist ein in Common Language Runtime integriertes vielschichtiges Typsystem, das die in den meisten Programmiersprachen vorkommenden Typen und Operationen unterstützt. CTS unterstützt die vollständige Implementierung zahlreicher Programmiersprachen.

Was ist die Common Language Specification (CLS)?

Die Common Language Specification (gemeinsame Sprachspezifikation) ist eine Gruppe von Konstrukten und Einschränkungen, die Richtlinien für Bibliotheken- und Compilerentwickler bilden. Bibliotheken können für jede Sprache, die CLS unterstützt, und die Sprachen, die untereinander integrierbar sind, umfassend verwendet werden. Die Common Language Specification ist ein Teil von CTS. Die Common Language Specification ist für Anwendungsentwickler wichtig, die Code schreiben, der von anderen Entwicklern verwendet werden soll. Wenn Entwickler öffentlich zugängliche APIs entwerfen und dabei die Richtlinien von CLS befolgen, können diese APIs problemlos von allen anderen Programmiersprachen verwendet werden, die Common Language Runtime verwenden sollen.

Was ist die Microsoft Intermediate Language (MSIL)?

MSIL ist der von der CPU unabhängige Anweisungssatz, in den .NET Framework-Programme kompiliert werden. MSIL enthält Anweisungen zum Laden, Speichern, Initialisieren und Aufrufen von Methoden auf Objekten.

Gemeinsam mit Metadaten und dem CTS ermöglicht MSIL eine echte sprachübergreifende Integration.

Vor der Ausführung wird MSIL nicht interpretiert, sondern in Maschinencode konvertiert.

Was ist verwalteter Code, was sind verwaltete Daten?

Verwalteter Code ist Code, der zum Ansprechen der Dienste von Common Language Runtime (siehe "Was ist die Common Language Runtime?") geschrieben wurde. Dafür muss der Code ein Mindestmaß an Informationen (Metadaten) zur Laufzeit enthalten. Der gesamte C#-, Visual Basic.NET- und JScript.NET-Code wird standardmäßig verwaltet. Visual Studio.NET C++-Code wird nicht standardmäßig verwaltet, der Compiler kann jedoch verwalteten Code erzeugen, indem ein Befehlszeilenschalter (/CLR) angegeben wird.

Eng verwandt mit verwaltetem Code sind verwaltete Daten, d.h. Daten, die vom Garbagecollector der Common Language Runtime zugewiesen oder freigegeben werden. C#-, Visual Basic- und JScript.NET-Daten werden standardmäßig verwaltet. C#-Daten können jedoch als nicht verwaltet gekennzeichnet werden, indem bestimmte Schlüsselwörter verwendet werden. Visual Studio.NET C++-Daten werden standardmäßig verwaltet (selbst bei Verwendung des Befehlszeilenschalters). Bei der Verwendung von verwalteten C++-Erweiterungen kann jedoch eine Klasse als verwaltet gekennzeichnet werden, indem das Schlüsselwort __gc verwendet wird. Wie schon aus dem Namen ersichtlich ist, bedeutet dies, dass der Arbeitsspeicher für Instanzen der Klasse durch den Garbagecollector verwaltet wird. Zusätzlich wird die Klasse zu einem vollwertigen Mitglied der .NET Framework-Community und übernimmt deren Vorteile und Einschränkungen. Zu den Vorteilen gehört z.B. die Interoperabilität mit Klassen, die in anderen Sprachen geschrieben wurden (so kann z.B. eine verwaltete C++-Klasse von einer Visual Basic-Klasse erben). Zu den Einschränkungen gehört z.B., dass eine verwaltete Klasse nur von einer Basisklasse erben kann.

Assemblies

Was ist eine Assembly?

Eine Assembly ist der wichtigste Baustein einer .NET Framework-Anwendung. Sie ist eine Funktionalitätsauflistung, die als einzelne Implementierungseinheit (als eine oder mehrere Dateien) erstellt, versioniert und weitergegeben wird. Alle verwendeten Typen und Ressourcen sind so gekennzeichnet, dass der Zugriff entweder nur in ihrer Implementierungseinheit oder nur durch den Code außerhalb dieser Einheit erfolgt.

Assemblies werden durch ihr Manifest beschrieben, das integrierter Teil jeder Assembly ist.
Das Manifest

  • legt die Identität (als Textname), Version, Kultur und digitale Signatur der Assembly fest (wenn die Assembly für andere Anwendungen freigegeben werden soll).

  • definiert (durch Namen und Dateihash), aus welchen Dateien die Assemblyimplementierung besteht.

  • gibt neben den Typen und Ressourcen, aus denen die Assembly besteht, auch an, welche Typen und Ressourcen aus der Assembly exportiert werden.

  • führt die bei der Kompilierung vorhandenen Abhängigkeiten von anderen Assemblies auf.

  • gibt den Berechtigungssatz an, der für die ordnungsgemäße Ausführung der Assembly erforderlich ist.

Diese Informationen werden zur Laufzeit verwendet, um Verweise aufzulösen, versionsbindende Richtlinien zu erzwingen und die Integrität geladener Assemblies zu prüfen. Die Laufzeit kann für ein beliebiges ausgeführtes Objekt die Assembly ermitteln und finden, da jeder Typ im Kontext einer Assembly geladen wird. Assemblies stellen außerdem die Einheit dar, auf die die Sicherheitsberechtigungen für den Codezugriff angewendet werden. Der Identitätsbeweis jeder Assembly wird separat berücksichtigt, wenn ermittelt wird, welche Berechtigungen dem enthaltenen Code erteilt werden.

Da Assemblies selbstbeschreibend sind, werden eine Installation ohne Auswirkungen und die XCOPY-Weitergabe ermöglicht.

Was sind private Assemblies und gemeinsam genutzte Assemblies?

Eine private Assembly wird nur von einer Anwendung verwendet und im Installationsverzeichnis dieser Anwendung (bzw. einem Unterverzeichnis in diesem Verzeichnis) gespeichert. Eine gemeinsam genutzte Assembly wird von mehreren Anwendungen referenziert. Damit eine Assembly gemeinsam genutzt werden kann, muss sie ausdrücklich für diesen Zweck erstellt werden, indem sie einen kryptografisch starken Namen ("gemeinsam genutzter Name") erhält. Im Gegensatz dazu muss der Name einer privaten Assembly nur für die Anwendung eindeutig sein, in der sie verwendet wird.

Durch die Unterscheidung von privaten und gemeinsam genutzten Assemblies muss der Entwickler sich eindeutig dafür entscheiden, dass eine Assembly gemeinsam genutzt wird. Wenn private Assemblies an ein Anwendungsverzeichnis weitergegeben werden, können Sie gewährleisten, dass diese Anwendung nur mit den Komponenten ausgeführt wird, mit denen sie erstellt und weitergegeben wurde. Verweise auf private Assemblies werden nur lokal zum privaten Anwendungsverzeichnis aufgelöst.

Es gibt zahlreiche Gründe dafür, gemeinsam genutzte Assemblies zu erstellen und zu verwenden. Ein Grund könnte z.B. die Möglichkeit sein, Versionsrichtlinien auszudrücken. Dass gemeinsam genutzte Assemblies einen kryptografisch starken Namen haben, bedeutet nur, dass der Autor der Assembly weiß, wie eine neue Version dieser Assembly erstellt wird. Wenn Sie also eine Richtlinienanweisung schreiben, die besagt, dass Sie die neue Version einer Assembly übernehmen möchten, können Sie einigermaßen sicher sein, dass Versionsaktualisierungen vom Autor gesteuert und überprüft werden. Wenn dies nicht der Fall ist, müssen Sie sie nicht übernehmen.

Bei lokal installierten Anwendungen wird eine gemeinsam genutzte Assembly i.d.R. im globalen Assemblycache installiert (ein lokaler Cache mit Assemblies, die von .NET Framework verwaltet werden). Die wichtigste der Versionsverwaltungsfunktionen von .NET Framework ist, dass gedownloadeter Code nicht die Ausführung lokal installierter Anwendungen beeinträchtigt. Gedownloadeter Code wird in einem bestimmten Downloadcache abgelegt und ist auf dem Computer selbst dann nicht global verfügbar, wenn einige der gedownloadeten Komponenten als gemeinsam genutzte Assemblies erstellt wurden.

Alle mit .NET Framework gelieferten Klassen wurden als gemeinsam genutzte Assemblies erstellt.

Wenn ich eine gemeinsam genutzte Assembly erstellen möchte, ist dann der Aufwand zum Signieren und Verwalten von Schlüsselpaaren erforderlich?

Für die Erstellung einer gemeinsam genutzten Assembly ist die Verwendung von kryptografischen Schlüsseln erforderlich. Eigentlich ist bei der Erstellung der Assembly nur der öffentliche Schlüssel erforderlich. Compiler, die .NET Framework verwenden, bieten Befehlszeilenoptionen (oder verwenden benutzerdefinierte Attribute), um beim Erstellen der Assembly den öffentlichen Schlüssel anzugeben. Es ist allgemein üblich, eine Kopie des öffentlichen Schlüssels in einer Quelldatenbank aufzubewahren und mit Hilfe von Erstellungsskripts auf diesen Schlüssel zu verweisen. Bevor die Assembly weitergegeben wird, muss sie mit dem entsprechenden privaten Schlüssel vollständig signiert werden. Dies geschieht mit einem SDK-Tool namens SN.exe (Strong Name = starker Name).

Anders als Authenticode beinhaltet die Signatur mit einem starken Namen keine Zertifikate. Drittanbieter sind nicht beteiligt, es müssen keine Gebühren bezahlt werden, und es gibt keine Zertifikatsketten. Außerdem ist der Aufwand für die Überprüfung eines starken Namens wesentlich geringer als bei Authenticode. Starke Namen machen jedoch keine Aussage über die Vertrauenswürdigkeit des jeweiligen Verlegers. Mit starken Namen wird gewährleistet, dass der Inhalt der jeweiligen Assembly nicht verändert wurde und dass die zur Laufzeit für Sie geladene Assembly von demselben Verleger wie die erste Version stammt. Es wird jedoch keine Aussage darüber gemacht, ob die Identität des Verlegers vertrauenswürdig ist.

Was ist der Unterschied zwischen einem Namespace und einem Assemblynamen?

Ein Namespace ist ein logisches Benennungsschema, in dem ein einfacher Typname, z.B. MeinTyp, einem durch einen Punkt getrennten hierarchischen Namen folgt. Die Steuerung eines solchen Benennungsschemas liegt beim Entwickler. So könnten wir erwarten, dass die Typen MeinUnternehmen.Dateizugriff.A und MeinUnternehmen.Dateizugriff.B über Funktionen für den Zugriff auf Dateien verfügen. .NET Framework verwendet für die Gruppierung von Typen in logische Kategorien verwandter Funktionen (z.B. ASP.NET-Anwendungsframework) oder Remotefunktionen ein hierarchisches Benennungsschema. Entwurfstools können Namespaces verwenden, damit Entwickler im Code einfacher nach Typen suchen und sie referenzieren können. Ein Namespace ist nicht mit einer Assembly verwandt. Eine einzelne Assembly enthält Typen, deren hierarchische Namen ggf. verschiedene Namespacestämme haben. Ein logischer Namespace umfasst u.U. mehrere Assemblies. In .NET Framework stellt ein Namespace eine logische Vereinfachung der Benennung zur Entwurfszeit dar, während eine Assembly den Namensbereich für Typen zur Laufzeit festlegt.

Weitergabe und Isolation einer Anwendung

Welche Optionen sind für die Weitergabe von .NET-Anwendungen verfügbar?

.NET Framework vereinfacht die Weitergabe, indem Installationen ohne Auswirkungen und eine XCOPY-Weitergabe ermöglicht werden. Da alle Anfragen zunächst in das private Anwendungsverzeichnis aufgelöst werden, müssen zum Ausführen der Anwendung lediglich die Verzeichnisdateien einer Anwendung auf das entsprechende Laufwerk kopiert werden. Eine Registrierung ist nicht erforderlich.

Dieses Szenario ist besonders für Webanwendungen, Webdienste und eigenständige Desktopanwendungen beeindruckend. Es gibt jedoch Szenarios, für die XCOPY als Verteilungsmechanismus nicht ausreicht. Beispiele dafür wären, wenn die Anwendung nur wenig privaten Code enthält und von der Verfügbarkeit gemeinsam genutzter Assemblies abhängt oder wenn die Anwendung nicht lokal installiert ist (sondern bei Bedarf gedownloadet wird). Für solche Fälle stellt .NET Framework umfangreiche Codedownloaddienste und die Integration in Windows Installer bereit. Die Codedownloadunterstützung von .NET Framework hat gegenüber den aktuellen Plattformen einige Vorteile, z.B. inkrementellen Download, Codezugriffssicherheit (also keine Authenticode-Dialogfelder) und Anwendungsisolation (der für eine Anwendung gedownloadete Code beeinträchtigt andere Anwendungen nicht). Windows Installer ist ein weiterer leistungsstarker Weitergabemechanismus, den .NET-Anwendungen verwenden können. Alle Funktionen von Windows Installer, einschließlich Veröffentlichung, Ankündigung und Anwendungswiederherstellung, sind für .NET-Anwendungen in Windows Installer 1.5 verfügbar.

Ich habe eine Assembly erstellt, die ich in mehreren Anwendungen verwenden möchte. Wo kann ich sie weitergeben?

Assemblies, die von mehreren Anwendungen verwendet werden sollen (z.B. gemeinsam genutzte Assemblies), werden an den globalen Assemblycache weitergegeben. Verwenden Sie in der Vorversion und in Betaversionen die /i-Option für das Alink SDK-Tool, um eine Assembly im Cache zu installieren:

al /i:myDll.dll

Mit der künftigen Version von Windows Installer können Sie Assemblies in den globalen Assemblycache installieren.

Wo kann ich sehen, welche Assemblies im globalen Assemblycache installiert sind?

Im Lieferumfang von .NET Framework ist eine Windows-Shellerweiterung für die Anzeige des Assemblycaches enthalten. Wenn Sie in Windows-Explorer zum Verzeichnis % windir%\assembly wechseln, wird der Viewer aktiviert.

Was ist eine Anwendungsdomäne?

Eine Anwendungsdomäne ist ein virtueller Prozess für die Isolation einer Anwendung. Alle Objekte, die im selben Anwendungsbereich erstellt wurden (also Objekte, die sich an einer beliebigen Stelle in der Objektaktivierungssequenz befinden, die mit dem Einstiegspunkt der Anwendung beginnt), werden in derselben Anwendungsdomäne erstellt. Ein einzelner Betriebssystemprozess kann mehrere Anwendungsdomänen enthalten, wodurch sie zu einem einfachen Mittel zur Anwendungsisolation werden.

Ein Betriebssystemprozess ermöglicht Isolation durch einen bestimmten Arbeitsspeicher-Adressenbereich. Dies ist zwar effizient, aber auch kostspielig, und es wird nicht auf die für große Webserver erforderlichen Anzahlen skaliert. Common Language Runtime erzwingt im Gegensatz dazu die Anwendungsisolation, indem die Arbeitsspeicherverwendung des Codes, der in der Anwendungsdomäne ausgeführt wird, verwaltet wird. Dadurch wird sichergestellt, dass nicht auf Arbeitsspeicher zugegriffen wird, der sich außerhalb der Domäne befindet. Beachten Sie, dass nur typsicherer Code auf diese Art verwaltet werden kann. (Die Laufzeit kann die Isolation nicht gewährleisten, wenn unsicherer Code in eine Anwendungsdomäne geladen wird.)

Garbagecollection

Was ist Garbagecollection?

Garbagecollection ist ein Mechanismus, mit dem der Computer ermitteln kann, wenn auf ein Objekt nicht mehr zugegriffen werden kann. In diesem Fall wird der von diesem Objekt verwendete Speicherplatz automatisch freigegeben (außerdem wird eine vom Benutzer geschriebene Bereinigungsroutine mit dem Namen "Finalizer" aufgerufen). Einige Garbagecollector, wie der von .NET verwendete, komprimieren Speicherplatz und verkleinern so das Workingset Ihres Programms.

Wie beeinflusst nichtdeterministische Garbagecollection meinen Code?

Wenn Programmierer über einen Garbagecollector verfügen (und in eine Garbagecollection aufgenommene Objekte verwenden), bedeutet dies meistens, dass sie sich nicht mehr um die Speicherplatzfreigabe oder das Referenzieren von Zählobjekten kümmern müssen, selbst wenn diese komplexe Datenstrukturen verwenden. Der Codierungsstil muss jedoch leicht geändert werden, wenn Sie gewöhnlich Systemressourcen (Dateihandles, Sperren usw.) in demselben Codeblock freigeben, in dem der Speicherplatz für ein Objekt freigegeben wird. Bei einem in eine Garbagecollection aufgenommenen Objekt sollten Sie eine Methode angeben, mit der die Systemressourcen deterministisch (also gesteuert durch Ihr Programm) freigegeben werden, so dass der Garbagecollector den Speicherplatz bei Komprimierung des Workingsets freigibt.

Kann ich die Verwendung des Garbagecollectionheaps vermeiden?

Mit allen Sprachen, die die Laufzeit ansprechen, können Sie Klassenobjekte aus dem Garbagecollectionheap zuweisen. Die Vorteile sind, dass eine schnelle Zuweisung erfolgt und Programmierer keine Vorgehensweisen entwickeln müssen, wenn alle Objekte explizit freigegeben werden sollen.

CLR bietet auch sog. Werttypen (ValueType-Objekte). Sie sind wie Klassen, nur werden ValueType-Objekte im Laufzeitstapel zugewiesen (anstatt im Heap) und daher automatisch freigegeben, wenn Ihr Code sich in der Prozedur befindet, in dem die Objekte definiert sind. So funktionieren übrigens "Strukturen" in C#.

Mit verwalteten C++-Erweiterungen können Sie wählen, welche Klassenobjekte zugeordnet werden. Wenn die Objekte als verwaltete Klassen mit dem Schlüsselwort __gc deklariert werden, werden sie vom Garbagecollectionheap zugewiesen. Wenn sie das Schlüsselwort __gc nicht enthalten, verhalten sie sich wie normale C++-Objekte, die vom C++-Heap zugewiesen und explizit mit der free-Methode freigegeben werden.

Weitere Informationen zur Garbagecollection finden Sie unter:

Remoting

Wie funktioniert prozessinterne und prozessübergreifende Kommunikation in Common Language Runtime?

Bei der prozessinternen Kommunikation müssen zwei Aspekte berücksichtigt werden: anwendungsdomäneninterne oder anwendungsdomänenübergreifende Kommunikation zwischen Kontexten. Zwischen Kontexten innerhalb einer Anwendungsdomäne werden Proxys als Interceptionmechanismus verwendet. Dabei sind Marshalling und Serialisierung nicht erforderlich. Bei der anwendungsdomänenübergreifenden Kommunikation wird Marshalling und Serialisierung mit dem binären Laufzeitprotokoll durchgeführt.

Für die prozessübergreifende Kommunikation werden Protokolle für Plug-In-Channel und Formatierer verwendet, die jeweils für einen bestimmten Zweck geeignet sind.

  • Wenn der Entwickler mit dem Tool soapsuds.exe einen Endpunkt angibt, um einen Metadatenproxy zu erzeugen, ist HTTP-Channel mit SOAP-Formatierer die Standardeinstellung.

  • Wenn ein Entwickler in der verwalteten Umgebung explizites Remoting durchführt, muss explizit angegeben werden, welcher Channel und welcher Formatierer verwendet werden sollen. Diese Angabe kann administrativ, über Konfigurationsdateien oder mit API-Aufrufen zum Laden bestimmter Channel erfolgen. Die folgenden Optionen sind verfügbar:
    HTTP-Channel mit SOAP-Formatierer (HTTP funktioniert gut im Internet oder wenn der Verkehr die Firewalls durchdringen muss)
    TCP-Channel mit Binärformatierer (TCP ist eine leistungsstärkere Option für lokale Netzwerke (LANs))
    SMTP-Channel mit SOAP-Formatierer (nur bei computerübergreifender Kommunikation sinnvoll)

Bei Übergängen zwischen verwaltetem und nicht verwaltetem Code wird die COM-Infrastruktur (v.a. DCOM) für Remoting verwendet. In Zwischenversionen von CLR gilt dies auch für mit Diensten versehene Komponenten (Komponenten, die COM+-Dienste verwenden). Bei der endgültigen Version müssten Sie jede im Remoteverfahren ausgeführte Komponente konfigurieren können.

Die verteilte Garbagecollection von Objekten wird durch ein System mit dem Namen "auf Leasing basierender Lebensdauer-Manager" verwaltet. Jedes Objekt hat eine Leasedauer. Wenn diese abgelaufen ist, wird die Verbindung des Objekts zur Remotinginfrastruktur von CLR getrennt. Objekte haben eine Standarderneuerungszeit – die Leasedauer wird erneuert, wenn ein erfolgreicher Aufruf vom Client an das Objekt erfolgt. Der Client kann außerdem die Leasedauer explizit erneuern.

Interoperabilität

Kann ich COM-Objekte von einem .NET Framework-Programm aus verwenden?

Ja. Jede COM-Komponente, die Sie weitergegeben haben, kann von verwaltetem Code verwendet werden. Bei häufig auftretenden Fällen findet die Anpassung vollständig automatisch statt.

Auf COM-Komponenten wird insbesondere von .NET Framework zugegriffen, indem ein "Runtime Callable Wrapper" (RCW) verwendet wird. Dieser Wrapper wandelt von der COM-Komponente offen gelegte COM-Schnittstellen in .NET Framework-kompatible Schnittstellen um. Für OLE-Automatisierungsschnittstellen kann der RCW automatisch aus einer Klassenbibliothek erzeugt werden. Für andere Automatisierungsschnittstellen kann der Entwickler einen RCW schreiben und die von der COM-Schnittstelle offen gelegten Typen manuell .NET Framework-kompatiblen Typen zuweisen.

Können .NET Framework-Komponenten von einem COM-Programm aus verwendet werden?

Ja. Auf die jetzt von Ihnen erstellten verwalteten Typen kann von COM zugegriffen werden, und normalerweise erfolgt die Konfiguration automatisch. Es gibt bestimmte neue Funktionen der verwalteten Entwicklungsumgebung, auf die von COM nicht zugegriffen werden kann. So können z.B. statische Methoden und parametrisierte Konstruktoren nicht von COM verwendet werden. Es ist i.Allg. von Vorteil, im Voraus festzulegen, wer der beabsichtigte Benutzer eines bestimmten Typs sein soll. Wenn der Typ von COM verwendet werden soll, können Sie ggf. nur die Funktionen verwenden, auf die von COM zugegriffen werden kann.

Je nach Sprache, in der der verwaltete Typ geschrieben wurde, ist der Typ standardmäßig ein- bzw. ausgeblendet.

Auf .NET Framework-Komponenten wird v.a. von COM zugegriffen, wobei ein COM Callable Wrapper (CCW) verwendet wird. Dieser ähnelt einem RCW (siehe vorige Frage), funktioniert aber auch in der entgegengesetzten Richtung. Zur Erinnerung: Wenn .NET Framework-Entwicklungstools den Wrapper nicht automatisch erzeugen können oder wenn Sie das automatisierte Verhalten nicht verwenden möchten, kann ein angepasster CCW entwickelt werden.

Kann ich die Win32-API von einem .NET Framework-Programm aus verwenden?

Ja. Mit P/Invoke können .NET Framework-Programme über statische DLL-Einstiegspunkte auf systemeigene Codebibliotheken zugreifen.

Ein Beispiel dafür, wie C# die Win32-MessageBox-Funktion aufruft:

using System;  
using System.Runtime.InteropServices;  
class MainApp  
{  
    [DllImport("user32.dll", EntryPoint="MessageBox")]  
    public static extern int MessageBox(int hWnd, String strMessage, String strCaption, uint uiType);  
    public static void Main()  
    {  
        MessageBox( 0, "Hallo, hier ist PInvoke!", ".NET", 0 );  
    }  
}

Sicherheit

Was muss ich machen, damit mein Code im Sicherheitssystem funktioniert?

Eigentlich gar nichts. Die meisten Anwendungen werden sicher ausgeführt und sind für mutwillige Angriffe nicht anfällig. Wenn Sie die Standardklassenbibliotheken verwenden, um auf Ressourcen (z.B. Dateien) zuzugreifen oder geschützte Operationen (z.B. ein Reflektionsverfahren für private Mitglieder eines Typs) durchzuführen, wird die Sicherheit von diesen Bibliotheken erzwungen. Zu den einfachen Vorgängen, die Anwendungsentwickler ausführen möchten, gehört u.U. eine Berechtigungsanforderung (eine Form von deklarativer Sicherheit), um die Berechtigungen zu begrenzen, die der Code empfangen kann (Begrenzung auf die erforderlichen Berechtigungen). Dadurch wird außerdem gewährleistet, dass der Code mit allen erforderlichen Berechtigungen ausgeführt wird, wenn die Ausführung zugelassen wird.

Nur Entwickler, die neue Basisklassenbibliotheken schreiben, welche neue Arten von Ressourcen offen legen, müssen direkt mit dem Sicherheitssystem arbeiten. Die Codesicherheit begrenzt den kritischen Code auf einen äußerst kleinen Ausschnitt, der das Sicherheitssystem außer Kraft setzt, so dass der Code insgesamt kein potenzielles Sicherheitsrisko darstellt.

Warum erhält mein Code eine Sicherheitsausnahme, wenn ich ihn auf einem gemeinsam genutzten Laufwerk ausführe?

Die Standard-Sicherheitsrichtlinie übergibt nur einen begrenzten Berechtigungssatz an den Code, der aus der lokalen Intranetzone stammt. Diese Zone wird durch die Sicherheitseinstellungen von Internet Explorer definiert und sollte so konfiguriert werden, dass sie dem lokalen Netzwerk einer Firma entspricht. Da Dateien, die von UNC oder einem zugeordneten Laufwerk (z.B. mit dem NET USE-Befehl) benannt wurden, über dieses lokale Netzwerk gesendet werden, befinden sich auch diese Dateien in der lokalen Intranetzone.

Die Standardeinstellung entspricht dem schlechtesten ungesicherten Intranet. Wenn Ihr Intranet sicherer ist, können Sie die Sicherheitsrichtlinie (mit dem CASPol-Tool) ändern, um dem lokalen Intranet oder Teilen des Intranets (z.B. bestimmten Computerfreigabenamen) weitere Berechtigungen zuzuweisen.

Wie erreiche ich, dass Code ausgeführt wird, wenn er vom Sicherheitssystem angehalten wird?

Sicherheitsausnahmen treten auf, wenn der Code versucht, Aktionen durchzuführen, für die keine Berechtigungen erteilt wurden. Die Erteilung von Berechtigungen erfolgt basierend auf den bekannten Informationen über den Code, v.a. dem Speicherort. So werden z.B. internetausgeführtem Code weniger Berechtigungen erteilt als dem Code, der vom lokalen Computer ausgeführt wird, da die Erfahrung gezeigt hat, dass Internetcode i.d.R. weniger zuverlässig ist. Wenn Sie also die Ausführung von Code zulassen möchten, der aufgrund von Sicherheitsausnahmen nicht ausgeführt wird, müssen Sie die erteilten Berechtigungen erweitern. Eine einfache Methode dafür ist, den Code an einen vertrauenswürdigeren Speicherort (z.B. das lokale Dateisystem) zu verschieben. Dies funktioniert jedoch nicht immer (ein gutes Beispiel sind Internetanwendungen, ein weiteres Intranetanwendungen in einem Firmennetzwerk). Anstatt also den Speicherort des Codes zu ändern, können Sie auch die Sicherheitsrichtlinien ändern, um dem Speicherort mehr Berechtigungen zu erteilen. Dies geschieht entweder mit dem Dienstprogramm für Codezugriffs-Sicherheitsrichtlinien (caspol.exe) oder dem grafischen Verwaltungstool (ab Beta 2 verfügbar). Wenn Sie den Code entwickelt oder veröffentlicht haben, können Sie ihn auch digital signieren und dann die Sicherheitsrichtlinie ändern, um Code, der diese Signatur trägt, weitere Berechtigungen zu erteilen. Wenn Sie eine dieser Methoden wählen, beachten Sie jedoch, dass dem Code weniger Berechtigungen erteilt werden, weil er nicht aus einer bekannten vertrauenswürdigen Quelle stammt. Bevor Sie Code auf Ihren Computer verschieben oder die Sicherheitsrichtlinien ändern, sollten Sie sich vergewissern, dass der Code keine mutwilligen oder schädigenden Aktionen durchführt.

Wie verwalte ich die Sicherheit für meinen Computer? Wie für eine Firma?

Zurzeit können Sie die Sicherheit nur mit dem Befehlszeilentool CASPol verwalten. Die Sicherheitsrichtlinien bestehen aus zwei Ebenen: Computer und nach Benutzer. Es gibt bereits Pläne für ein voll funktionsfähiges Verwaltungstool sowie für die Unterstützung der Richtlinienverwaltung für Firmen als integrierte Komponente für die erste Version von .NET Framework.

Wie funktioniert beweisbasierte Sicherheit mit der Sicherheit von Windows 2000?

Beweisbasierte Sicherheit (die Code autorisiert) funktioniert gemeinsam mit der Windows 2000-Sicherheit (die auf der Anmelde-ID basiert). Für den Zugriff auf eine Datei muss z.B. verwalteter Code über die Sicherheitsdateiberechtigung für den Codezugriff verfügen sowie unter einer Anmelde-ID ausgeführt werden, die NTFS-Dateizugriffsrechte besitzt. Die in .NET Framework enthaltenen verwalteten Bibliotheken bieten auch Klassen für rollenbasierte Sicherheit. Dadurch funktioniert die Anwendung mit Windows-Anmelde-IDs und -Benutzergruppen.


Anzeigen: