.net - net - visual studio essentials




如何修復Visual Studio編譯錯誤,“處理器體系結構之間的不匹配”? (12)

我對Visual Studio 2010中的項目配置很陌生,但我已經做了一些research ,但仍然無法完全解決這個問題。 我有一個C ++ DLL引用C#DLL的Visual Studio解決方案。 C#DLL引用了一些其他的DLL,一些在我的項目和一些外部。 當我嘗試編譯C ++ DLL時,出現以下警告:

警告MSB3270:構建“MSIL”的項目的處理器體系結構與參考“[internal C#dll]”,“x86”的處理器體系結構之間存在不匹配。

它告訴我去配置管理器來調整我的架構。 C#DLL使用平台目標x86進行設置。 如果我嘗試將其更改為其他任何內容,如Any CPU,則會發生抱怨,因為依賴的其中一個外部DLL具有平台目標x86。

當我查看配置管理器時,它將我的C#DLL的平台顯示為x86,並將我的C ++項目顯示為Win32。 這似乎是正確的設置; 當然,我不希望我的C ++項目的項目將平台設置為x64,這是唯一提供的其他選項。

我在這裡做錯了什麼?


C#DLL使用平台目標x86進行設置

這是一個問題,DLL實際上並不能選擇進程的位數。 這完全取決於EXE項目,這是第一個被加載的程序集,因此它的平台目標設置是計算和設置該進程的位數的設置。

DLL沒有選擇,它們需要與進程位相兼容。 如果他們不是,那麼當你的代碼嘗試使用它們時,你會得到一個帶有BadImageFormatException的大型Kaboom。

所以對於DLL的一個很好的選擇是AnyCPU,所以它們以任何方式工作。 這對於C#DLL很有意義,它們可以以任何方式工作。 但是,當然,不是您的C ++ / CLI混合模式DLL,它包含非託管代碼,只有當進程以32位模式運行時才能正常工作。 你可以讓構建系統生成關於這個的警告。 這正是你得到的。 只是警告,它仍然正確地建立。

只是解決問題。 將EXE項目的Platform目標設置為x86,它不會與任何其他設置一起使用。 只要將所有DLL項目保存在AnyCPU中。


一個好的經驗法則是“打開的DLL,關閉的EXE”,即:

  • EXE通過指定x86或x64來定位操作系統。
  • DLL保持開放(即AnyCPU),因此它們可以在32位或64位進程中實例化。

當您將EXE構建為AnyCPU時,您所做的只是推遲關於在OS上使用哪種進程位數的決定,這將根據EXE的喜好進行調整。 也就是說,一個x64操作系統將創建一個64位進程,一個x86操作系統將創建一個32位進程。

將DLL構建為AnyCPU可以使它們與任一進程兼容。

有關裝配加載細節的更多信息,請參見here 。 執行摘要如下所示:

  • AnyCPU - 根據調用過程加載為x64或x86程序集
  • x86 - 作為x86程序集加載; 將不會從x64進程加載
  • x64 - 加載為x64程序集; 將不會從x86進程加載

對於C#項目,x86的目標聽起來很像。 它說這個程序集只支持x86體系結構。 同樣適用於x64。 另一方面,任何CPU都表示我不關心哪個體系結構,我同時支持這兩種體系結構。 所以,接下來的兩個問題是(1)使用這些dll的可執行文件的配置是什麼? 和(2)你的OS /計算機的位數是多少? 我問的原因是因為如果您的可執行文件被編譯為64位運行,那麼它需要所有的依賴關係能夠以64位模式運行。 你的任何CPU程序集都應該能夠被加載,但也許它正在引用一些只能在x86配置下運行的其他依賴。 如果您打算以64位模式運行可執行文件,請檢查所有依賴項和依賴關係以確保所有內容都是“任意CPU”或“x64”。 否則,你會遇到問題。

在許多方面,Visual Studio不會輕鬆編譯任何CPU和各種體系結構相關程序集的混合。 這是可行的,但它通常需要一個組件,否則就是“任何CPU”必須分別編譯為x86和x64,因為某些依賴項的某個依賴項有兩個版本。


對於我的項目,我需要能夠構建到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"/>

我今天遇到了這個問題,只是在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似乎沒有看到它。

從引用的項目中刪除此行解決了我的問題。


我以前遇到類似問題,特別是在將測試解決方案添加到現有的x64解決方案(如SharePoint)時。 就我而言,這似乎與某些項目模板默認添加為某些平台的事實有關。

以下是我經常使用的解決方案:在Configuration Manager中將所有內容設置到正確的平台(活動配置下拉菜單,通常稱為調試是一種很好的方法)和項目平台(在項目屬性中),然後構建,然後將所有內容都設置回AnyCPU。 有時我必須刪除並重新添加一些依賴項(每個項目屬性中的DLL),有時需要更改“以32位或64位進程運行測試”(雙擊Local.testsettings並轉到主機)。

在我看來,這只是設置一些東西然後放回去的,但是我可能在幕後發生了更多事情,我沒有看到。 儘管如此,它對我來說仍然是一貫的。


我有與SQLite打開連接相同的問題,並使用Nuget和安裝項目中使用的組件(SQLite)修復它! 嘗試以這種方式安裝組件並檢查結果


我有類似的問題,它是由MS單元測試DLL引起的。 我的WPF應用程序被編譯為x86,但單元測試DLL(引用的EXE文件)為“任何CPU”。 我將單元測試DLL更改為x86編譯(與EXE相同),並將其解壓縮。


我解決了這個警告,將“Configuration Manager”更改為Release(混合Plataform)。



這個警告似乎是在新的Visual Studio 11 Beta和.NET 4.5中引入的,儘管我想這可能是以前可能的。

首先,這只是一個警告。 如果你只是處理x86依賴關係,它不應該傷害任何東西。 當您聲明您的項目與“任何CPU”兼容,但您依賴於x86或x64的項目或.dll程序集時,Microsoft只是試圖警告您。 因為你有一個x86依賴項,所以在技術上你的項目不是“任何CPU”兼容的。 要使警告消失,實際上應該將項目從“任何CPU”更改為“x86”。 這很容易做到,這裡是步驟。

  1. 轉到Build | Configuration Manager菜單項。
  2. 在列表中找到你的項目,在平台下,它會說“任何CPU”
  3. 從下拉列表中選擇“Any CPU”選項,然後選擇<New..>
  4. 在該對話框中,從“New Platform”下拉列表中選擇x86,並確保在“Copy settings from”下拉列表中選擇“Any CPU”。
  5. 點擊確定
  6. 您將要為Debug和Release配置選擇x86。

這將使警告消失,並且聲明您的程序集或項目現在不再是“任何CPU”兼容的,但現在是x86特定的。 如果您正在構建具有x64依賴項的64位項目,這也適用; 你只需要選擇x64。

還有一點需要注意的是,如果項目是純.NET項目,項目通常可以兼容“任何CPU”。 如果你引入了一個針對特定處理器體系結構的依賴關係(第三方dll或你自己的C ++託管項目),那麼這個問題才會出現。


這是一個非常固執的警告,雖然它是一個有效的警告,但也有一些情況下,由於使用第三方組件和其他原因無法解決。 我有一個類似的問題,除了警告是因為我的項目平台是AnyCPU,而且我引用了為AMD64構建的MS庫。 順便說一下,這在Visual Studio 2010中,似乎是通過安裝VS2012和.Net 4.5引入的。

由於我無法更改引用的MS庫,並且由於我知道我的目標部署環境只能是64位,所以我可以放心地忽略此問題。

那警告呢? 微軟發布了一篇關於連接報告的回應,其中一個選項是禁用該警告。 你只應該這樣做,你是非常了解你的解決方案架構,並且你完全理解你的部署目標,並且知道這不是開發環境之外的問題。

您可以編輯您的項目文件並添加此屬性組並設置為禁用警告:

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




visual-studio