Mein Problem beginnt mit dem Verschieben einer .Net 2.0-Anwendung auf .NET 4.0. Der Grund dafür war, dass Windows 8 die älteren .Net-Versionen standardmäßig nicht aktiviert und meine Anwendung den Benutzer nicht zur Aktivierung auffordern kann.Dynamic Assembly Laden in .NET 4.0
Die Anwendung ist ein NPAPI-Plugin, das .Net-Komponenten über UnmanagedExports verwendet. Ich habe es als eine Anwendung mit niedriger Integrität entworfen und muss daher im LocalLow-Verzeichnis der Benutzer liegen.
In meiner Anwendung habe ich einen dynamischen Assembly-Lademechanismus verwendet, um mehrere Assemblys zur Laufzeit zu laden. Ich die folgende Methode verwendet, um eine Baugruppe zu laden,
MyInterface Instance;
Assembly assembly = Assembly.LoadFrom(AssemblyFile);
Type type = assembly.GetType(Identifier); // Identifier is implementing the MyInterface
Instance = Activator.CreateInstance(type) as MyInterface;
// Do something with the Instance
Nachdem das Projekt modifiziert 4.0 auf .NET, bemerkte ich, dass das Plugin stürzt ab, wenn die Binär-Dateien innerhalb des LocalLow Verzeichnis abgelegt werden (Es funktioniert in anderen Orten) . Mein nächster Schritt war, ein minimalistisches Plugin mit möglichst wenig Code zu erstellen, um das Problem zu lösen. Ich bemerkte, dass die dynamische Montage Laden mit der folgenden Ausnahme fehlgeschlagen,
System.IO.FileLoadException: Could not load file or assembly '<assemblyPath>' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515 (COR_E_NOTSUPPORTED)) --->
System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=131738 for more information.
ich folgende Ansätze versucht, eine separate Domäne zu erstellen und die Baugruppen geladen werden, aber ohne Glück,
- http://blogs.msdn.com/b/shawnfa/archive/2009/06/08/more-implicit-uses-of-cas-policy-loadfromremotesources.aspx
- http://www.west-wind.com/weblog/posts/2009/Jan/19/Assembly-Loading-across-AppDomains
Das Hinzufügen der Konfiguration 'loadFromRemoteSources' funktionierte ebenfalls nicht. Es scheint, dass die .Net-Komponente .dll.config-Dateien nicht lädt. (konnte wegen UnmanagedExporting sein)
Meine Fragen sind,
- Ist es möglich, eine Anordnung von LocalLow dynamisch zu laden?
- Gilt die neue CAS-Richtlinie in CLR 4.0 auch für LocalLow? Von dem, was ich bisher verstanden habe, sollte es nur die über das Netzwerk geladenen Baugruppen betreffen
- Gibt es eine andere Möglichkeit, dieses Problem zu beheben?
Warum sind Sie in LocalLow? Dies ist ein Verzeichnis, das speziell dafür gesichert ist, dass es von nicht vertrauenswürdigen Anwendungen beschreibbar ist (Prozesse mit geringer Integrität). Es wird wahrscheinlich als "Netzwerkstandort" angesehen, da es für Internet Explorer und andere Browser verwendet wird, aber es könnte einfach ein MOTW auf der DLL sein. – Mitch
Der Grund, warum ich zu LocalLow wechseln musste, ist, dass Internet Explorer den Zugriff auf alle anderen Pfade blockiert, wenn ein Plug-in ausgeführt wird, insbesondere wenn wir in Dateien schreiben [diesen Link überprüfen] (http://www.codeproject.com)/Artikel/18866/A-Entwickler-s-Survival-Guide-to-IE-Protected-Mode # Schreibdateien). Die einzige Option war die Verwendung von LocalLow. – Isuru
genau mein Punkt. Da es in Plugins geschrieben werden kann, wird es von BlackNet beim Laden einer Assembly gelöscht. LocalLow ist für Dateien, die * von * Plugins geschrieben werden müssen, nicht für die Plugins selbst. Suchen Sie das Plug-in in einem anderen Verzeichnis (Programmdateien kommen Ihnen in den Sinn) und schreiben Sie Ihre temporären Dateien in LocalLow. – Mitch