Home/ Questions/Q 6587369
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T16:54:30+00:00

My business partner and I are co-developing a web app that’s deployed on Azure

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0