2013-09-05 5 views
1

저는 현재 .NET 어셈블리 (COM 클래스 포함)를 무료로 등록하려고합니다. 잘 작동하지만 정확한 원인을 찾아 낼 수없는 문제가 하나 있습니다.SXS는 어떤 프레임 워크 버전을로드해야합니까?

문제는 어셈블리 바인딩이 올바른 .NET Framework 버전에서 수행되지 않는다는 것입니다.

나는 현재 2 개 조립은 (의 그들 A.DLL 및 B.DLL을 부르 자)이 있고 그들은 모두 .NET 4.0을 사용하여 구축된다.

B.dll이 매우 작아서 등록이 필요없는 인증을 테스트했습니다. 옆에 매니페스트가 있음, B.dll.manifest). 그것은 1 개의 속성과 1 개의 메소드를 가진 1 개의 클래스를 포함합니다.

A.DLL는 빌드 후 이벤트 (사용하여 Mt.exe)와 같은 자원으로 임베디드되는 매니페스트의 서명, 훨씬 더 복잡하다.

VB6 애플리케이션을 테스트 해 보았습니다. 내 응용 프로그램에는 종속성을 선언하는 매니페스트가 있습니다.

내 응용 프로그램을 실행하면 B.dll이 제대로 작동하지만 A.dll은 작동하지 않습니다. fuslogvw.exe로 바인딩 로그를 보면 .NET 2.0을 사용하여 A.dll의 바인딩을 시도한 반면 .NET 4.0을 사용하여 B.dll을 완료 한 것으로 나타났습니다.

A.DLL는 COR_E_NEWER_RUNTIME 인 에러 코드 0x8013101b 함께 실패 끝난다. ERR : 파일에서 매니페스트 가져 오기를 추출하는 동안 오류가 발생했습니다 (hr = 0x8013101b).

것은 그것이 작동하도록하기 위해, 내가

<?xml version="1.0"?> 
<configuration> 
    <startup useLegacyV2RuntimeActivationPolicy="true" > 
     <supportedRuntime version="v4.0" /> 
    </startup> 
</configuration> 

그런 다음이 콘텐츠를 내 VB6 응용 프로그램에 .config 파일을 추가해야합니다, 그것은 적절한 프레임 워크 버전에 결합하고 그것을 작동합니다.

나는 어쩌면, Mt.exe에 그것이이 2.0로드해야한다고 생각하고, 내 조립에 속성/메타 정보를 변경하는 것이 tougth. 그래서 ILSpy를 사용하여 열었습니다. 내가 거기서 보는 모든 것은 4.0에 관한 것이고 아무것도 의심스럽지 않습니다.

내가 어셈블리가 그들을 구축하는 데 사용 된 FW를 사용하여 기본적으로로드해야 읽었습니다 (내 경우에는, 그들은 어디 ALL 4.0, 아니 2.0입니다). 그래서, 2.0을 사용하여 특정 하나를로드하려고하는 이유를 얻지 못합니다. 내가 생성/유지하지만 무엇보다도이 특정 조립거야 사용할 수있는 모든 응용 프로그램의 .config 사람들을 배포하는 것을 피하기 위해 싶습니다

나를 위해 문제입니다. 필자의 특별한 경우에 100 개 정도의 .config 파일을 가져야 함을 의미합니다. 참고로

:

Mt.exe에 제가 사용되는 7.0a에의 SDK에서이며 5.2.3790.2076 버전이다.

다음은 fuslogvw입니다.EXE 출력

JRN : cette liaison démarre dans le contexte de chargement de default. 
JRN : tentative de téléchargement du fichier de configuration de l'application à partir de file:///C:/RegFreeCom/BafComClient/binTB/Project1.exe.config. 
JRNÂ : Le fichier de configuration C:\RegFreeCom\BafComClient\binTB\Project1.exe.config n'existe pas. 
JRN : aucun fichier de configuration de l'application n'a été trouvé. 
JRN : utilisation du fichier de configuration de l'ordinateur à partir de C:\Windows\Microsoft.NET\Framework\v2.0.50727\config\machine.config. 
JRN : référence post-stratégie : A, Version=1.0.0.0, Culture=neutral, PublicKeyToken=SomeToken, processorArchitecture=MSIL 
JRN : échec de la recherche dans le GAC. 
JRN : tentative de téléchargement de la nouvelle URL file:///C:/RegFreeCom/BafComClient/binTB/A.DLL. 
JRN : le téléchargement de l'assembly a réussi. Tentative d'installation du fichier : C:\RegFreeCom\BafComClient\binTB\A.dll 
JRN : entrée dans la phase d'installation à exécution à partir de la source. 
ERR : erreur lors de l'extraction de l'importation du manifeste à partir du fichier (hr = 0x8013101b). 
ERR : impossible de terminer l'installation de l'assembly (hr = 0x8013101b). Détection terminée. 

작동하지

JRN : cette liaison démarre dans le contexte de chargement de default. 
JRN : tentative de téléchargement du fichier de configuration de l'application à partir de file:///C:/RegFreeCom/BafComClient/binTB/Project1.exe.config. 
JRNÂ : Le fichier de configuration C:\RegFreeCom\BafComClient\binTB\Project1.exe.config n'existe pas. 
JRN : aucun fichier de configuration de l'application n'a été trouvé. 
JRN : utilisation du fichier de configuration d'hôte : 
JRN : utilisation du fichier de configuration de l'ordinateur à partir de C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config. 
JRN : stratégie non appliquée à la référence à ce stade (liaison d'assembly privée, personnalisée, partielle ou basée sur l'emplacement). 
JRN : tentative de téléchargement de la nouvelle URL file:///C:/RegFreeCom/BafComClient/binTB/sidebysidenet.DLL. 
JRN : le téléchargement de l'assembly a réussi. Tentative d'installation du fichier : C:\RegFreeCom\BafComClient\binTB\B.dll 
JRN : entrée dans la phase d'installation à exécution à partir de la source. 
JRN : le nom de l'assembly est : B, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null 
JRN : la liaison a réussi. Elle retourne un assembly à partir de C:\RegFreeCom\BafComClient\binTB\B.dll. 
JRN : l'assembly est chargé dans le contexte de chargement default. 

작업

B (프랑스 및 엉망 지기도 CHAR 미안은 중요한 부분은 프레임 워크 버전 번호 어쨌든이다) , 작업 (config 파일 덕분에)이 CLR 팀에서

JRN : cette liaison démarre dans le contexte de chargement de default. 
JRN : tentative de téléchargement du fichier de configuration de l'application à partir de file:///C:/RegFreeCom/BafComClient/binTB/Project1.exe.Config. 
JRN : le fichier de configuration de l'application a été trouvé (C:\RegFreeCom\BafComClient\binTB\Project1.exe.Config). 
JRN : utilisation du fichier de configuration de l'application : C:\RegFreeCom\BafComClient\binTB\Project1.exe.Config 
JRN : utilisation du fichier de configuration d'hôte : 
JRN : utilisation du fichier de configuration de l'ordinateur à partir de C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config. 
JRN : référence post-stratégie : A, Version=1.0.0.0, Culture=neutral, PublicKeyToken=SomeToken, processorArchitecture=MSIL 
JRN : échec de la recherche dans le GAC. 
JRN : tentative de téléchargement de la nouvelle URL file:///C:/RegFreeCom/BafComClient/binTB/A.DLL. 
JRN : le téléchargement de l'assembly a réussi. Tentative d'installation du fichier : C:\RegFreeCom\BafComClient\binTB\A.dll 
JRN : entrée dans la phase d'installation à exécution à partir de la source. 
JRN : le nom de l'assembly est : A, Version=1.0.0.0, Culture=neutral, PublicKeyToken=SomeToken 
JRN : la liaison a réussi. Elle retourne un assembly à partir de C:\RegFreeCom\BafComClient\binTB\A.dll. 
JRN : l'assembly est chargé dans le contexte de chargement default. 
+0

때문에 Mt.exe에의되었을 수도, 난 내 빌드 후 이벤트를 수정했습니다. 나는 여전히 같은 오류가 발생합니다. 최신 버전의 MT (SDK 8.1에 포함 된 버전)로 이동하려고 시도했지만 해결되지 않았습니다. –

+0

찾았습니다. 내 어셈블리에서 구형 2.0 어셈블리에 대한 참조가 있습니다. 테스트를 위해 제거했습니다. 동일한 결과가 여전히 있으므로 참고 문헌이 내 문제의 원인이 아닙니다. –

답변

1

M. 밀러는 나를 지적 올바른 방향. 내 매니페스트 (Windows SDK 7.0A에서 mt.exe에 의해 생성됨)는 clrClass 태그의 runtimeVersion에 값을 포함하지 않았습니다.

은 CLR 로더는 "출장"로딩 경로에 들어갈 원인이었다. 밀러 (Miller)가 말한 바에 따르면 버전이 v4 이상이 아니며 로더의 "FindLatestVersion"에서 반환 한 값을 v2로 제한하는 경우이 상한로드 경로가 발생합니다. 따라서 2.0 FW를 사용하여 어셈블리를로드하려고합니다.

올바른 버전 (v4.0.30319)을 지정하고 아무것도 캐시되지 않았 음을 확인하기 위해 매니페스트를 수정하여 (올바른 버전이 로그에 표시되도록 내 디렉토리를 다른 곳으로 복사해야 함) 결국 문제가 해결되었습니다. 이제로드가 '뚜껑이있는'경로로 이동하는 대신 오른쪽 경로로 이동합니다.

이렇게 간단한 결론이 나왔습니다.

FWIW, 난 윈도우 SDK 8.1에서 Mt.exe에를 사용하여 동일한 매니페스트를 생성 시도 (최신 일)과는 runtimeVersion의 제대로 특성을 생성!

이 문제에 대한 도움을 주신 Mark Miller에게 감사드립니다. 도움이 필요하지 않은 경우이 문제를 해결하는 데 시간이 오래 걸릴 것입니다. 단지 매니페스트를 생성하고 (내 어셈블리는 그대로두고)에 embeding 건너 뛰기를 생각

+0

캐싱 메커니즘에 관해서, 나는이 블로그 엔트리를 발견했다. 캐싱은 디버깅 오류 매니페스트를 어렵게 만듭니다. 이 블로그 항목은 해결 http://csi-windows.com/blog/all/27-csi-news-general/245-find-out-why-your-external-manifest-is-being-ignored –

+1

다행이 포함되어 나는 도울 수 있었다. 여기서 중요한 부분은 reg-free COM이 CLSID를 등록하는 데 사용되었고 manifest에는 shim이 런타임이 적합한 지 결정하기 위해 사용하는 버전 문자열이 포함되지 않았다는 것입니다. RegAsm 또는 다른 도구를 사용한 일반적인 등록은 적절한 버전 문자열과 함께 레지스트리 키를 생성하며 분명히 mt.exe (적어도 최신 항목)가이 권한을 얻습니다. 이 버전은 .NET (3.5, 4.5 등)에 사용되는 "마케팅 버전"이 아닌 supportedRuntime 구성 요소에 사용 된 버전 문자열과 비슷한 "런타임 버전"입니다. –

+0

예, 최신 (SDK 8.1) mt.exe가 실제로 올바른 런타임 버전을 포함하고 있습니다. 그러나 "7.0A"아래 설치된 제품은 그렇지 않습니다. Reg-Free COM 매니페스트를 생성하는 데 사용하려고하는 모든 사람에게 경고하는 단어입니다. –