VB.NET Winforms Program, .NET 4.0, compiled with VS2013. 100% managed code; no DLL that depend on a certain processor architecture.
I have two Visual Studio Installer projects, one for x86 and the other for x64.
The program "phones home" to find a new program; right now I detect the processor architecture to determine, if a new program exists, to download the 32-bit or 64 bit installers.
Detection code:
dim sArchitecture as String = ""
If Environment.Is64BitProcess Then
sArchitecture = "x64"
Else
sArchitecture = "x86"
End If
Problem scenario:
Customer has 64 bit machine but downloads 32 bit installer, which of course works properly. In fact, we advise customers who do not know their processor architecture to download the 32 bit installer.
32-bit installer program phones home and sends the x64 processor architecture it detects in the program. Download brings in 64-bit installer, which installs a second copy of the program into the customer's computer and confusion ensues.
What I need to figure out, if I use a Visual Studio installer project, with a TargetPlatform set to x86, is there some reliable way to detect this? Checking the install folder to see if it contains "Program Files (x86)" is insufficient; the customer may have installed the program to another location.
I would truly appreciate the Help!
Thanks
John.
Switch to the Release build and right-click your EXE project > Properties > Build tab. You have the Platform target set to AnyCPU and the Prefer 32-bit checkbox turned off.
Yes, very convenient that .NET program can automatically run in 32-bit and 64-bit mode. You don't need separate builds for the 32-bit and the 64-bit version, nice. Other than that your "detection code" no longer works reliably, the 32-bit installer still deploys a program that runs in 64-bit mode. The only way to discover what installer was used if it does not leave a bread crumb is to reverse-engineer it from the install directory. Yes, not very reliable. Leaving a bread crumb in the registry is otherwise very easy to do, installers are good at writing registry keys.
But just simplify your life, you just don't need a 64-bit specific installer at all. One gets the job done. That it is stored in the "wrong" directory just doesn't matter, you already know it works fine.
Related
I have a new VM on which I have installed Visual studio.
I created a new SSIS project, and am trying to use the oledb data source task to access an .accdb MS-Access file.
However I cannot see the Provider. So I installed the Access 32 bit runtime. Now I can see the provider. I am reading that since visual studio is a 32-bit tool, we have to install the Access 32bit runtime. Otherwise if we install the 64bit runtime, then we will not be able to see the provider in the list because visual studio is 32bit and only shows 32bit providers.
When I hit the debug button in visual studio SSIS project it can access the MS-Access file. I am now confused and want to ask - when the project is running, does it run in 32 or 64 bit mode? If the answer is 64bit mode, then how can it access the MS-access file using the 32bit provider? Does it mean that project running in 64 bit mode can utilize 32 bit mode runtime/provider?
Assuming no settings are changed, when debug button is pressed, then does the program execute is 32 or 64 bit mode? Does the OS bitness have any impact on this?
You are quite right and quite close here.
Since Visual Studio is x32 bits?
Well, if your project is set to x86 (x32 bits) or set to ANY CPU?
Then hitting F5 to run + debug (or ctrl-F5 to run the .exe without debug), then you will get (have) a x32 bit running program. Some caution here. If you use ANY cpu? then again FROM VS f5 to run - you get a x32 bit process.
But, if you go to the windows commnd line?
Well, if you launch teh windows x64 bit command line (default on most computers), then if the project is ANY cpu? Then your app run will be x64 bits. (and ANY un-manged code such as Access, or any other windows code used for COM autoamtion? it will break.
If you launch the windows x32 bit command line (with any CPU) then you get a x32 bit version running.
So, from VS - F5 - always x32 bits.
From windows command line - depends.
So, what above suggests? Well, if your intention is to have + use x32 bits process? Then FORCE/SET the project to your intentions. That way, no "by chance" will fool you, and your application will ALWAYS run as to the project settings.
So, in such cases, I do avoid ANY CPU.
Now, what happens if you force the project to x64 bits? eg this:
Well, if you pick x64 bits? (and not any cpu, and not x86).
Then hitting f5 (or ctrl-F5), it WILL run the application as a x64 bits in-process. I am not sure quite how VS works, but they have some kind of "bridge" that marshals the x64 bit debugger to talk to VS x32 bits.
So, if you force the project to x64, then it will always run as x64 bit - including from VS.
So, this means:
if you set project to x64 bits - use a connection builder in settings?
You can use the connection builder but since (we assume) that you using
access x64 bits? Then the test connection button in VS will NEVER work.
But, if you run the code as x64, and have access x64, then it will work. So ONLY the test connection button fails - and that's due to VS being x32.
If you have even the wrong version of Access (say x32 bits), and your project is set to x64? Then the connection builders will work and EVEN the test connection will work (because test connection is ALWAYS x32 bits from VS). This has the effect of you building a connection, hitting test connection - it says good!!! But when you run the project (f5, ctrl-f5), the project runs as x64, and it will fail (this example assumes x32 bits).
Now this is building an writing code from VS. I don't' know of a SSIS package built with Visual Studio works different. But we do NOT want to confuse Visual Studio (VS) with that of say sql studio or other systems - they don't have the project "cpu" or "bit" setting options like you do for a VS project.
So, I quite much suggest if your intention is x32 bit operations, then ALWAYS force the VS project to x32 bits, and thus come time to launch that .exe from windows, then it will never run with a wrong or un-expected bit size.
I not tested a SISIS integration project, but if building this from VS? Then once again, force/set the project bit size.
In effect to remove the "chance" of the wrong bit size? Then force the project to the given bit size you as the developer were intending to use here - that way this is not left to chance.
There ARE times when you want to use ANY cpu. A really good example is when you build say class library code to share amoung projects. In that case, ANY cpu is a good choice, since then EVEN projects forced to x32 or x64 can referances those external assemblies and library code.
However, if you force those external assemblies to a given bit size, then only projects running that that correct bit size can consume such libraries.
.net code (managed) is differnt then un-managed code. .net code has the ability to run "either" x32 or x64 if you choose ANY cpu. But un-managed code (external non .net code such as Access) can't change on the fly like .net code can. And I use the term "on the fly lose here". Since ONCE a .net program starts running x32 or x64? It remains that bit size until terminated.
So, ANY CPU is fine for external class library code you write and thus want to include in any project. But the main project .exe program has to use SOME external non .net (non managed) code? Then you would do very well to force the project bit size settings.
And to answer you last question?
If the provider is a .net one, such as sql provider or whatever? Then it is managed code - cpu settings don't matter. it is ONLY when you start using external code systems that are NOT managed and NOT .net code. MS-Access is one such common example. So would be any windows c++ or even a lot of commerial programs.
For example. Sage/Simply accoutning, and Quickbooks accounting? They offer .net SDK's to interface to those accoutning packages. But they only have x32 bit verisons of those desktop programs - and they are not .net prorgrams. So once agian, you do well to force the project to x32 bits.
So, no x64 bit process can consume a x32 bit process. nor can you consume external librares that don't match.
However, if that library code and system is .net (managed code), and was compiled and created with any CPU, then you don't have any restrictions in regards to using ANY cpu, or even consuming those libraires when you force the .net project cpu settings.
So this whole system ONLY breaks down when you introduce or start using external code libraires.
For example, if you use .net ghostscript library? They have two versions - x32 and x64. And thus just like MS-Access you have to match up the bit size of those external libraries.
This actually is a REALLY nasty problem say for Adobe PDF. Their pdf viewers are x32 only. In fact it was only what - last month they started offering x64 bit versions of their PDF adobe reader. And they no doubt started doing this since office is now moving towards being x64 bits and not a x32 bit system/program.
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 an application that I compile as x86 code but as a separate version, as x64 code as well. The application basically has two parts, a c# managed exe and a c++ unmanaged dll. I have problems with the latter. On my development PC (Windows 7 64-bit, Visual Studio 2008) I create a setup with a deployment project and this setup installs the application in Program Files... as it should and the application runs. I also have a test PC (Windows 7 64-bit with practically nothing else). There the application still installs into Program Files... but it does not run, I get the BadImageFormatException when a function (any function) of the unmanaged dll is called. The problem is that my own project that produces the dll also makes use of quite a few freely available libraries (e.g. glew32, openal, freeimage, etc.) I took as much care is possible to make sure that I use the x64 versions of these libraries, but something still must be wrong. For some reason one of the libraries used by my dll is not available as x64 code on the test PC but it is on the development PC. At least that is the only explanation I have at the moment why my setup works on the development PC but not on the test PC.
My question is: how can I find out where the problem is. The error message I receive does not tell any helpful detail. I tried to analyze my dll with depends but it looks OK. It lists a lot of dependent libraries as X86 (these are probably system files) but all those that I use on purpose are listed as x64.
Is there any way to test why the Windows on my test PC tries to run the DLL as x86 code even though it should be x64?
Thanks.
I noticed something very strange: My application is being deployed in the Program Files folder as it should be for a x64 application but it fails to run. However if I copy all the files in the folder it is installed to to another folder (inside the Documents folder) the application runs perfectly.
Run Fusion Log Viewer in the machine where you want to diagnose the issue. Look carefully at the logs and you'll see exactly which dlls are being loaded, and where from.
You have build your .NET executable (or DLL) with Any CPU configuration, and you have given x64/Win32 native DLL for Win32/x64 (i.e. wrong config).
On x64 systems, your .NET binary will try to load the native DLL as if native DLL is x64.
And on 32-bit systems, it will try to load 32-bit native DLL.
I found the answer. The problem was not the 64-bit dll at all. One of the libraries I did not make but I link to (I do not know which yet, there) seems to try to write a file to the application folder. Of course, this is not allowed inside the Program Files folder unless you run the application as an administrator. Sorry for asking help for the wrong question.
I have an installer (Visual Studio setup project) which uses DIFxApp and an Orca transform to install drivers. The problem is that there are two DIFxApp merge modules - one for x86 and one for x64. If I reference both of them, the installation only works on 64-bit machines, whereas referencing only the x86 version allows me to install on 32-bit machines.
It seems as though the only solution is to create two MSIs (one for x86 and one for x64), each referencing the correct merge module. My question is how should I create an installer that chooses which MSI to install based off of the target machine's processor?
I've worked with NSIS a little bit, so it might be easiest to go that route.
Other possibilities are Inno-Setup and dotNetInstaller.
Similar questions (but with inadequate answers):
launching correct installer for 32 and 64-bit apps
If you decide to go with NSIS:
!include "x64.nsh"
${If} ${RunningX64}
MessageBox MB_OK "running on x64"
${Else}
MessageBox MB_OK "running on x86"
${EndIf}
You can use a custom action to detect the OS, then call the right installer.
I've given an example here: single-msi-to-install-correct-32-or-64-bit-c-application
How about making a small program (launcher) that detect the os type (64 0r 32 bit, should be easy). The little program then launch the correct installer depending on detection result. The program shouldn't has any window and has the same icon as the installer. Just give the customer all three files, installer.exe (the program), inst32.msi and inst64.msi. If that's too much for your customer then just compress them to a self extracting zip that launch the installer.exe automatically.
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).