레지스트리 접근 - Win7 "Any CPU"vs x86

우리는 프로그래머 중 한 명에게 누군가에게 통용되지 않는 약간의 변화를 주었고 누군가가 통찰력을 제공하기를 희망합니다. 불행히도 우리는 그에게 연락 할 수 없습니다. 다음 주에이 정보를 더 빨리 알면 좋을 것입니다.레지스트리 접근 - Win7 "Any CPU"vs x86

우리는 모든 적절한 소스 파일을 다운로드하고 COM 인 DLL을 등록 및 등록 해제하고 일부 어셈블리에 대해 RegASM을 실행하는 사용자 정의 응용 프로그램 로더 (.net)가 있습니다. 우리는 윈도우 7 (x64)에서 로더에 문제가있어이를 수정하도록했습니다.

이 문제를 해결하기 위해 할당 된 개인은 로더가 "모든 CPU"가 아닌 x86으로 빌드되도록 요청하는 것뿐입니다. 이것이 어떻게 문제를 해결할 수 있는지 보는 데 어려움을 겪고 있습니다.

이전에 우리는 COM 등록 오류가 있었으며 RegASM을 사용하여 TLB 파일을 만들려고 할 때 "요청 된 레지스트리 액세스가 허용되지 않았습니다"오류가 발생했습니다. 누구든지 그의 변화가 어떻게이 문제에 영향을 줄 수 있었는지 알 수 있습니까?

출처

2011-10-05 coding4fun

옳은 일이 아니라고 말하는 것은 아닙니다. 예 "모든 CPU"는 좋지 않지만 여전히 우리가 가진 문제를 어떻게 해결했는지 알지 못합니다. x86 프로세스와 마찬가지로 x64 프로세스보다 보안 성이 뛰어납니다. – coding4fun

동료가 수정되었습니다. 이유는 다음과 같습니다.

Windows x64에서 프로세스는 32 비트 또는 64 비트 프로세스로 시작될 수 있습니다. 64 비트 프로세스는 64 비트 DLL 만로드 할 수 있고 32 비트 프로세스는 32 비트 DLL 만로드 할 수 있습니다.

.NET 응용 프로그램의 플랫폼 대상 (예 : 프로젝트 속성에 지정된)이 "모든 CPU"로 설정된 경우 대상 플랫폼에 따라 중간 코드가 32 비트 또는 64 비트 코드로 컴파일됩니다 (예 : x64 시스템의 64 비트 코드가 생성됩니다. 따라서 네이티브 32 비트 COM 구성 요소와 같은 32 비트 라이브러리는 64 비트 프로세스에로드 할 수 없습니다.

출처

2011-10-05 19:59:11

COM in-proc DLL에 해당합니다. 그러나 64 비트 프로세스는 32 비트 COM out-proc EXE를로드하고 사용할 수 있으며 반대의 경우도 마찬가지입니다. COM은 out-proc 서버에 필요한 32 비트/64 비트 마샬링을 처리합니다. in-proc DLL을 한 비트 씩 컴파일하고 다른 비트 프로세스에서 사용해야하는 경우 DllSurrogate를 DLL에 할당하여 out-proc 서버로 실행할 수 있습니다. –

@Remy Lebeau - TeamB : 사실이지만, 사람들이 원하는 것은 거의 없습니다. AnyCPU로 .NET 코드를 컴파일하고 x86으로 컴파일하고 in-proc 서버를 사용하여 동일하게 달성 할 수있는 경우 out-of-process COM 구성 요소를 사용하려는 interop 사례는 매우 드뭅니다. 이러한 이유로 Microsoft는 VS 2010의 기본 프로젝트 템플릿을 x86으로 컴파일하도록 변경했습니다. –

레지스트리 접근 - Win7 "Any CPU"vs x86

답변

관련 문제