I'm trying to access the TargetPlatform property value (which you can set in a Deployment project) from the condition within a "Launch Condition".
Basically I'm trying to tell the application not to install itself as a 32bit app if a 64bit version of Office is installed on that computer. Therefore I need to somehow get the application's bitness and put it in a launch condition.
I can get the bitness of Office from the registry, but I don't know how to access the TargetPlatform from the installer.
Thanks!
Here are two link:
Deploy1
Deploy2
From the above link you can deduce that you can't target both platforms from a MSI installer. You will need to have two installers. Depending on how the installer is built, x86 or x64, will depend the way the installer interprets some constants that tell where to isntall the files - Program Files, or Program Files (x86).
You can't change the TargetPlatform of the installer at runtime.
What you can do maybe is to have two installers packed into a third one and based on the Office version installed that you say you can obtain run either sub-installer x86 or sub-installer x64, that will actually install the application files.
If MSI installer is not the outmost requirement I would go for NSIS. If not at least package the to MSI installers into an NSIS one. It is incredibly easy. NSIS is way cooler than MSI, talking from experience.
I've read this question a few times now and I'm not 100% certain I understand what you are trying to do. Do you have a 32bit application and you only want to install if they have 32bit Office (2010 I assume) installed? Do you also have a 64bit version that you want to install if 64bit office is installed?
I'm not sure why you need to care about the TargetPlatform property because if you know that 64bit Office is installed you must by definition be a 64bit OS. If 32bit Office is installed you could possibly be a 64bit OS but does it really matter? You said you cared about the bitness of Office not Windows.
I would think, from what I've read, that if you have an AppSearch that pulls the bitness into a property that you could just use a LaunchCondition that uses that property along with "or Installed" ( to handle being able to uninstall your application if Office was uninstalled first ) and be just fine.
Add a custom action before the installation starts to perform the check. Use an Installer class to perform the custom action. You could use the OnBeforeInstall event to read the registry key and check the bitness as appropriate. Throwing an exception will cause the installation to abort, but there may be a cleaner way to do this.
Related
I have created an application in C# that relies on a specific driver (a custom virtual hid driver based on VMulti).
Currently, I have everything working and I want to combine both the application and driver into one installation package. As of right now, my application part has a .exe file and a .dll file. My driver has an .inf and .sys file, hidkmdf.sys, and WdfCoInstaller01009.dll (this dll is from the WDK). I am not able to install the driver through the traditional method of right-clicking the inf and clicking install. Instead, I use devcon to install it (command is "install inffile.inf hardwareid")
I tried using InstallShield LE, but I am only able to install the application, not the driver. After doing some searching, I found people using DIFxAPP to create the installation framework for drivers, however, I am not sure if this can be integrated into InstallShield so that the driver is installed during the application installation process.
So my main question is: What is the best and simplest method for combining application and driver installation into one package (meaning the setup.exe will install both the driver and the application)?
I am very new to driver development and application deployment, so any suggestions are welcome.
Thank You
EDIT: It is preferred that the solution does not require any paid tools.
Acctually, exists a many ways to implement this which depends on your Windows Installers skills.
You didn't specify target OSes for your application, that's why can I give you some ways:
PnpUtil.exe internal Windows 7 utility (only for Windows 7)
DPInst.exe included to WDK
DifXAPI merge module.
You can install drivers with help of all these utils via Custom Actions.
NOTE: That your driver SHOULD BE signed, otherwise you will receive error during silent installation.
I am looking for the safest way to detect what components of Microsoft Office, if any, are installed on a given workstation. I realize this could be seen as a question for Serverfault as well, but since I'll be using this in a script and many people here are more familiar with the inner workings of Office, I thought this would be the best place to ask.
I've looked at the uninstall key, but it shows components that do not actually exist on the system. I believe this has to do with the way Office can install a component on first access. I'm not fond of looking for executables as the path can theoretically change.
I ended up testing for specific registry keys, taking into account the differences between 32 and 64-bit Windows installs. I'm paying attention to the following registry locations/values:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\12.0\—The base Office12 key on a 64-bit Windows install
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\—The base Office12 location on a 32-bit Windows install
Office base path\Outlook\InstallRoot\Path—Key signifying Outlook installation path
Office base path\Registration\{90120000-0012-0000-0000-0000000FF1CE}—Key for Office 12 Standard GUID
Office base path\Registration\{90120000-0011-0000-0000-0000000FF1CE}—Key for Office 12 Professional Plus GUID
With these locations I've been able to:
Detect whether Office is installed.
Detect the version of Office that is installed.
Detect whether Outlook is installed.
I have not attempted to get any more granular than this.
If you really think you cannot rely on paths to exe's or dll's, I would diff the registry (many tools for this exist) of before and after snapshots of installing the various components. In my experience however, I find it necessary to test existence of dll's and other files for detecting installed components for Office (I had to test for VBA dlls to detect presence of visual basic module installed, for example). The paths of files can only change so much. You just need to be cognizant of 32-bit and 64-bit patching, and winxp and win7 pathing.
I am finalizing an application that will soon be submitted for Windows Logo Program validation. One of the requirements is x64 compatibility. Specifically, Crystal Reports 2008 must work under x64.
My problem is that Crystal Reports basic 2008 (the one packaged with Visual Studio 2008) has no merge modules and must be installed using the provided .msi installers. They offer separate installers for x86 and x64.
So how would I detect x86 and x64 during install and then run the appropriate Crystal msi? Is this even possible without merge modules?
EDIT:
This:
IF PROCESSOR_ARCHITECTURE == x86 AND
PROCESSOR_ARCHITEW6432 NOT DEFINED THEN
// OS is 32bit
ELSE
// OS is 64bit
END IF
seems to tell me how to detect it (thanks MicSim). But how do I perform this in an MSI? Is it a custom action? And then how do I trigger different required msi's for the x32 and x64 crystal reports?
And why doesn't the x86 crystal installer work under WOW64? You have to install x64 Crystal to work with your WOW64 x86 app. Frustrating...
EDIT 2:
Okay, so detecting x86/x64 seems to be covered here. Now how about manually triggering an msi of your choosing?
The easiest way I have found to detect a 64-bit operating system is to use the VersionNT64 property. This property can be used in conditions for components or custom actions (eg. the condition Not VersionNT64 will only be true for 32-bit operating systems).
As for installing other MSI packages during your installation, that is a little trickier. Windows Installer will only allow one MSI to be running the Execute Sequence at a time. This means that you must either install your Crystal Reports MSI during the UI Sequence using a custom action (be careful if you do this, the UI Sequence is skipped if the MSI is run in silent mode), or create some kind of bootstrapper program that will run both the Crystal Reports MSI and your own in sequence.
I have never created my own bootstrapper, but InstallShield has a bootstrapper program built into their setup.exe; they call packages installed this way prerequisites.
Just googled it: If you have an MSI project you could check the properties like described here.
For further information about detecting process and OS architecture you might want to read this MSDN blog about "HOWTO: Detect Process Bitness".
You can trigger the Crystal Reports MSI with a custom action that executes [SystemFolder]msiexec. Just specify "/i [YourFolderWithCRMSI]msiname.msi" as the arguments.
According to this forum, Crystal Reports now includes a merge module for visual studio 2008.
HREF=https://smpdl.sap-ag.de/~sapidp/012002523100005986132008E/cr10_net_mm.zip
Edit (from the author): It turns out that this doesn't work for the Crystal Reports that comes bundled with Visual Studio 2008.
I'm sketching an application deployment process for a bunch of relatively complex desktop applications. We have both native and Java apps, so the deployment must be able to check for existence of the JRE and install it if needed. Some of the apps depend on special hardware, so the deployment must also be able to launch the necessary driver installers. Some of the apps are multiplatform, and preferably the same mechanism should be able to create Windows, Linux and Mac OS X installers. That is:
The installer must be able to install, in addition to the application itself:
Java Runtime Environment.
Drivers (hardware) - that is, launch other installers.
The installer builder must be operable from the command line so that it can be integrated with an automatic build mechanism that generates installer packages for each platform as nightly builds.
In addition, I need to create "update from the web" mechanisms for the applications. It could be included in the installer, or it could also be a separate custom mechanism built into the application.
Now, this is getting a bit complex, and I suspect that there might be no single installer that could do this all. Therefore I'm thinking between two fundamentally different approaches:
Platform-specific mechanisms: NSIS would create .exe or .msi for Windows, XXX would create .deb for Ubuntu, and YYY would create .dmg for OS X.
Cross-platform installer that would handle all the requirements above: ZZZ?
Any recommendations? Some options that I've looked include:
NSIS - Excellent, but Windows only.
IzPack - Good, but requires JVM to run.
Is there an universal tool for this, or should I just pick an appropriate tool separately for each platform? In the latter case, what would be "NSIS equivalents" for Ubuntu and Mac OS X?
I have some recommendations as follows.
Use WIX (Windows Installer XML) for creating MSI installers for Windows
Use Package Maker (part of XCode tools) on MAC OS X, preferably the command line version
Write wrapper scripts (in Python or so) to drive the over-all installer creation process.
to aggregate all the components you need to install (may be from ur version control system)
generate necessary files for Wix and Package Maker as much as possible
to run the packaging tool and generate the package
Make sure that the overall installer creation process is a simple one command operation overall (with options to create different versions of your package based on criteria like release branch etc.)
Overall, developing this workflow requires some initial effort and quite a lot of thinking. But the end result is quite worth the effort.
I haven't done this on the Linux side, but I guess would use RPM/DEB on that front in this workflow.
BitRock InstallBuilder meets all the requirements, including being multiplatform and providing an autoupdate mechanism
You should take a look at InstallJammer. It will definitely handle the cross-platform elements that you want and can even add entries to the DEB and RPM databases on the target system during installation. OS X support is still experimental, but it mostly works.
For .net 3.5 SP1, Microsoft have the new client profile which installs only a subset of .net 3.5 SP1 on to Windows XP user's machines.
I'm aware of how to make my assemblies client-profile ready. And I've read the articles on how to implement an installer for ClickOnce or MSI.
But I've been using Inno Setup for my project so far and I'd like to continue to use it (as an Express user, I can't easily make MSIs), I need to know how to use the client-profile installer in a custom environment.
There is an article on a Deployment.xml schema, but no indication of how to write one, package it or anything else. Can someone explain this process? Finding the articles I linked to alone was a painful search experience.
Microsoft has now shipped the Client Profile Configuration Designer (Beta).
This designer lets you edit the XML files with some limitations, this isn't a 'Google beta' by any means.
Information and download
Can you clarify: Are you trying to write an installer for your app, which depends on the Client-Profile, or are you trying to write a custom installer for the client-profile?
I haven't used it personally, but if it's anything like the dotnetfx 1 and 2 msi's, you basically have to just invoke it's executable yourself from your own .exe file, or from an Msi BEFORE the InstallExecuteSequence starts up - you can't "embed" those in your own app, MS go out of their way to tell you not to do that due to suckage of MSI.
Client profile works only on clean XP. If your user as .Net 1 or 2 installed, client profile wont install...
You have an offline version (integrating Full .Net3.5 Install in case Client Wont install) 200 to 300Mo don't remember
Online version will get required files.
You can call a silent install from the first steps of your install.