如何在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位版本

回答

相关问题