Visual Studio 컴파일 오류인 "프로세서 아키텍처 간 불일치"를 해결하려면 어떻게 해야 합니까?
Visual Studio 2010의 프로젝트 구성은 처음이지만 몇 가지 조사를 해봤지만 여전히 이 문제를 제대로 파악할 수 없습니다.C# DLL을 참조하는 C++ DLL이 있는 Visual Studio 솔루션이 있습니다.C# DLL은 몇 가지 다른 DLL을 참조하며, 일부는 내 프로젝트 내에서, 일부는 외부에서 참조합니다.C++ DLL을 컴파일하려고 하면 다음과 같은 경고가 표시됩니다.
MSB3270 경고: 빌드 "MSIL" 프로젝트의 프로세서 아키텍처와 참조 "[내부 C# dll], "x86"의 프로세서 아키텍처가 일치하지 않습니다.
구성 관리자로 이동하여 아키텍처를 조정하라는 메시지가 표시됩니다.C# DLL은 플랫폼 대상 x86으로 설정됩니다.이를 Any CPU와 같은 다른 것으로 변경하려고 하면 종속된 외부 DLL 중 하나에 플랫폼 대상 x86이 있기 때문에 불만이 제기됩니다.
Configuration Manager를 보면 C# DLL의 Platform은 x86으로 표시되고 C++ 프로젝트의 Platform은 Win32로 표시됩니다.이것은 올바른 설정인 것 같습니다. 확실히 저는 제 C++ 프로젝트의 프로젝트가 제시된 유일한 다른 옵션인 x64로 설정되는 것을 원하지 않습니다.
내가 여기서 뭘 잘못하고 있는 거지?
이 경고는 새로운 Visual Studio 11 베타 및 .NET 4.5와 함께 도입된 것으로 보이지만 이전에는 가능했을 수도 있습니다.
첫째, 그것은 정말로 경고에 불과합니다.x86 종속성을 처리하는 경우에는 아무런 문제가 되지 않습니다.Microsoft는 프로젝트가 "모든 CPU"와 호환되지만 x86 또는 x64인 프로젝트 또는 .dll 어셈블리에 종속되어 있다고 말할 때 경고하려고 합니다.x86 종속성을 가지고 있기 때문에 기술적으로 프로젝트는 "모든 CPU"와 호환되지 않습니다.경고를 없애려면 프로젝트를 "모든 CPU"에서 "x86"으로 변경해야 합니다.이 작업은 매우 쉽습니다. 단계는 다음과 같습니다.
- 빌드/구성 관리자 메뉴 항목으로 이동합니다.
- 목록에서 프로젝트를 찾으십시오. Platform(플랫폼) 아래에 "Any CPU(모든 CPU)"라고 표시됩니다.
- 에서 " CPU"후 "Any CPU"를 합니다.
<New..>
- 이 대화 상자에서 "새 플랫폼" 드롭다운에서 x86을 선택하고 "설정 복사 위치" 드롭다운에서 "모든 CPU"가 선택되었는지 확인합니다.
- 확인을 누릅니다.
- 디버그 및 릴리스 구성 모두에 대해 x86을 선택할 수 있습니다.
그러면 경고가 사라지고 어셈블리 또는 프로젝트가 더 이상 "모든 CPU"와 호환되지 않지만 x86에만 해당된다는 내용이 표시됩니다.이는 x64 종속성을 가진 64비트 프로젝트를 빌드하는 경우에도 적용됩니다. 대신 x64를 선택하면 됩니다.
하나는 순수한 .NET 프로젝트인 경우 프로젝트는 일반적으로 "모든 CPU"와 호환될 수 있다는 점입니다.이 문제는 특정 프로세서 아키텍처를 대상으로 하는 종속성(타사 dll 또는 자체 C++ 관리 프로젝트)을 도입한 경우에만 발생합니다.
이는 매우 강력한 경고이며, 유효한 경고이지만 타사 구성 요소의 사용 및 기타 이유로 인해 해결할 수 없는 경우가 있습니다.제 프로젝트 플랫폼이 AnyCPU이고 AMD64용으로 구축된 MS 라이브러리를 참조하고 있기 때문이라는 경고를 제외하고는 비슷한 문제가 있습니다.참고로 Visual Studio 2010에서는 VS2012 및 를 설치하여 이 기능을 도입한 것으로 보입니다.넷 4.5.
참조하고 있는 MS 라이브러리를 변경할 수 없고 대상 배포 환경이 64비트만 될 것이라는 것을 알고 있으므로 이 문제는 무시해도 무방합니다.
경고는?연결 보고서에 대한 응답으로 Microsoft는 해당 경고를 비활성화하는 옵션이 하나 있다고 게시했습니다.솔루션 아키텍처에 대해 잘 알고 있고 구축 목표를 완전히 이해하고 있으며 개발 환경 외부의 문제가 아니라는 것을 알고 있어야 합니다.
프로젝트 파일을 편집하고 이 속성 그룹 및 설정을 추가하여 경고를 사용하지 않도록 설정할 수 있습니다.
<PropertyGroup>
<ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>
경험칙으로는 "열린 DLL, 닫힌 EXE", 즉 다음과 같습니다.
- EXE는 x86 또는 x64를 지정하여 OS를 대상으로 합니다.
- DLL은 열려 있으므로(즉, AnyCPU) 32비트 또는 64비트 프로세스 내에서 인스턴스화할 수 있습니다.
AnyCPU로 EXE를 구축할 때는 사용할 프로세스 비트에 대한 결정을 OS로 미루는 것만으로 EXE를 원하는 대로 JIT할 수 있습니다.즉, x64 OS는 64비트 프로세스를 생성하고 x86 OS는 32비트 프로세스를 생성합니다.
DLL을 AnyCPU로 구축하면 두 프로세스 모두 호환됩니다.
어셈블리 로드의 세부 사항에 대한 자세한 내용은 여기를 참조하십시오.요약본에는 다음과 같은 내용이 있습니다.
- 모든 CPU – 호출 프로세스에 따라 x64 또는 x86 어셈블리로 로드
- x86 – x86 어셈블리로 로드, x64 프로세스에서 로드되지 않음
- x64 – x64 어셈블리로 로드, x86 프로세스에서 로드되지 않음
C# DLL이 플랫폼 대상 x86으로 설정되었습니다.
문제는 DLL이 실제로 프로세스의 비트를 선택할 수 없다는 것입니다.이는 EXE 프로젝트에 의해 전적으로 결정됩니다. EXE 프로젝트는 로드되는 첫 번째 어셈블리이므로 플랫폼 대상 설정이 프로세스에 대한 비트를 계산하고 설정합니다.
DLL은 선택의 여지가 없습니다. 프로세스 비트와 호환되어야 합니다.그렇지 않으면 코드가 사용하려고 할 때 잘못된 이미지 형식 예외가 있는 큰 카붐이 표시됩니다.
따라서 DLL에 적합한 선택은 AnyCPU이므로 어느 쪽이든 작동합니다.C# DLL은 어느 쪽이든 작동합니다.그러나 C++/CLI 혼합 모드 DLL이 아니라 프로세스가 32비트 모드에서 실행될 때만 제대로 작동할 수 있는 관리되지 않는 코드가 포함되어 있습니다.빌드 시스템에서 이에 대한 경고를 생성하도록 할 수 있습니다.그게 바로 당신이 가진 것입니다.경고만 해도 제대로 구축됩니다.
그냥 문제를 푼다.EXE 프로젝트의 플랫폼 대상을 x86으로 설정합니다. 다른 설정에서는 작동하지 않습니다.모든 DLL 프로젝트를 AnyCPU에 저장합니다.
저는 제가 한 것과 같은 경고를 받고 있었습니다.
- 프로젝트 언로드
- 프로젝트 속성 편집(예: syslogroj)
다음 태그를 추가합니다.
<PropertyGroup> <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch> None </ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch> </PropertyGroup>
프로젝트 다시 로드
오늘 이 문제가 발생했습니다. 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는 이를 보지 못한 것 같습니다.
참조된 프로젝트에서 이 라인을 제거하여 문제가 해결되었습니다.
https://learn.microsoft.com/en-us/visualstudio/msbuild/customize-your-build#directorybuildprops-example 사용:
- 디렉토리를 추가합니다.솔루션 폴더에 .props 파일 구축
- 붙여넣기:
<Project>
<PropertyGroup>
<ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>
</Project>
C# DLL에 x86 기반 종속성이 있는 경우 DLL 자체가 x86이어야 합니다.저는 그것을 피할 방법을 잘 모르겠습니다.VS는 64비트 실행 파일이 32비트 라이브러리를 로드할 수 없기 때문에 x64로 변경하는 것에 대해 불만을 표시합니다.
저는 C++ 프로젝트의 구성에 대해 조금 혼란스럽습니다.빌드에 대해 제공된 경고 메시지는 AnyCPU가 대상 플랫폼이 [MSIL]이라고 보고했기 때문에 AnyCPU를 대상으로 했다는 것을 나타내지만 프로젝트에 대한 구성이 실제로 Win32라고 표시했습니다.기본 Win32 앱은 MSIL을 포함하지 않아야 하지만 C# 라이브러리와 상호 작용하는 경우 CLR 지원을 활성화해야 합니다.그래서 저는 정보 측면에 몇 가지 차이가 있다고 생각합니다.
프로젝트의 정확한 구성과 상호 관련성에 대해 좀 더 자세히 검토하고 게시해 주실 수 있을까요?가능하다면 기꺼이 더 많은 도움을 드리겠습니다.
David Sacks의 답변 외에도, 당신은 또한 웹사이트로 가야 할 수도 있습니다.Build
의 탭Project Properties
트세를 합니다.Platform Target
x86
이러한 경고를 제공하는 프로젝트에 대해 설명합니다.예상할 수 있지만 이 설정이 구성 관리자의 설정과 완벽하게 동기화되지 않은 것 같습니다.
C# 프로젝트의 경우 x86의 대상은 소리가 나는 대로 합니다.이 어셈블리는 x86 아키텍처만 지원한다고 합니다.x64도 마찬가지입니다.반면 CPU는 어느 아키텍처든 상관없고 둘 다 지원한다고 말합니다.다음 두 가지 질문은 (1) 이러한 dll을 사용하는 실행 파일의 구성은 무엇입니까? (2) OS/컴퓨터의 비트는 무엇입니까?제가 요청하는 이유는 실행 파일이 64비트로 실행되도록 컴파일된 경우 64비트 모드에서도 실행할 수 있도록 모든 종속성이 필요하기 때문입니다.모든 CPU 어셈블리를 로드할 수 있어야 하지만 x86 구성에서만 실행할 수 있는 다른 종속성을 참조하는 것일 수 있습니다.64비트 모드에서 실행 파일을 실행하려는 경우 모든 종속성 및 종속성을 확인하여 모든 항목이 "모든 CPU" 또는 "x64"인지 확인합니다.그렇지 않으면 문제가 생길 것입니다.
여러 면에서 Visual Studio는 모든 CPU와 다양한 아키텍처 종속 어셈블리의 혼합물을 쉽게 컴파일할 수 없습니다.실행할 수는 있지만 일부 종속성에는 두 가지 버전이 있기 때문에 "모든 CPU"가 아닌 어셈블리를 x86과 x64용으로 별도로 컴파일해야 하는 경우가 종종 있습니다.
저도 비슷한 문제를 겪은 적이 있습니다. 특히 쉐어포인트와 같은 기존 x64 솔루션에 테스트 솔루션을 추가할 때 그렇습니다.저의 경우, 기본적으로 특정 프로젝트 템플릿이 특정 플랫폼으로 추가되는 것과 관련이 있는 것 같습니다.
자주 사용할 수 있는 솔루션은 다음과 같습니다. 구성 관리자(일반적으로 디버그라고 하는 활성 구성 드롭다운)와 프로젝트 플랫폼(프로젝트 속성)에서 모든 것을 올바른 플랫폼으로 설정한 다음 빌드하고 모든 것을 AnyCPU로 다시 설정하는 것입니다.때로는 일부 종속성(각 프로젝트의 속성에 있는 DLL)을 제거했다가 다시 추가해야 하고, 때로는 "32비트 또는 64비트 프로세스에서 테스트 실행"(Local.test 설정을 두 번 클릭하고 Hosts로 이동)을 변경해야 합니다.
제가 보기에 이것은 단지 무언가를 설정하고 그것을 되돌리는 것처럼 보이지만, 아마도 제가 보지 못하는 이면에는 더 많은 일들이 있을 것입니다.하지만 과거에는 꽤 꾸준히 효과가 있었습니다.
제 프로젝트를 위해서는 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"입니다.유닛 테스트 DLL을 x86용으로 컴파일되도록 변경했는데(EXE와 동일) 수정되었습니다.
f.csproj가 build on 명령이기 때문에 해결하기가 쉽지 않은 MS Fake 어셈블리에 대해서도 이 경고가 표시될 수 있습니다.다행히도 가짜 xml을 사용하면 거기에 추가할 수 있습니다.
IIS Express를 사용하고 있는데 웹 프로젝트의 비트 수가 64로 설정되어 있는지 확인하는 것이 수정되었습니다.
Properties에서 Platform target을 "Any CPU"로 변경하면 됩니다!릴리스 빌드를 만들어야 할 수도 있습니다.
작업 방법:
제 체격에도 비슷한 경고가 있었습니다.프로젝트는 빌드 서버에 윈도우즈 8.1 SDK(.NET 4.5.1용)가 설치된 .NET 4.5를 대상으로 설정되었습니다.프로젝트를 target .NET 4.5.1(완전히 새로운 애플리케이션의 경우)로 업데이트한 후 더 이상 경고를 받지 못했습니다.
이 경고를 "구성 관리자"를 릴리스(혼합 플랫폼)로 변경하여 해결했습니다.
SQL Server 2012 SP1 SSIS 파이프라인 스크립트 작업을 컴파일할 때 SQL Server 2012 SP2를 설치할 때까지 Visual Studio 2012에서 이 경고가 발생했습니다.
SQLite를 열 때도 같은 문제가 있었는데, Nuget을 사용하여 프로젝트(SQLite)에 사용된 구성 요소를 설치하는 것이 해결되었습니다! 이 방법으로 구성 요소를 설치하고 결과를 확인해 보십시오.
여기서 답을 찾지 못하는 사람들을 위해 글을 올리고 싶습니다. 그들의 문제를 해결했습니다.
응용 프로그램을 실행할 때 솔루션 플랫폼 드롭다운이 올바르게 설정되어 있는지 확인하십시오. 내 것은 x86에 있었고, 이로 인해 이 문제가 발생했습니다.
.NET EXE/DLL AnyCPU 및 이에 의존하는 관리되지 않는 DLL을 x86 및 x64로 컴파일하여 런타임 프로세서 아키텍처를 기반으로 .NET 모듈이 올바른 파일 이름을 동적으로 로드하는 방법이 있어야 합니다.그러면 AnyCPU가 강력해집니다.C++ DLL이 x86이나 x64만 지원한다면 당연히 AnyCPU는 의미가 없습니다.그러나 구성 관리자로서 아직 구현되지 않은 두 가지 아이디어 모두 AnyCPU 또는 기타 구성과 같은 개념을 가능하게 하는 다중 번들을 위한 다른 구성/플랫폼으로 동일한 프로젝트를 두 번 구축할 수 있는 수단을 제공하지 않습니다.
언급URL : https://stackoverflow.com/questions/10113532/how-do-i-fix-the-visual-studio-compile-error-mismatch-between-processor-archit
'bestsource' 카테고리의 다른 글
Angular - 구성 요소에서 module.id 의 의미는 무엇입니까? (0) | 2023.05.29 |
---|---|
ExecuteScalar, ExecuteReader 및 ExecuteNonQuery의 차이점은 무엇입니까? (0) | 2023.05.29 |
Bash 스크립트 누락 ']' (0) | 2023.05.29 |
구조 시스템을 변환하려면 어떻게 해야 합니까?시스템에 대한 바이트 바이트 []입니다.IO.C#의 스트림 개체? (0) | 2023.05.29 |
Node Sass가 현재 환경을 아직 지원하지 않음: Linux 64비트(false 포함) (0) | 2023.05.29 |