Visual Studio 컴파일 오류“프로세서 아키텍처 간 불일치”를 어떻게 수정합니까?

Visual Studio 2010에서 프로젝트 구성을 처음 사용했지만 약간의 연구를 수행했지만 여전히이 문제를 파악할 수는 없습니다. C # DLL을 참조하는 C ++ DLL이 포함 된 Visual Studio 솔루션이 있습니다. C # DLL은 다른 일부 DLL을 참조하며, 일부는 프로젝트 내 및 일부는 외부 DLL입니다. C ++ DLL을 컴파일하려고하면 다음과 같은 경고 메시지가 나타납니다.

경고 MSB3270 : "MSIL"빌드중인 프로젝트의 프로세서 아키텍처와 "[internal C # dll]", "x86"참조의 프로세서 아키텍처간에 불일치가있었습니다.

내 아키텍처를 정렬하기 위해 Configuration Manager로 이동하라는 메시지가 표시됩니다. C # DLL은 플랫폼 대상 x86으로 설정됩니다. 이것을 Any CPU와 같은 다른 것으로 변경하려고 하면 의존 하는 외부 DLL 중 하나에 플랫폼 대상 x86이 있기 때문에 불평 합니다.

Configuration Manager를 보면 C # DLL의 플랫폼이 x86으로, C ++ 프로젝트의 경우 Win32로 표시됩니다. 이것은 올바른 설정처럼 보입니다. 확실히 C ++ 프로젝트의 프로젝트가 x64로 설정된 플랫폼을 갖기를 원하지 않습니다.이 옵션은 다른 옵션입니다.

내가 여기서 뭘 잘못하고 있니?

이 경고는 새로운 Visual Studio 11 Beta 및 .NET 4.5에서 도입 된 것으로 보이지만 이전에는 가능했을 것으로 생각됩니다.

첫째, 정말 경고 일뿐입니다. x86 의존성을 다루는 경우 아무것도 아프지 않아야합니다. Microsoft는 프로젝트가 "Any CPU"와 호환 가능하지만 x86 또는 x64 인 .dll 어셈블리 또는 프로젝트에 종속되어 있다고 말할 때 경고하려고합니다. x86 종속성이 있으므로 기술적으로 프로젝트는 "모든 CPU"와 호환되지 않습니다. 경고를 없애려면 실제로 프로젝트를 "Any CPU"에서 "x86"으로 변경해야합니다. 이 작업은 매우 쉽습니다. 단계는 다음과 같습니다.

1. Build | Configuration Manager 메뉴 항목으로 이동하십시오.
2. 목록에서 프로젝트를 찾으십시오. 플랫폼 아래에 "모든 CPU"라고 표시됩니다.
3. 드롭 다운에서 "모든 CPU"옵션을 선택한 다음 <New..>
4. 해당 대화 상자의 "New Platform"드롭 다운에서 x86을 선택하고 "Copy settings from"드롭 다운에서 "Any CPU"가 선택되어 있는지 확인하십시오.
5. 확인을 누르십시오
6. 디버그 및 릴리스 구성 모두에 대해 x86을 선택하려고합니다.

이렇게하면 경고가 사라지고 어셈블리 또는 프로젝트가 더 이상 "모든 CPU"와 호환되지 않지만 이제 x86에만 해당됩니다. x64 종속성이있는 64 비트 프로젝트를 빌드하는 경우에도 적용됩니다. 대신 x64를 선택하면됩니다.

다른 참고로, 프로젝트가 순수한 .NET 프로젝트 인 경우 일반적으로 "모든 CPU"와 호환 될 수 있습니다. 이 문제는 특정 프로세서 아키텍처를 대상으로하는 종속성 (타사 dll 또는 자체 C ++ 관리 프로젝트)을 도입 한 경우에만 발생합니다.

이것은 매우 완고한 경고이며 유효한 경고이지만 타사 구성 요소 사용 및 기타 이유로 인해 해결할 수없는 경우가 있습니다. 내 프로젝트 플랫폼이 AnyCPU이고 AMD64 용으로 작성된 MS 라이브러리를 참조하기 때문에 경고가 있다는 것을 제외하고는 비슷한 문제가 있습니다. 이것은 Visual Studio 2010에 있으며 VS2012 및 .Net 4.5를 설치하여 소개 된 것으로 보입니다.

MS 라이브러리를 변경할 수 없으므로 참조하고 있으며 대상 배포 환경이 64 비트 일뿐 이므로이 문제를 무시할 수 있습니다.

경고는 어떻습니까? Microsoft는 Connect 보고서 에 대한 응답으로 경고를 비활성화하는 옵션 중 하나 를 게시했습니다 . 솔루션 아키텍처에 대해 잘 알고 있으며 배포 대상을 완전히 이해하고 개발 환경 외부에서는 실제로 문제가되지 않는다는 것을 알고 있어야합니다.

프로젝트 파일을 편집하고이 속성 그룹과 설정을 추가하여 경고를 비활성화 할 수 있습니다.

<PropertyGroup>
  <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>

일반적으로 "열린 DLL, 닫힌 EXE"는 다음과 같습니다.

• EXE 는 x86 또는 x64를 지정하여 OS를 대상으로합니다.
• DLL 은 열린 상태 (즉, AnyCPU)로 유지되므로 32 비트 또는 64 비트 프로세스 내에서 인스턴스화 할 수 있습니다.

EXE를 AnyCPU로 빌드 할 때 OS에 사용할 프로세스 비트 비트에 대한 결정을 연기하면 EXE가 원하는대로 JIT됩니다. 즉, x64 OS는 64 비트 프로세스를 만들고 x86 OS는 32 비트 프로세스를 만듭니다.

DLL을 AnyCPU로 빌드하면 두 프로세스와 호환됩니다.

조립품 로딩의 미묘함에 대한 자세한 내용은 여기를 참조 하십시오 . 요약 내용은 다음과 같습니다.

• AnyCPU – 호출 프로세스에 따라 x64 또는 x86 어셈블리로로드
• x86 – x86 어셈블리로로드합니다. x64 프로세스에서로드되지 않습니다
• x64 – x64 어셈블리로로드합니다. x86 프로세스에서로드되지 않습니다

C # DLL은 플랫폼 대상 x86으로 설정됩니다.

어떤 종류의 문제인지, DLL은 실제로 프로세스의 비트가 무엇인지 선택할 수 없습니다. 그것은 EXE 프로젝트에 의해 완전히 결정됩니다.로드되는 첫 번째 어셈블리이므로 플랫폼 대상 설정이 프로세스의 비트 수를 세고 설정합니다.

DLL은 선택의 여지가 없으며 프로세스 비트와 호환되어야합니다. 그렇지 않으면 코드에서 사용하려고 할 때 BadImageFormatException과 함께 큰 Kaboom이 발생합니다.

따라서 DLL에 대한 올바른 선택은 AnyCPU이므로 어느 쪽이든 작동합니다. C #을 DLL에 대한 이해의 그 차종의 많은, 그들은 할 일 중 하나의 방법을. 그러나 C ++ / CLI 혼합 모드 DLL이 아니라 프로세스가 32 비트 모드에서 실행될 때만 잘 작동 할 수있는 관리되지 않는 코드가 포함되어 있습니다. 빌드 시스템이 이에 대한 경고를 생성하도록 할 수 있습니다 . 정확히 당신이 얻은 것입니다. 경고 만해도 제대로 빌드됩니다.

문제를 해결하십시오. EXE 프로젝트의 플랫폼 대상을 x86으로 설정하면 다른 설정에서는 작동하지 않습니다. 그리고 모든 DLL 프로젝트를 AnyCPU에 보관하십시오.

나는 내가 한 것과 같은 경고를 받고 있었다 :

1. 프로젝트를 내리다
2. 프로젝트 속성 편집 (예 : .csproj)

3. 다음 태그를 추가하십시오.

   <PropertyGroup>
       <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
           None
       </ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
   </PropertyGroup>

4. 프로젝트를 다시로드

나는 오늘이 문제가 있었고 Visual Studio에서 건물 구성을 보는 것은 도움이되지 않았습니다. 빌드되지 않은 프로젝트와 참조 된 프로젝트 모두에 대한 모든 CPU를 보여 주었기 때문입니다.

그런 다음 참조 된 프로젝트의 csproj를 살펴보고 이것을 찾았습니다.

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<PlatformTarget>x64</PlatformTarget>

어떻게 든이 PlatformTarget이 구성 변경 중에 추가되어 IDE가 그것을 보지 못했습니다.

참조 된 프로젝트 에서이 줄을 제거하면 문제가 해결되었습니다.

C # DLL에 x86 기반 종속성이있는 경우 DLL 자체는 x86이어야합니다. 나는 그 주위에 방법을 실제로 보지 못합니다. 64 비트 실행 파일은 32 비트 라이브러리를로드 할 수 없으므로 VS는 (예를 들어) x64로 변경하는 것에 대해 불평합니다.

C ++ 프로젝트의 구성에 대해 약간 혼란 스럽습니다. 빌드에 제공된 경고 메시지는 대상 플랫폼이 [MSIL] 인 것으로보고했기 때문에 AnyCPU를 대상으로했음을 나타내지 만 프로젝트 구성은 실제로 Win32임을 나타냅니다. 네이티브 Win32 앱에는 MSIL이 포함되어서는 안됩니다. C # 라이브러리와 상호 작용하는 경우 CLR 지원을 활성화해야 할 수 있습니다. 정보 측면에 약간의 차이가 있다고 생각합니다.

프로젝트의 정확한 구성과 프로젝트가 어떻게 관련되어 있는지 좀 더 자세히 검토하고 게시 해 주시겠습니까? 가능하면 더 도와 드리겠습니다.

데이비드 자루의 대답 이외에, 당신은 또한 이동해야 할 수 Build의 탭 Project Properties과 세트 Platform Target로 x86당신에게 이러한 경고를 제공하는 프로젝트. 예상 할 수 있지만이 설정은 구성 관리자의 설정과 완벽하게 동기화되지 않은 것 같습니다.

C # 프로젝트의 경우 x86의 대상은 소리처럼 작동합니다. 이 어셈블리는 x86 아키텍처 만 지원한다고합니다. x64도 마찬가지입니다. 반면에 어떤 CPU는 어떤 아키텍처를 신경 쓰지 않는다고 말하면서 두 가지를 모두 지원합니다. 따라서 다음 두 가지 질문은 (1) 이러한 dll을 사용하는 실행 파일의 구성은 무엇입니까? 그리고 (2) 무엇입니까 비트OS / 컴퓨터의 내가 묻는 이유는 실행 파일이 64 비트로 실행되도록 컴파일 된 경우 64 비트 모드로 실행할 수 있도록 모든 종속성을 필요로하기 때문입니다. 모든 CPU 어셈블리를로드 할 수 있지만 x86 구성에서만 실행할 수있는 다른 종속성을 참조하고있을 수 있습니다. 64 비트 모드에서 실행 파일을 실행하려는 경우 모든 종속성 및 종속성 종속성을 확인하여 모든 것이 "Any CPU"또는 "x64"인지 확인하십시오. 그렇지 않으면 문제가 있습니다.

여러 가지면에서 Visual Studio는 모든 CPU와 다양한 아키텍처 종속 어셈블리를 쉽게 컴파일 할 수 없습니다. 가능하지만, "어떤 CPU"인 어셈블리는 x86과 x64에 대해 별도로 컴파일해야 할 필요가 있습니다. 어딘가의 종속 종속성에는 두 가지 버전이 있기 때문입니다.

SharePoint와 같은 기존 x64 솔루션에 테스트 솔루션을 추가 할 때와 비슷한 문제가있었습니다. 필자의 경우 특정 프로젝트 템플릿이 기본적으로 특정 플랫폼으로 추가된다는 사실과 관련이있는 것 같습니다.

다음은 종종 저에게 적합한 솔루션입니다. Configuration Manager에서 모든 것을 올바른 플랫폼으로 설정하십시오 (활성 구성 드롭 다운은 정상적으로 디버그하는 것이 좋습니다) 및 프로젝트 플랫폼 (프로젝트 속성) 빌드 한 다음 모든 것을 AnyCPU로 다시 설정하십시오. 때로는 일부 종속성 (각 프로젝트의 속성에서 DLL)을 제거하고 다시 추가해야하며 때로는 "32 비트 또는 64 비트 프로세스에서 테스트 실행"(Local.testsettings를 두 번 클릭하고 호스트로 이동)을 변경해야합니다.

이것은 단지 무언가를 설정하고 다시 설정하는 것 같지만 보이지 않는 장면 뒤에 더 많은 일이있을 것입니다. 과거에는 나에게 상당히 일관되었습니다.

내 프로젝트의 경우 x86과 x64 모두에 빌드 할 수 있어야합니다. 이것의 문제점은 하나를 사용하는 동안 참조를 추가 할 때마다 다른 하나를 만들 때 불평한다는 것입니다.

내 해결책은 * .csproj 파일을 수동으로 편집하여 다음과 같은 줄을 만드는 것입니다.

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=x86"/>

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=AMD64"/>

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL"/>

이것으로 변경하십시오 :

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral"/>

MS UNIT Test DLL로 인해 비슷한 문제가 발생했습니다. 내 WPF 응용 프로그램은 x86으로 컴파일되었지만 단위 테스트 DLL (참조 EXE 파일)은 "Any CPU"입니다. x86 (EXE와 동일) 용으로 컴파일되도록 단위 테스트 DLL을 변경했으며 해결되었습니다.

f.csproj가 빌드시 명령이므로 해결하기 쉽지 않은 MS Fakes 어셈블리에 대해서도이 경고가 표시 될 수 있습니다. 운 좋게도 Fakes xml을 사용하면 거기에 추가 할 수 있습니다 .

.NET EXE / DLL AnyCPU 및 x86 및 x64로 컴파일 된 의존하는 관리되지 않는 DLL을 만드는 방법이 있어야합니다. 둘 다 다른 파일 이름으로 번들 된 다음 .NET 모듈이 런타임에 따라 올바른 파일을 동적으로로드합니다. 프로세서 아키텍처. 그러면 AnyCPU가 강력 해집니다. C ++ DLL이 x86 또는 x64 만 지원한다면 AnyCPU는 의미가 없습니다. 그러나 구성 관리자가 구현하지 않았으므로 번들로 제공되는 두 가지 아이디어는 여러 가지 번들링을 위해 AnyCPU 또는 다른 구성과 같은 다른 개념을 가능하게하는 다른 구성 / 플랫폼으로 동일한 프로젝트를 두 번 빌드하는 수단조차 제공하지 않습니다.

내 빌드에서 매우 비슷한 경고가있었습니다. 내 프로젝트는 빌드 서버에서 Windows 8.1 SDK (.NET 4.5.1 용)가 설치된 .NET 4.5를 대상으로 설정되었습니다. .NET 4.5.1을 대상으로 프로젝트를 업데이트 한 후 (문제는 아니고 완전히 새로운 응용 프로그램이었습니다) 더 이상 경고를받지 못했습니다 ...

"Configuration Manager"를 릴리스 (Mixed Plataform)로 변경하여이 경고를 해결했습니다.

SQL Server 2012 SP2를 설치할 때까지 SQL Server 2012 SP1 SSIS 파이프 라인 스크립트 작업을 컴파일 할 때 Visual Studio 2012에서이 경고가 나타납니다.

SQLite 열기 연결과 동일한 문제가 있었고 Nuget을 사용하고 프로젝트 (SQLite)에 사용 된 구성 요소를 설치하면 문제가 해결되었습니다! 이 방법으로 구성 요소를 설치하고 결과를 확인하십시오

https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build#directorybuildprops-example을 사용 하십시오 .

• 솔루션 폴더에 Directory.Build.props 파일 추가
• 이것을 붙여 넣으십시오 :

<Project>
 <PropertyGroup>
   <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
 </PropertyGroup>
</Project>