.NET-Applets

Windows Presentation Foundation, Silverlights großer Bruder, ist ebenfalls im Browser zu verwenden. Web Browser Application (WBA) oder XAML Browser Application (XBAP) sind die Techniken dafür. Wie bei Silverlight kann der Entwickler über ein <object>-Tag mit XAML (Extensible Application Markup Language) gestaltete Steuerelemente in die Seite einbetten, wobei ein Steuerelement aus anderen bestehen darf. Auf Gestaltungsseite bietet eine WBA alles, was .NET bietet. Dafür erfordert sie ein vollständiges .NET Framework auf dem Client. Dennoch erlaubt die Standardsicherheitskonfiguration einer WBA nicht alles, was .NET kann. Dateisystemzugriffe und andere kritische Aufrufe blockt das Sicherheitssystem, denn einer von einem Webserver geladenen Anwendung vertraut das .NET Framework nicht vollständig – zumindest solange man nicht die Sicherheitskonfiguration ändert.

Oft wird vergessen, dass man seit .NET 1.0 Windows-Forms-Steuerelemente in Webseiten als Objekt einbetten kann. Für die Anwendung gibt es von Microsofts Seite aus nicht einmal einen eigenen Namen. Der Autor hat daher den Begriff ".NET-Applet" für die Windows-Forms-Anwendung kreiert. Dabei wäre .NET-Applet auch als Oberbegriff von Windows Forms und WPF im Browser treffend, denn die Anforderungen und Mittel sind mit denen von Java-Applets vergleichbar. WBAs haben gegenüber Windows-Forms-Applets den Vorteil, dass sie neben Internet Explorer im Firefox laufen.

ActiveX ist nicht tot

Für Internet-Anwendungen haben WBAs und .NET-Applets durch die Softwareanforderungen keine Bedeutung, im Intranet findet man sie nicht häufig. Für Intranet-Anwendungen gilt oft die Anforderung des Zugriffs auf lokale Ressourcen wie Dateisystem, Smartcard-Reader und Spezialdrucker (etwa für Etiketten). Solche Hard- und Softwareressourcen kann man weder mit WBA noch mit Windows-Forms-Applets ansprechen. Dafür gibt es nur eine Lösung und die heißt ActiveX im Webbrowser. ActiveX ist durch sein Schwarz-Weiß-Sicherheitsmodell tot für Internet-Anwendungen, denn ActiveX kann ein Steuerelement entweder nur komplett verbieten oder aber es mit den vollen Rechten des angemeldeten Benutzers (etwas eingeschränkt ab Windows Vista mit aktivierter Benutzerkontensteuerung) ausführen. Eine Sandbox mit selektiver Ausführung wie bei Silverlight und den .NET-Applets gibt es nicht. Im Intranet ist es jedoch kein Problem, den eigenen Steuerelementen zu vertrauen.

ActiveX-Steuerelemente mit .NET zu erstellen ist zwar technisch möglich, ergibt aber keinen Sinn. Denn erstens braucht man ein .NET Framework auf dem Client und zweitens würde wieder das Sicherheitssystem greifen, das man ja im Fall des Zugriffs auf Ressourcen nicht will. ActiveX programmiert man am besten mit C++ als Unmanaged Code, denn die entstehenden DLLs sind klein und eine Laufzeitumgebung ist nicht erforderlich.