如何在Azure上部署64位版本的DLL，但在開發盒上使用32位版本

我的業務夥伴和我正在共同開發部署在Azure上的Web應用程序。我的盒子是基於64位Windows 7，但我的合作伙伴正在使用32位Windows 7。如何在Azure上部署64位版本的DLL，但在開發盒上使用32位版本

從VS2010 IDE內時從我的System32目錄（在我的箱64位）加到一個參考「ieframe.dll」，實際上是帶過來的所述SYSWOW64（32位）版本的IDE DLL。

兩個開發盒用的「ieframe.dll」 32位WOW版本完美地工作，但是當我們部署到Azure中，我們正在做的互操作/調用的DllImport進入「ieframe當得到一個EntryPointNotFoundException。 DLL」。所以看起來Azure希望擁有64位版本。

我們如何才能將64位版本部署到Azure，但在我們的開發箱中仍然使用32位版本？

編輯：顯然，我們可以通過在某處複製64位'ieframe.dll'手動執行此操作，然後手動將它放在'bin'目錄中，但是有沒有更好的最佳實踐方式可以在Azure中執行此操作？

編輯＃2：對於這種情況，我們最終將Azure的節點從osFamily =「1」更改爲osFamily =「2」。這樣做會安裝Windows Server 2008 R2，其中包括IE8（而不是Windows Server 2008 SP1中的IE7）。不需要混淆32位和64位版本，或手動將DLL複製到服務器。

來源

2011-09-15 Armchair Bronco

如果您始終從64位計算機部署到Azure，則可以根據執行構建的計算機的處理器類型，修改項目文件以在構建時將正確的DLL複製到bin文件夾。這對我們非常有用，因爲我們從64位構建服務器部署到Azure。如果這聽起來像一個很好的解決方案，請按照下列步驟操作：

1 - 創建一個包含名爲32和64
2兩個子文件夾的外部lib文件夾 - 將DLL的32位版本在32文件夾和64位文件夾中的64位版本。
3 - 在文本編輯器中打開違規項目文件。
4 - 將以下節點添加到緊鄰包含「引用包含」項目的ItemGroup之後的項目文件中。這將根據系統提供的環境變量拷貝正確的DLL：

<ItemGroup> 
    <DllToCopy Condition=" '$(PROCESSOR_ARCHITECTURE)' == 'x86' And '$(PROCESSOR_ARCHITEW6432)' == '' " Include="..\ext-lib\32\mydll.dll" /> 
    <DllToCopy Condition=" '$(PROCESSOR_ARCHITECTURE)' == 'AMD64' Or '$(PROCESSOR_ARCHITEW6432)' == 'AMD64' " Include="..\ext-lib\64\mydll.dll" /> 
</ItemGroup>

5 - 最後，改變項目的BeforeBuild目標，像這樣：

<Target Name="BeforeBuild"> 
    <Copy SourceFiles="@(DllToCopy)" DestinationFolder="$(OutputPath)" /> 
</Target>

另一種選擇是正確的DLL複製到bin文件夾基於構建配置（較不理想）。舉例來說，如果你有一個構建配置名爲production你按照上面的步驟，除了第4步將包含此：

<ItemGroup> 
    <DllToCopy Condition=" '$(Configuration)' != 'Production' " Include="..\ext-lib\32\mydll.dll" /> 
    <DllToCopy Condition=" '$(Configuration)' == 'Production' Include="..\ext-lib\64\mydll.dll" /> 
</ItemGroup>

另一個（甚至是不太理想的）選擇是複製64位使用Azure啓動任務將DLL的版本發送到bin文件夾。

希望這會有所幫助。

來源

2011-09-21 01:33:23

感謝您的詳細回覆。我的共同創始人和我考慮了您提供的所有反饋。最後，他選擇了一個子彈，並決定升級到64位操作系統的64位機器，這樣他和我都將使用相同的64位架構。之前，他從32位盒子中將所有新位部署到Azure。這工作得很好，直到我們遇到了我上面提到的與ieframe.dll依賴項相關的問題。我們討厭不得不支持多種配置，所以現在是時候讓他「上手」到一個新盒子了！ –

順便說一下：使用Azure啓動任務是我們面臨困境的最經常建議的解決方法，但正如您所指出的，在所有「修復」中，這是最醜陋的。我們再次感謝您的反饋。如果出於某種原因，我們有另一位開發人員與32位開發機器相連，那麼知道如何做到這一點很好。 –

有關我們最終使用的解決方案，請參閱上面的編輯＃2。 –

如何在Azure上部署64位版本的DLL，但在開發盒上使用32位版本

回答

相關問題