Error processing SSI file

Solutions for Chapter 3: The .NET Architecture

  1. Virtuelle Maschine. Welche Vorteile sprechen für die Verwendung einer virtuellen Maschine?

    Antwort: siehe 3.1 Wozu eine virtuelle Maschine, Seite 122 ff



  2. CLR vs. JVM. Eignet sich die .NET Common Language Runtime oder die Java Virtual Machine eher als Zielplattform für verschiedene Programmiersprachen? Begründen Sie Ihre Antwort.

    Antwort: siehe Vergleich zweier virtueller Maschinen: CLR vs. JVM, Seite 125 ff

    Die CLR ist besser als Zielplattform für verschiedene Programmiersprachen geeignet, weil sie ein breiteres Spektrum an Konzepten unterstützt als die JVM, z.B.

    Der Grund für diese höhre Flexibilität liegt einfach in der unterschiedlichen Zielsetzung der beiden Plattformen: die JVM soll nur eine Programmiersprache (Java) auf möglichst vielen Systemen unterstützen, während die CLR von Grund auf mit dem Ziel entwickelt wurde, viele Konzepte auf vielen Programmiersprachen zu unterstützen.



    3. Common Type System (CTS)

  3. Wert- und Referenztypen. Worin besteht der grundlegende Unterschied zwischen Wert- und Referenztypen? Wie wirkt sich das auf die Laufzeit aus?

    Antwort: siehe 3.2.2 Werttypen, Seite 133 f

    Bei Werttypen werden die Daten direkt am Stack gespeichert, während Referenztypvariablen nur Zeiger auf die Daten am Heap enthalten.
    Wenn Werttypvariablen von Stack entfernt werden, wird damit gleichzeitig der Speicherplatz für deren Daten freigeben. Bei Referenztypvariablen wird nur der Speicherplatz für den Objektzeiger freigegeben, der Speicher, den die Daten am Heap beanspruchen, wird erst vom Garbage Collector freigegeben.
    Deshalb, und weil jeder Zugriff auf die Daten eines Referenztyps eine zusätzliche Indirektion in den Heap bedeutet, kosten Referenztypen mehr Laufzeit, weshalb sich Werttypen gerade für kurzlebige Zwischenergebnisse eignen.



  4. Boxing. Trotz des Unterschiedes zwischen Wert- und Referenztypen sind in .NET alle Objekte zum obersten Basistyp System.Object kompatibel. Wie erreicht man diese Kompatibilität für Werttypen?

    Antwort: siehe 3.2.4 Von Wert- nach Referenztyp und zurück, Seite 143 f

    Durch den sog. Boxing-Mechanismus:
    Dabei werden Objekte von Werttypen in strukturäquivalente Referenztypobjekte auf den Heap kopiert und einer Referenz darauf wird in der Referenztypvariablen gespeichert. Umgekehrt können derart "verpackte" Werttypobjekte auch wieder auf den Stack kopiert, also an Werttypvariablen zugewiesen werden.



    5. Common Language Specification (CLS)

  5. Attribut CLSCompliant. Betrachten Sie die folgenden C#-Codebeispiele und stellen Sie fest, für welche Elemente (Klassen, Felder, Methoden) der C#-Compiler tatsächlich die CLS-Konformität prüft. (In allen Fällen liefert der C#-Compiler keine Fehlermeldung).
    Begründen Sie Ihre Antworten kurz.
    a)
    public class A {
      public int F1;
      public void M1 (int p1) { }
    }

    b)
    [assembly: System.CLSCompliant(true)]

    public class B {
      public int F1;
      public void M1 (int p1) { }
    }

    c)
    [assembly: System.CLSCompliant(true)]

    public class C {
      public int F1;
      M1 (sbyte p1) { }
    }

    Antwort: siehe 3.3.1 Attribut CLSCompliant, Seite 146

    a) CLS-Konformität wird gar nicht geprüft, weil nicht explizit gefordert.
    b) CLS-Konformität wird für alle Elemente des Assemblies geprüft, weil für das gesamte Assembly gefordert.
    c) CLS-Konformität wird für die Klasse C und das Feld F1 geprüft, aber nicht für die Methode M1, weil diese private ist und daher die CLS-Regel für sie nicht gelten (sbyte wäre nicht CLS-konform).



    6. Common Intermediate Language (CIL)

    Metadaten

  6. Metadatenarten. Welche Arten von Metadaten kann man unter .NET unterscheiden? Was beschreiben sie?

    Antwort: siehe 3.5 Metadaten, Seite 149



    7. Assemblies und Module

  7. Assembly vs. Module. Beschreiben Sie kurz, wodurch sich Modul und Assembly voneinander unterscheiden?

    Antwort: siehe 3.6 Assemblies und Module, Seite 154 f

    Ein Modul bildet eine physikalische Einheit und entspricht immer einer Datei, während ein Assembly eine logische Einheit darstellt, die eine oder mehrere (Modul- und Ressource-)Dateien zusammenfasst.



  8. Starke Namen. Aus welchen Teilen setzt sich ein starker Name zusammen?

    Antwort: siehe 3.6.2 Versionierung, Seite 158 f

    Ein starker Name besteht aus



  9. Starke Namen. Wozu oder wann benötigt ein Assembly einen starken Namen?

    Antwort: siehe 3.6.2 Versionierung, Seite 158

    Ein Assembly braucht einen starken Namen, um



  10. Versionsnummern. Wann wurde ein Assembly mit der automatisch generierten Versionsnummer ([assembly: AssemblyVersion("1.2.*")]) 1.2.1088.3792 erzeugt?

    Antwort: siehe 3.6.2 Versionierung, Tabelle 3.8, Seite 159

    Am 24.12.2002 um 02:12:24 (Ortszeit).



    11. Virtual Execution System (VES)

  11. Applikationsdomänen. Implementierien Sie (in C#) eine Kommandozeilen-Applikation AppLauncher, die es ermöglicht, andere Applikation zu starten und gleichzeitig laufen zu lassen. Jede dieser von AppLauncher gestarteten Applikationen soll in einer eigenen Applikationdomäne laufen (kein eigener Prozess!).

    Antwort: siehe 3.7.1 Applikationsdomänen, Seite 154 f

    using System;
using System.Threading;

class AppLauncher {
  class AppThread {
    AppDomain domain;
    string uri;

    public AppThread (string appURI) {
      uri = appURI;
      domain = AppDomain.CreateDomain(uri);
    }

    public void Execute () {
      try {
        domain.ExecuteAssembly(uri);
      } catch (Exception e) {
        Console.WriteLine("Exception while executing " + domain.FriendlyName);
        Console.WriteLine(e);
      }
    }
  }

  static void Main () {
    for (;;) {
      Console.WriteLine();
      Console.Write(">");
      string appURI = Console.ReadLine();

      try {
        if (appURI == "exit") break;
        else if (if (appURI == null || appURI.Length == 0)
          throw new Exception("No application specified");

        AppThread at = new AppThread(appURI);
        Thread t = new Thread(new ThreadStart(at.Execute));
        t.Start();
      } catch (Exception e) {
        Console.WriteLine(e);
      }
    }
  }
}



  12. Probing. Bei der Ausführung von MyApp aus dem lokalen Verzeichnis c:\Programme\MyAppDir\ wird das private Assembly Utils benötigt. In welchen Pfaden wird standardmäßig danach gesucht?

    Antwort: siehe 3.7.2 Laden und Ausführen von Managed Code, Auffinden eines Assemblies, Seite 164 f

    Private Assemblies müssen in einem Unterverzeichnis des Applikationsbasisverzeichnisses liegen und werden immer durch Probing gesucht. Dabei wird zuerst die Dateierweiterung .dll und anschließend .exe ausprobiert.
    Ablauf
      c:\Programme\MyAppDir\Utils.dll
      c:\Programme\MyAppDir\Utils\Utils.dll
      c:\Programme\MyAppDir\bin\Utils.dll
      c:\Programme\MyAppDir\bin\Utils\Utils.dll

      c:\Programme\MyAppDir\Utils.exe
      c:\Programme\MyAppDir\Utils\Utils.exe
      c:\Programme\MyAppDir\bin\Utils.exe
      c:\Programme\MyAppDir\bin\Utils\Utils.exe



    13. Sicherheit

  13. Rechtevergabe. Die Sicherheitspolitik wird unter .NET auf vier Ebenen definiert: Enterprise, Machine, User, AppDomain. Angenommen auf Enterprise-, User- und AppDomain-Ebene erhalten alle Assembly alle Rechte (FullTrust). Auf Machine-Ebene wird die folgende Politik festgelegt:



    Welche Rechte erhält das Assembly MSApp, dass von Microsoft produziert (und signiert) und von http://dotnet.jku.at/pub/apps/ geladen wurde? Zu welchen Codegruppen der Machine-Ebene gehört es?

    Antwort: siehe 3.8.1 Codebasierte Sicherheit, Bestimmen der Rechte eines Assemblies, Seite 177 ff

    Assembly MSApp gehört zu den Codegruppen:

    ... und erhält daraus die Rechte der Genehmigungsmengen:



Error processing SSI file