6

My business partner and I are co-developing a web app that's deployed on Azure. My box is based on 64-bit Windows 7, but my partner is using 32-bit Windows 7.

From within the VS2010 IDE when I added a reference to 'ieframe.dll' from my System32 directory (64-bit on my box), the IDE actually brought over the SysWoW64 (32-bit) version of the DLL.

Both dev boxes work perfectly with the 32-bit WOW version of 'ieframe.dll', but when we deploy to Azure we're getting a EntryPointNotFoundException when making an Interop/DllImport call into 'ieframe.dll'. So it seems like Azure wants to have the 64-bit version.

How can we deploy the 64-bit version to Azure but keep using the 32-bit version on our dev boxes?

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

EDIT #2: For this scenario, we ended up changing the node for Azure from osFamily="1" to osFamily="2". Doing this installs Windows Server 2008 R2 which includes IE8 (rather than IE7 in Windows Server 2008 SP1). No need to mess with 32 versus 64 bit versions or manually copy DLLs up to the server.

Armchair Bronco
  • 2,367
  • 4
  • 31
  • 44

1 Answers1

5

If you are always deploying to Azure from a 64-bit machine, you can alter the project file to copy the correct DLL to the bin folder at build time based on the processor type of the machine performing the build. This works great for us because we deploy to Azure from a 64-bit build server. If this sounds like a good solution, follow these steps:

1 - Create an external lib folder that contains two sub folders named 32 and 64.
2 - Place the 32-bit version of the DLL in the 32 folder and the 64-bit version in the 64 folder.
3 - Open the offending project file in a text editor.
4 - Add the following node to the project file just after the ItemGroup that conatins the "reference include" items. This will copy the correct DLL based on system supplied 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, alter the project's BeforeBuild target like so:

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

Another option would be to copy the correct DLL to the bin folder based on a build configuration (less ideal). For example, if you had a build configuration named Production you'd follow the steps above, except step 4 would contain this:

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

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

Hope this helps.

Jonathan McIntire
  • 2,665
  • 23
  • 26
  • Thanks for your detailed response. My co-founder and I considered all of the feedback you provided. In the end, he bit the bullet and decided to upgrade to a 64-bit machine with a 64-bit OS so that he, I and Azure will all be using the same 64-bit architecture. Previously, he was deploying all of the new bits to Azure from his 32-bit box. This worked fine until we ran into the issue I noted above with the ieframe.dll dependency. We hate having to support multiple configurations so it was time for him to "Man Up" to a new box! – Armchair Bronco Oct 12 '11 at 00:23
  • By the way: using a Azure startup task was the most frequently suggested workaround for our dilemma, but as you noted, of all the "fixes" it was the ugliest. Once again, we appreciate your feedback. It's nice to know how to do this if, for some reason, we have another developer on board who is wedded to a 32-bit dev machine. – Armchair Bronco Oct 12 '11 at 00:27
  • See Edit #2 above for the solution that we ultimately ended up using. – Armchair Bronco Oct 21 '11 at 21:58