IE: UserControl als applet

[rednax]

Hallo zusammen!


Folgende Situation:
Habe mit Visual Studio 2005 eine Klassenbibliothek mit einer von System.Windows.Forms.UserControl abgeleiteten Klasse geschrieben.
Das Attribut "AllowPartiallyTrustedCallers" ist gesetzt und die Assembly mit einem Schlüssel signiert.
Mit dem Tool ".NET Framework 2.0 Configuration" habe ich unter Laufzeitrichtlinien /Computer/Codegruppen/All_Code eine neue Codegruppe definiert, die für die Mitgliedschaftsbedingung "Starker Name" und dem Schlüssel der Assembly den Berechtigungssatz "FullTrust" festlegt.

Diese Assembly-DLL habe ich nun in ein eigenes Web-Verzeichnis kopiert und eine HTML-Seite mit passendem OBJECT-Tag in ein anderes Web-Verzeichnis.
Als Web-Server verwende ich Apache2.

Mit dem Internet Explorer 7 rufe ich nun die Web-Seite unter Angabe des Hostnamens meines Web-Serves auf. Die Seite habe ich als "vertrauenswürdige Seite" definiert. Diese wird nun korrekt mit der UserControl-Komponente angezeigt und die UserControl-Komponente funktioniert einwandfrei.

Mein Problem:
Die UserControl-Komponente funktioniert nur innerhalb meines Intranets (auf unterschiedlichen Rechnern gestestet).
Der Versuch, die gleiche Installation von einem im Internet befindlichen Web-Server aufzurufen, führt dazu, daß an der Stelle des UserControls lediglich ein Platzhalterrahmen mit einem roten X erscheint.
Zu Testzwecken habe ich noch die URL für die Assembly-DLL direkt im Browser eingegeben. Die Dll läßt sich problemlos vom Internet-Web-Server herunterladen. Der Zugriff auf die Dll kann also nicht der Grund sein.

Ich vermute, daß es an fehlenden Rechten liegt (Internet-Zone?). Da ich aber keine Fehlermeldungen erhalte, stochere ich ziemlich im dunklen.


Kann mir jemand bei meinem Problem helfen?

Recht herzlich Dank.


Mit freundlichen Grüßen,

rednax

[Andreas Kosch]

Hallo,

Mit dem Tool ".NET Framework 2.0 Configuration" habe ich unter Laufzeitrichtlinien /Computer/Codegruppen/All_Code eine neue Codegruppe definiert, die für die Mitgliedschaftsbedingung "Starker Name" und dem Schlüssel der Assembly den Berechtigungssatz "FullTrust" festlegt.

das reicht nicht aus. Da bei der Konfiguration die Attribute PolicyStatementAttribute.Exclusive bzw. PolicyStatementAttribute.LevelFinal gesetzt werden dürfen, sagt ein vorhander Eintrag im Worst Case nichts aus, weil er von einem anderen Eintrag "überstimmt" werden kann. Wurden die beiden Checkboxen This policy level will only have the permissions from the permission set associated with this code group und Policy levels below this level will not be evaluated angekreuzt?

Ich würde den Versuch wiederholen, nachdem im Zweig All_Code | Trusted_Zone das vorbelegte Permission Set auf Full Trust geändert wird. Wenn der Zugriff dann erfolgreich ist, kann man die Einstellung auf den Defaultwert zurücksetzen und statt dessen eine Untergruppe anlegen und über den Strong Name die Rechte nur für das eigene Control aufbohren.

Die UserControl-Komponente funktioniert nur innerhalb meines Intranets...

Weil dort die Code Group All_Code | LocalIntranet_Zone beim Persmission Set bereits in der Voreinstellung höhere Rechte (aber kein Full Trust) vergibt.

[rednax]

Hallo Andreas Kosch,


vielen Dank für Deine Hinweise.

Folgende Schritte habe ich unternommen, um das UserControl zum Laufen zu bekommen:

Zuerst einmal habe ich den Browser-Cache und die .NET-Konfiguration zurückgesetzt.
- Internetoptionen / Allgemein / Browserverlauf / Löschen... Alles
- .NET Framework 2.0 Configuration / Arbeitsplatz / Laufzeitrichtlinie / Alle Richtlinienebenen zurücksetzen


1. Versuch:
- Neue Codegruppe "Computer / All_Code / MyUserControlApplet" erstellt:
"Die Richtlinienebene erhält nur die Berechtigung im der Codegruppe zugewiesenen Berechtigungssatz" markiert
"Richtlinienebenen unter dieser Ebene werden nicht ausgewertet" markiert
Mitgliedschaftsbedingung "Starker Name" mit Schlüssel der Assembly
Berechtigungssatz "FullTrust"

Internet-TEST: kein Erfolg, UserControl wird nicht ausgeführt.


2. Versuch:
- Zusätzlich Codegruppe "Computer / All_Code / Trusted_Zone" auf Berechtigungssatz "FullTrust" geändert

Internet-TEST: kein Erfolg


3. Versuch:
- Zusätzlich neue Codegruppe "Computer / All_Code / Webseite" erstellt:
"Die Richtlinienebene erhält nur die Berechtigung im der Codegruppe zugewiesenen Berechtigungssatz" markiert
"Richtlinienebenen unter dieser Ebene werden nicht ausgewertet" markiert
Mitgliedschaftsbedingung "Site" mit URL meiner Webseite
Berechtigungssatz "FullTrust"

Internet-TEST: kein Erfolg


4. Versuch:
- Zusätzlich Zonensicherheit angepaßt: Alle Zonen auf "FullTrust" gesetzt

Internet-TEST: kein Erfolg


Eigentlich ging ich spätestens beim 4. Versuch davon aus, daß jetzt wirklich jedes .NET-Programm ausgeführt würde.
So kann man sich täuschen.


Da das UserControl im Intranet bei den vorangegangenen Versuchen immer funktionierte, wollte ich feststellen,
ob die Einstellungen überhaupt irgend eine Wirkung zeigen.
Folgende Änderungen:
- Internetoptionen / Allgemein / Browserverlauf / Löschen... Alles
- .NET Framework 2.0 Configuration / Arbeitsplatz / Laufzeitrichtlinie / Alle Richtlinienebenen zurücksetzen

5. Versuch:
INTRANET-Versuch: UserControl funktioniert, und das mit den Standardeinstellungen.


6. Versuch:
- Zonensicherheit geändert: Alle Zonen bis auf Arbeitsplatz auf "nicht vertrauenswürdig" gesetzt.
INTRANET-Versuch: UserControl wird nicht mehr ausgeführt. Allerdings erscheint an der Stelle des UserControls diesmal ein Platzhalterrahmen mit
einem anderen Symbol (rotes Viereck, grüner Kreis, blaues Dreieck).


Momentan bin ich ziemlich ratlos, wie ich das .NET-UserControl im Internet zum Laufen bekommen soll.


Noch irgend welche hilfreichen Ratschläge?



Mit freundlichen Grüßen,


rednax

[rednax]

Hallo zusammen!


Da ich leider mein Problem immer noch nicht gelöst habe und mir auch bis jetzt niemand weiterhelfen konnte,
möchte ich zumindest weitere Informationen darüber geben, welche Versuche ich unternommen habe,
um die Assembly doch noch zum Laufen zu bekommen.


Zu diesem Zweck habe ich erstens die "IEHost Debug Log File" aktiviert.
In diese Log-Datei werden alle Aktivitäten der IEHost.dll protokolliert,
welche immer dann zum Einsatz kommt, wenn innerhalb des Internet Explorers CLR-Code zur Ausführung kommt.
Siehe hierzu http://support.microsoft.com/kb/313892/en-us.

Zweitens habe ich die Assemblybindungs-Protokollanzeige aktiviert.
Siehe hierzu http://msdn2.microsoft.com/de-de/lib...c4(VS.80).aspx.
Diese habe ich so eingestellt, daß alle Bindungen protokolliert werden.



Danach habe ich zuerst die Intranet-Seite aufgerufen, die bekanntlich funktioniert.
Daraufhin wurde eine "IEHost Debug Log File" geschrieben und es erschienen Eintragungen in der Assemblybindungs-Protokollanzeige.
Ohne genauer auf den Inhalt der Protokolle einzugehen habe ich danach die Internet-Seite aufgerufen.
Ergebnis: Weder erscheint eine "IEHost Debug Log File" noch erscheinen Eintragungen in der Assemblybindungs-Protokollanzeige.
Meine vorläufige Schlußfolgerung: Die Assembly in der Internet-Seite wird nie an das .NET Framework weitergeleitet,
da nicht einmal ein Bindungsversuch stattfindet. Dies würde auch erklären, warum die Assembly trotz "FullTrust" für alle Sicherheitszonen
nicht ausgeführt wird.
Da ich für meine Versuche die "Internet Explorer"-Sicherheitseinstellungen praktisch komplett deaktiviert habe,
bin ich momentan am Ende der Fahnenstange angelangt. Ich habe keine Ahnung, welche Einstellung es noch geben könnte,
die die Ausführung der Assembly verhindert.


Vielleicht hat jemand einen hilfreichen Hinweis?



Mit freundlichen Grüßen,


rednax

[rednax]

Hallo zusammen!



Nachtrag zu dem bisher Gesagtem:

Ob es sich bei einem Objekt um eine .NET Assembly handelt oder nicht,
entscheidet der Internet Explorer mit Hilfe der Mscorie.dll.
Siehe hierzu http://support.microsoft.com/kb/311301/en-us.
Diese Dll analysiert den Datenstrom und startet bei erfolgreicher Identifizierung einer .NET Assembly
die IEHost.dll, welche dann für die Bindung sorgt.
Mit Hilfe des "ProcessExplorers" habe ich nun überprüft, ob der Internet Explorer diese Dlls lädt.
1. Intranet:
Sobald die Web-Seite mit dem Object-Tag für die Assembly geladen wird, werden auch die Mscorie.dll und IEHost.dll (plus einige weitere Dlls)
in den Internet Explorer Prozess geladen.

2. Internet:
Wenn die Web-Seite mit dem Object-Tag für die Assembly geladen wird, passiert nichts dergleichen.
Keine einzige der unter 1. gefundenen Dlls wird geladen.
-> Wenn mscorie.dll nicht geladen wird, kann nicht erkannt werden, ob es sich um eine .NET Assembly handelt.
-> .NET Assembly wird niemals ausgeführt.

Meine vorläufige Schlußfolgerung:
Obwohl beide Web-Seiten als "vertrauenswürdige Seite" eingestuft sind, werden diese dennoch vom Internet Explorer 7 unterschiedlich behandelt.
(Ob dies auch für ältere Internet Explorer-Versionen gilt, habe ich nicht getestet)
Ganz offensichtlich ignoriert der Internet Explorer jegliche Sicherheitseinstellung
und unterbindet grundsätzlich die Ausführung jeglicher .NET Assemblies die ursprünglich aus der Internetzone stammen.

Ist jemandem bekannt, daß dies tatsächlich so ist?
Oder hat jemand gegenteilige Erfahrungen gemacht?




Mit freundlichen Grüßen,


rednax

[Andreas Kosch]

Hallo,

eventuell hilft eines der beiden folgenden Foren weiter:
http://forums.microsoft.com/MSDN/def...D=253&SiteID=1

[rednax]

Hallo zusammen!


Hier kommt des Rätsels Lösung:

Der Web-Server war falsch konfiguriert.
Die UserControll-Dll wurde nicht als MIME-Typ application/octet-stream
übertragen sondern als text/plain.
Da die mscorie.dll aber nur bei application/octet-stream Typen aktiv wird, wurde die Assembly nicht erkannt und somit nicht ausgeführt.


Hallo Andreas, nochmals vielen Dank, daß Du versucht hast, mir weiterzuhelfen.
Leider habe ich am falschen Ende begonnen zu suchen.


Mit freundlichen Grüßen,


rednax

[Andreas Kosch]

Hallo,

Leider habe ich am falschen Ende begonnen zu suchen.

das ist gesetzmäßig: Murphy's Gesetz ;-)

Man muss nur das Positive sehen. Die Suche nach der Ursache für das Problem hat zumindest das Wissen nach 4 Jahren wieder auf den aktuellen Stand gebracht (damals zum .NET-Start habe ich auch mit so etwas "gespielt", aber später nicht in echten Projekten verwendet, weil es mit ClickOnce eine andere Alternative gibt).