Menu
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.
346
On 64-bit Windows, a 64-bit process cannot load a 32-bit dynamic-link library (DLL). Additionally, a 32-bit process cannot load a 64-bit DLL. However, 64-bit Windows supports remote procedure calls (RPC) between 64-bit and 32-bit processes (both on the same computer and across computers).
Solution. You cannot call a 64-bit DLL from 32-bit LabVIEW. This is a limitation of 64-bit Windows, which does not support mixed 64-bit/32-bit processes. The recommended solution is to recompile the DLL from the source code for a 32-bit target architecture.
If the first DLL in the path is 32 bit and your app is 32 bit, then the DLL load will work. If the app is 64 bit, it will fail to load the DLL and the process will abort. If you want two DLLs to coexist on the system path, you need to give them unique file names.
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.
131
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
