We use Wix Windows Installer XML with bootstrapper, our target system is Windows 10.
On a Windows 10 running on an ARM system as virtualization, our software installs without problems, but crashes on certain actions because C++ runtime files for ARM architecture are missing.
Is it possible to create a condition in this setup for these runtime files to install only on ARM architecture without affecting other systems?
Do these files belong better in the MSI or in the bundle?
Many corporations roll out software using some kind of software change management tool like Microsoft SCCM. My experience is that they usually do not like all in one exe installers and rather want to control the installation of each component (msi).
So I would create a msi package for each architecture. You can then run the specific msi from the bundle with a condition on the "ProcessorArchitecture" property https://wixtoolset.org/documentation/manual/v3/bundle/bundle_built_in_variables.html.
Related
I have built a program using Visual studio 2013 in visual basic. I am using a set of DLLs to communicate to some external hardware. The computer I developed the software on is a Win7 64bit machine and I can compile and run the software with no hiccups on it. I also have another computer (Surface Pro 3 64bit) that I use to test my software on and that works as well. Basically I just locate the debug directory of the development computer and copy the EXE and support DLLs to the new computer and run the EXE. This all works with my surface pro 3 computer.
My company purchased some other surface pro 3 computers for our production department and I am trying to get the software running on those as well. I do the same thing. Grab the EXE and support DLLs from the debug directory of the development computer. Except on these computers when I run the software program it tells me it can't find the DLL for the program. The DLL is sitting right in the application's folder, yet it says it can't find it.
I have tried multiple things, like publishing the software and including the DLLs in the installation, then running the installation on the "problem" computers. This still doesn't work. Same issue, it can't find the DLL.
This could be a number of things:
Incorrect version of .NET - do the new computers have the target version of .NET installed on them?
A required DLL is not being found, you should enable assembly bind failure logging and try again - How to enable assembly bind failure logging (Fusion) in .NET
So it turns out that the DLL I was referencing requires the VC++ redistributable packages to be installed on the computer. I downloaded and installed these on all of the problem computers and now the software recognizes the DLL and run.
I need to detect what type of installer software is being used for a particular software. How do I do that?
I don't think there's a common way to do it which fits each vendor. I can only talk about Windows Installer based vendors, like InstallShield and WiX. If you use extra functionality provided by a certain vendor (built on top of usual Windows Installer stuff), this can be various custom MSI tables or just specific MSI properties. The Orca tool and verbose installation log file are helpful tools.
I have a Windows .net solution that is deployed with a Visual Studio Deployment project.
My exe is a win32 app that runs fine on either a x86 or x64 windows.
However I included a merge module (*.msm) from a third party vendor which is available in a x86 and x64 version.
Now I could copy my whole deploy project and just change the msm, but I'm a lazy guy and the best thing would be to include both msm's in my installer and only install the module which fits the processor of the client machine.
Is there a way to do this with Visual Deployment projects?
Merge Modules seem to lack a Condition property like included exe / dll files have.
My problem is that a vendor is providing me with a 64bit application (packed in a 64bit installer) but it goes and installs to the x86 (Program Files) Folder and he keeps telling me its OK but I want it to install in the Program Files directory; as the 32 bit version does that and scripts for the app are developed based on this assumption.
Can someone direct me to the Microsoft recommended best practices for 64bit applications(links).
Thanks in advance.
This may help:
About Windows Installer on 64-Bit Operating Systems
http://msdn.microsoft.com/en-us/library/aa367451.aspx
Is your vendor installing the app via an MSI file? If so, their app setup generator (WIX, InstallShield, etc) should be creating MSI's that store their components in the correct places.
If not and they're installing using a custom script, suggest they start investing in learning WIX ;)
Either way, they should be following the recommended guidelines and installing 64-bit code and 32-bit code to the correct locations and modifying the correct registry trees accordingly.
Is it possible to create MSI package, which will run without Windows installer installed in system, but first will install Windows installer itself, and then continue installing other components?
The goal is to create prerequisite package for our software, which must install some components, including some operation system service packs. We also prefer using MSI package. But it's obviously to us that our software will be installed on clean operation system. Though there will not be needed Windows installer present. Is it possible to create such prerequisite package using MSI?
No, there is no way to install an .MSI package without Windows Installer already being present in the OS.
However, Windows Installer has been a native part of Windows since Windows 2000. Are you really developing installers for Windows 95/98/NT4? That would be the only case where there is no Windows Installer support and you'd need to install a redistributable MSI package first.
Unless you meant to say that you require a higher version of Windows Installer than is native to one of the older OSes? (e.g. MSI 3.1 for WinXP) In that case, you'll need to bundle the .MSI redistributable for the MSI package you desire and run that first. Sometimes a reboot is required, other times not. YMMV.
One way, you can write an application in cpp or c or any language that does not require any additional frameworks or SDKs, to check for the installer and install it programatically.
It sounds like you need a bootstrapped with two or more msi files in it. Take look at the WiX documentation. WiX has build-in bootstrapped
Hope this helps
s