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.
Related
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.
I have Visual Studio 2010 in a 32-bit Windows 7. I need to compile my created vb.net program (lets call it myprogram.exe) to be able to run in a 64-bit Windows 7 environment.
I have set my VS2010 project to "Any CPU" and even so myprogram.exe doesn't run on a 64-bit Windows 7. However, it does on a 32-bit Windows 7.
Could be possible it's because I'm using System.Data.OracleClient for database connection?
Error message in 64-bit Windows 7:
"The version of this file is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need an x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher"
The 64-bit Windows 7 has Framework v2 installed. I attach some picture to show that.
Supposedly, WOW64 should run automatically but will not work on all applications.
In this case, should I install on my 64-bit Windows 7 some "Windows virtual PC"?
EDIT:
My VS2010 Premium is in a 32-bit Windows7 environment, and only see "Any CPU" option available. I don't see any other one else.
Should I install in the 64-bit Windows7 PC some "32-bit virtual Windows7 "? Which one would you recommend?
If you compile your program with the target platform set to AnyCPU then, when you run you executable on a 64bit OS the JIT compiler emits code for 64bit systems and, on 32bit OS, code for 32bit systems.
From your error it is clear that something between your references is a 32bit only library and thus cannot be called from 64bit code.
You could switch back to 32bit setting the x86 target platform in your Build Configuration or try to identify the library responsible and check if a 64bit version exists.
However, if you don't have specific reasons to use AnyCPU then you could still use x86 because in some cases the performances are better than 64bit code
You could read about the PROS and CONS of AnyCPU in this a little old, but still valuable, article
Try instead setting it from "Any CPU" to "x86" to force it to run on the 32-bit architecture. The problem might be that your program is relying on DLLs that aren't supported on the 64-bit architecture.
I have a windows form application which is being installed on client pc by using msi file trough active directories, application is a 32bit app which is being deployed to a 32 bit and 64 bit windows systems and as we know application folder names are different between 32 and 64 bit systems, Program Files and Program Files(x86), also during installation application shortcut is placed in startup folder so app will be started when PC us powered up.
Question: Is there a chance to build msi by Windows Installer provided by Visual Studion in such a way that it will check what operating system its being installed at and place the shortcut in to start up folder with correct URI, to Program Files\Applicaiton\ or Program Files(x86)\Applicaiton?
Thank you!
Windows Installer packages are platform aware (x86, x64 ). Windows Installer doesn't support 64bit packages running on 32bit platforms or 32bit packages writing to 64bit ProgramFiles.
You can compile your EXE as AnyCPU and even though it's installed as 32bit it'll execute as 64bit. Although the Visual Studio team has moved away from that and compile as x86 by default in recent versions of Visual Studio.
Upon initialization, the Windows Installer gathers information about the operating system and automatically sets properties that can be used in optional conditional statements used by the setup application, such as VersionNT64 and "System Folder Properties"
In cases where it is necessary for the setup to know this information, it is preferred practice to allow the Windows Installer service to determine folder locations rather than try to hard-code this information into the package.
I have installation solution that have installer project (not web installer but simple installer) that installs NT services, web service and web sites with help of additional two projects of dlls with my own code that performs my installation step. In user actions of installer project I call installer function of one of those projects, and this project calls to installer of second project: installer -> MiddleCaller -> InstallationCore.
All this developing on Windows 7 and work fine when I compile all in 32 bit.
The project must run on Windows 2008. Because of some reasons all must be in x64 bit.
For this purpose, in MiddleCaller and InstallationCore I click right button of mouse on project -> build -> targer x64. For to move installer project to 64 bit in properties of installer (when project is active) I check: Target platform: x64.
When I run installation on x86 I get error:
The installation package is not supported by this processor type"
And this is good, because now I know that my installation compiled in 64 bit, but when I run this on windows 2008 I get:
Error 1001. Exception occured while initializing the instance:
System.BadImageFormatException: could not load file or Assembly
'MiddleCaller, v...' or one of its dependencies. An attempt was
made to load a program with an incorrect format.
Any one has some idea what I need to do for run fine the installation on x64?
May be I still not moved the installer project to x64 bit, if yes, where I do this?
Thank you for ahead.
Found a quick tip on Microsoft's website that could be useful on troubleshooting setup and deployment projects:
64-bit managed custom actions throw a System.BadImageFormatException exception
If you add a 64-bit managed custom action to a Setup project, the Visual Studio build process embeds a 32-bit version of InstallUtilLib.dll into the MSI as InstallUtil. In turn, the 32-bit .NET Framework is loaded to run the 64-bit managed custom action and causes a BadImageFormatException exception.
For the workaround, replace the 32-bit InstallUtilLib.dll with the 64-bit version.
Open the resulting .msi in Orca from the Windows Installer SDK.
Select the Binary table.
Double click the cell [Binary Data] for the record InstallUtil.
Make sure "Read binary from filename" is selected and click the Browse button.
Browse to %WINDIR%\Microsoft.NET\Framework64\v2.0.50727.
Note
The Framework64 directory is only installed on 64-bit platforms and corresponds to the 64-bit processor type.
Select InstallUtilLib.dll.
Click the Open button.
Click the OK button.
There are some unclear things in this scenario. I understand that you are having difficulty running a 32-bit installer that calls on 64-bit assemblies. If this is correct, then what you are doing is not allowed. You cannot have 32-bit and 64-bit assemblies in the same process - that is illegal. If the 64-bit assemblies are being referenced by the installer directly, then the installer must also be 64-bit.
As clarification: I believe a 32-bit installer can install a 64-bit application, but it may only do so by copying the 64-bit files and not by actually making calls into the 64-bit files. The only way this is supported is if the 64-bit files are loaded into a different process and you use IPC to call into them, but even this is likely to be a bad solution.
In your case, I would encourage you to convert your installer into a 64-bit installer.
So, eventually, I compiled MiddleCaller and InstallationCore in AnyCpu mode, when all dll and executables that I need to install were compiled in x64 bit. All this I compiled on Windows 2008 x64 bit with x64 bit outer dependencies (like Oracle client).
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.