How to deploy a 64-bit version on Azure DLL, but use a 32-bit version on dev-boxes

Question

My business partner and I are jointly developing a web application that is deployed on Azure . My box is based on 64-bit Windows 7 , but my partner uses 32-bit Windows 7 .

In ID2 VS2010, when I added the link to 'ieframe.dll' from my System32 directory (64-bit in my box), the IDE actually led to the SysWoW64 (32-bit) version of the DLL.

Both dev boxes work fine with the 32-bit version of WOW ieframe.dll , but when deployed to Azure, we get an EntryPointNotFoundException when creating an Interop / DllImport call in 'ieframe.dll'. So it seems that Azure wants to have a 64-bit version.

How can we deploy the 64-bit version of Azure, but continue to use the 32-bit version in our dev blocks?

EDIT: Obviously, we can do this manually by copying the 64-bit "ieframe.dll" somewhere, and then manually put it in the "bin" directory, but is there a better best way to do this in Azure?

EDIT # 2: for this scenario, we have finished changing the node for Azure from osFamily = "1" to osFamily = "2". To do this, you must install Windows Server 2008 R2, which includes IE8 (and not IE7 in Windows Server 2008 Service Pack 1). No need to bother with 32 or 64 bit versions or manually copy the DLL to the server.

Answer 1

If you always use Azure from a 64-bit machine, you can modify the project file to copy the desired DLL to the bin folder during build based on the processor type of the machine that builds. This works great for us because we are deploying Azure from a 64-bit build server. If this seems like a good solution, follow these steps:

1 - Create an external lib folder containing two subfolders named 32 and 64.
2 - Place the 32-bit version of the DLL in the 32-bit folder and the 64-bit version in the 64 folder.
3 - Open the project file with a violation in a text editor.
4 - Add the following node file to the project file immediately after the ItemGroup, which links the link elements. This will copy the correct DLL based on the system environment variables:

<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 - Finally, modify the BeforeBuild target as follows:

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

Another option is to copy the correct DLL to the bin folder based on the build configuration (less than ideal). For example, if you had an assembly configuration called Production, you would follow the steps above, except that step 4 would contain the following:

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

Another (and even less ideal) option would be to copy the 64-bit version of the DLL to the bin folder using the Azure startup task.

Hope this helps.