I am writing an Outlook VSTO addin using Visual Studio. The addin uses SQLite. It needs a dll called SQLite.interop.dll. This comes in a 32-bit version and 64-bit version, and Outlook wants the correct version. If the end user is running a 32-bit version of Office on a 64-bit CPU, Outlook needs the 32-bit version of the dll, and the 64-bit version doesn't work. Three questions:
Is there a way of detecting whether the user is running a 32-bit or 64-bit version of Office?
Is it possible in Visual Studio to do two builds of the same project, one containing the 32-bit dll and one containing the 64-bit dll, or do I need two separate projects?
Is there some other way of managing this?
Thanks,
Paul
Your addin is always running with the same bitness as Outlook, just compile it as "Any CPU".
Keep both dlls (or embed them as resource), and at run-time determine the bitness by evaluating the size of the IntPtr type - 4 for 32 bit, and 8 for 64. Then extract/load the dll of the right bitness.
Related
I have an add in for Microsoft Word, if I launch it from Visual Studio it open and run correctly but when I try to build and install the .msi on a 64 bit windows 7 I have a problem.
The installation end fine but when I try to open the add in, Word raise an error because it search for the add in in x64 programs file and not in x86 folder. I want that the add in is installed only in x86 programs file and I have specified as Target platform x86 and defaultLocation [ProgramFilesFolder][Manufacturer][ProductName].
What is the error?
There are 32-bit and 64-bit versions of Office, so the most likely cause of this issue is that the user has installed 64-bit Office. That means that it must look in the 64-bit locations because a 64-bit process cannot load a 32-bit Dll. You're referring to the x86 locations, so I'm assuming that your code is 32-bit.
If you don't want to support 64-bit Office then you'll need to detect when there is a 64-bit Word or Office on the system and stop the installation. If you do want to support 32 and 64-bit Office then build your 32-bit one, and then build another MSI with 64-bit target location, 64-bit code, and 64-bit folders such as ProgramFiles64Folder. Your users install the appropriate one for their Office architecture version.
We have a decent size project in Visual Studios 2010 that needs to be built for 32bit and 64bit machines. Simple enough, however, we rely on a third part library for certain functionality and this third party library has a 32-bit version and a 64-bit version.
Now, If i was to build a 32-bit version of this project, I would obviously want to reference the 32-bit version of the third party's library, and the same goes for when building the 64-bit version.
How exactly is the best way to go about doing this in Visual Studios without having to switch between 32-bit and 64-bit every time I do a build?
You will need to make different configurations and each configuration will reference it's version, when you build, you just choose the 32 or 64 configuration.
I have a problem related to this question. Two players:
C# application
Mixed assembly used by 1)
The application has to support anything from Windows XP (32bit) to Windows 7 (32 & 64bit). The assembly is complicated in different ways. It contains managed C++/CLI code and some native C++ classes dancing with native DirectX. It also is linked to a few 32bit native dll's w/o source access (containing C++ classes with import libraries).
Things are working well in 32bit environments (XP and 7 tested) including the 32bit subsystem on Windows 7. Havoc happens, as soon as "Any CPU" is used on 64bit systems in order to build the complete solution. The 32bit assembly is unusable than - but seemingly only in debug mode ("cannot load, wrong format" etc.). It seems to work in release. A 64bit assembly build is prevented by the implicit dependencies to the mentioned 32bit third-party dll's.
Is there any way to provide a real native 64bit application able to use the assembly?
Requirement for the assembly isn't that strict. It could be both - 32 or 64bit - but as said above, should be be usable from the application one way or the other.
You are running into a rock hard limitation in the 64-bit version of Windows, a 64-bit process cannot execute any 32-bit machine code in-process. You certainly have a dependency on machine code when you use C++/CLI and work with DirectX. Although it doesn't sound like you could not execute in 64-bit mode, both C++/CLI and DirectX can be compiled/are available in 64-bit.
This then boils down to a build and deployment issue. You have to build the C++/CLI project(s) in 64-bit mode and deploy only 64-bit components on a 64-bit operating system. The main EXE must be built to AnyCPU. Similarly, on a 32-bit operating system you must build and deploy only the 32-bit compiled version. You solve the build issue by adding the x64 configuration to the solution so you build the 32-bit and 64-bit version separately. You solve the deployment issue by creating two installers.
Since you have to support a 32-bit operating system anyway, the simple solution is to change the Target platform setting on your EXE project to x86. Now everything always runs in 32-bit mode and you don't have to bother with the build and deployment headaches. The only thing you miss out on is the larger virtual memory address space that's available in the 64-bit version.
Forget about the C++/CLI project for a minute.
You have third-party 32-bit DLLs. These CANNOT load in a 64-bit process. So your main application will have to be 32-bit. This restriction has nothing to do with the C++/CLI middleman.
The only way you can make use of these DLLs from a 64-bit application is to load them in a separate (32-bit) process and marshal data back and forth.
I am creating a Visual Studio 2010 Setup project for installing my application. My application works by having multiple executable for different system bitness, and detects if you are running on a 32-bit or 64-bit system.
I'd like to have the Visual C++ 2010 x64 Runtime installed by the installer if it is a 64-bit system. Setting this as a prerequisite, disables installation on 32-bit systems. Is there any way to set this as a prerequisite, but only on 64-bit systems, without resorting to two different installers?
You need to create separate MSI files for the 64-bit version and the 32-bit version to deal with the specialities of WOW64.
It is not possible to have one single MSI install both a 64-bit and a 32-bit version:
Different Packages are Required for Different Processor Architectures
Because you will have separate MSI files it should be easy to add the 64-bit VC++ Runtime Redistributables to the 64-bit MSI and the 32-bit ones to the 32-bit MSI respectively.
Of course, you may create a bootstrapper that checks the system architecture and then launches the respective MSI file. I believe dotNetInstaller offers such a mechanism as has been indicated in a related question.
I'm wondering if I can still develop 32-bit apps using a 64-bit machine (64-bit Windows Vista with Visual Studio 2008 SP1)? Because I am planning to buy a laptop with 64-bit Vista. Im asking just to make sure. Thanks!
64-bit Windows runs 32-bit Visual Studio just fine. Unless you specify you wish you use the x64 development tools, it will still compile 32-bit applications.
Straight from the page:
Visual Studio uses the 32-bit cross
compiler even on a Windows 64-bit
computer. You can, however, use devenv
commands to create a command line
environment to call 64-bit hosted
tools.
Further Information: http://msdn.microsoft.com/en-us/library/ms246588(VS.80).aspx
With Visual Studio you are able to target what platform. By default it will run on "Any CPU" (read 32 or 64 bit), but you can specify if you desire. Look under Project>Properties>Build and look for the "Platform Target" property.
Yes. 64-bit vista will run 32-bit executables, so if you have a 32-bit compiler, it will still work.
Within visual studio you can tell it what to compile to under the Configuration Manager - (Build Menu - Configuration manager) - this allows you to target 32 or 64 bit.
64bit of consumer hardwares is usually "amd64" architecture which can run both 32bit apps and 64bit ones natively. Windows Vista 64bit edition supports both 32bit and 64bit system libraries, so basically you can run both type of applications as well. (Note that IA-64 architecture does not allow this.)
Compiling a program in 64bit is not much related to the platform that the compiler runs. But, of course, to run and test the result binary requires the corresponding architecture.
As many mentioned above, VS2008 let you choose the target architecture, so there's no problem.
I've found that just the setup.exe created by Visual Studio 2012 Express won't work on XP, but if you go ahead load MS 4.0 .NET Framework from the Microsoft Website then the *.application will load and install without using the setup.exe at all.