.Net 2.0 응용 프로그램을 .Net 4.0으로 옮기는 것으로부터 시작합니다. 이 작업을 수행 한 이유는 Windows 8에서 이전 버전의 .Net 버전을 기본적으로 사용할 수 없기 때문에 내 응용 프로그램에서 사용자에게 사용권을 요청할 수 없기 때문입니다..Net 4.0에서 동적 어셈블리로드
응용 프로그램은 UnmanagedExports을 통해 .Net 구성 요소를 사용하는 NPAPI 플러그인입니다. 낮은 무결성 응용 프로그램으로 설계하여 사용자의 LocalLow 디렉터리에 있어야합니다.
내 응용 프로그램에서는 동적 어셈블리로드 메커니즘을 사용하여 런타임에 여러 어셈블리를로드했습니다. 나는 4.0 .NET으로 프로젝트를 수정 한 후,
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
를 어셈블리를로드하기 위해 다음과 같은 방법을 사용, 나는 눈치 그 (그것은 다른 장소를 작동 ) 바이너리가 LocalLow 디렉터리 내부에 배치되는 플러그인 충돌 . 내 다음 단계는 최소한의 코드로 문제를 파악할 수있는 최소한의 플러그인을 만드는 것이 었습니다. 나는 동적 어셈블리 로딩,
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.
내가 별도의 도메인을 생성하고 어셈블리를로드하지만 운 다음 방법을 시도, 다음과 같은 예외로
- 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 실패한 것으로 나타났습니다
'loadFromRemoteSources'구성을 추가하지 못했습니다. .Net 구성 요소가 .dll.config 파일을로드하지 않는 것 같습니다.
- 동적으로 LocalLow에서 어셈블리를로드 할 수 있으며,
내 질문이 있습니다 (때문에 UnmanagedExporting이 될 수 있을까요)?
- CLR 4.0의 새로운 CAS 정책이 LocalLow에도 적용됩니까? 지금까지 이해 한 것부터 네트워크를 통해로드 된 어셈블리에만 영향을 주어야합니다.
- 이 문제를 극복하는 다른 방법이 있습니까?
왜 LocalLow에 있습니까? 이는 신뢰할 수없는 응용 프로그램 (낮은 무결성 프로세스)이 쓰기 가능하도록 특별히 보호 된 디렉토리입니다. 아마도 Internet Explorer 및 다른 브라우저를 사용하기 때문에 "네트워크 위치"로 볼 수 있지만 DLL의 MOTW 일 수 있습니다. – Mitch
LocalLow로 전환해야하는 이유는 Internet Explorer가 플러그인을 실행할 때 다른 모든 경로에 대한 액세스를 차단하기 때문입니다. 특히 파일에 쓰는 경우에는 [이 링크 확인] (http://www.codeproject.com)을 참조하십시오./Articles/18866/A-Developer-s-Survival-Guide-to-IE-Protected-Mode # writingfile). 유일한 옵션은 LocalLow를 사용하는 것이 었습니다. 내 포인트는 – Isuru
입니다. 플러그인에 쓰기가 가능하기 때문에 .Net은 어셈블리를로드하지 못하도록 블랙리스트에 올립니다. LocalLow는 * 플러그인에 의해 작성되어야하는 파일을위한 것이지 플러그인 자체는 필요하지 않습니다. 다른 디렉토리 (프로그램 파일이 마음에 듭니다)에서 플러그인을 찾아 LocalLow에 임시 데이터 파일을 작성하십시오. – Mitch