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.
Related
I am developing an Outlook plugin solution that involves the plugin itself and a windows application working in tandem.
The plugin targets multiple versions of Outlook - 2007, 2010 and 2013.
The windows app uses different libraries for x86 and 64 bit processors.
Of course there are dependencies of both the plugin and the app.
In addition to pure installation, I would like to make automatic updates possible. It could be something as simple as custom code in the windows app to check for updates in a predefined location. But I would like to know my options.
The solution I have in mind right now, and which I would like to ask the SO community to evaluate is as follows:
Separate Windows Setup Projects (producing MSI files) for each combination of application and configuration (This could be as many as 8 different msi files)
One common bootstrapper project, detecting current system configuration and installing prerequisites and selected msis.
MSIs would not have prerequisites embedded in them, only the uber-installer/bootstrapper would have those.
Am I missing something? Is this solution viable? Are there third party alternatives to Windows Setup Projects that would make my life easier? Full featured Install Shield maybe?
In case this actually is helpful for someone, the solution I went with is the incredibly customizable installer solution: InstallMate 7 by Tarma.
You can find out more from their website, but the features that got me are:
Built in support for x86 and x64
Customizable prerequisites
Stand-alone update tool also provided by Tarma, which simplifies
automatic updates a lot.
PRICE! Forget about spending 5K on similar features elsewhere.
While working on an auditing project I came across different problems regarding software and licenses. My project runs on Linux with Perl and I successfully retried remote machine software via both SNMP and WMI. The big issue is that the two protocols return quite different results. For instance one may find a program and the other may not, and vice versa.
I know that SNMP retrieves software wich have a related uninstall key on (correct me if I am wrong):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
But what about Win32_Product? This is what the documentation says about:
The Win32_Product WMI class represents products as they are installed
by Windows Installer. A product generally correlates to one
installation package.
What does that mean? And, last but not least, is there a way to improve how installed software are retrieved? I mean if I lookt at my installed software from the control panel and confront results with SNMP and WMI there are a lot of wierd things.
EDIT: Just a quick update, I developed a couple of programs in .NET C# that I installed on many computers. Too bad neither WMI and SNMP find them out. I installed these programs with the usual Visual Studio generated setup. Any hints?
People basically use WMI to query various system parameters. WMI exposes a lot of interfaces which one can leverage. It is mostly used with VBScript but one can also use C++/COM or C# to interact with it. This Wikipedia article can give you a detailed explanation about WMI and then you may understand what Win32_Product Class does. This is another great article and a must-read for someone beginning to work with WMI.
Also go through these articles without fail:
Retrieving a CLASS
Retrieving an Instance
Retrieving part of an Instance
Accessing a Qualifier
These articles will give you a good understanding of WMI concepts.
As far as Windows installer is concerned:
Windows installer is based on Server-Client architecture. The Windows Installer is actually a Windows Service. The various features that Windows installer supports has made it the most standard method of application life-cycle management. The Basic MSI(there is nothing Basic about it) package with the .msi extension is used to package and distribute apps.
The Basic MSI package is basically a DATABASE. The application binaries and other stuff may be packaged as CAB files and included in the MSI package or may exist outside of it.
This is known as TRANSACTIONAL install method. The Application Packaging developer just has to fill in the various tables in the database and the Windows Installer engine takes care of everything else. This may seem or sound easy but is very difficult and needs a lot of knowledge.
When the application is installed on to any sytem, Windows Installer writes all the Registry keys needed for proper management of all resources installed on to the system. As the life-cycle of an application is managed by Windows Installer, it can easily support:
1) Repair
2) Resilience
Once you go through all this, you may have a better idea of all the parties involved in your case. Then you will have clearer questions(or may not!), and we can help you better(or you may not need it at all!).
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.
Hello I have been fighting some complexities with understanding deployment of Primary Interop Assemblies (PIA) for MS Office. I have Visual Studio Com Add-IN built in VS 2008 on pure com technology (not VSTO see bottom of this for more on that), which references 2003 Primary Interop Assemblies but the add-in may be used on 2003, 2007 or now 2010 Office machines. Because I never know if the customer will be using 2003, 2007, or 2010, I cannot simply deploy one PIA version as a prerequisite (unless I make 3 installers which I do not want to do). Now, my understanding is that when you follow the steps here to add 2003 and 2007 PIA to the prerequisite lists that show up in a Visual Studio (2008) setup package, the prerequisites are smart enough to determine which office version is running on the client you are targeting. So if you were to select 2003 primary interop assemblies and 2007 primary iterop assemblies as both being prerequisites then when this installs on a machine that has 2003 it should be intelligent enough to only try to add the 2003 PIA if those are missing on this machine and if this is a 2007 Office machine then it will only install 2007 PIA (and not try to install 2003 PIA).
Question 1 is this a correct understanding (that the prerequisite packages are this intelligent to only install what it needs based on the version of Office?)
Question 2 is there a way to get the 2010 PIA to show in the list of prerequisites in VS 2008 like 2003 and 2007 do? I do not want to upgrade this project to VS 2010 b/c it is considered a legacy app now with many customers from all around the world using it.
Question 3 Even though the actual assembly references 2003 primary interops, I do not presently deploy those interops with the add-in to the install location. Instead, I am assuming that if I can get the correct PIA installed then I don't need this present in the installation path, since the PIA would be in the GAC. However, one possible approach may be to just include the 2003 assemblies that are referenced (in my case excel and word) in the install path and not worry about the PIA. I suspect this would work on 2003 machines but perhaps not on 2007 and 2010 machines b/c on the latter, even if the 2003 interops that are referenced are found at run time in the install path of the assembly, I think if there is not a Policy.11.0.Microsoft.Office.Interop.Excel/Word(etc) in the GAC, then 2007 and 2010 will likely not know what to do with the 11.0 (2003) interops (as I think the Policy.11.0.Microsoft.Office.Interop files redirect requests for the 2003 interops to 2007 or 2010). Any thoughts on this?
Question 4: There is a well known bug with Framework 2.0 apps Office Add-Ins and Office 2003 where the add-in won't load. This was addressed by KB907417 aka KB908002. Dopes anyone know if this KB necessary if you develop on the 3.0 or 3.5 framework (and make 3.0 or 3.5 a prerequisite) since this problem was specific to framework 2.0? Or does the KB still need to be deployed b/c it's office 2003 that is the problem and not the version of the framework?
As you can tell by my 3 questions what I am trying to ascertain is whether we can build one single installer via the VS setup utility. If the PIAs can be done with one installer but the KB above is the obstacle (as perhaps the answer will come back that even on the 3.0 or 3.5 framework 2003 customers will need the KB) then maybe the path to one installer is to just make the KB a prerequisite across the board and install it on 2007 or 2010 machines, though they technically do not need them. Any thoughts on that option would be appreciated as well. Finally, I am aware that writing a manged Com Add-IN for excel or word is now generally done with VSTO instead of pure managed framework code, but this is not an option presently to change the legacy app to this direction. Also it is reported that the 4.0 framework now can be used to deploy add-ins without making any PIA a prerequisite but again, this is not a viable option right now.
Does the code use any Office 2007+ methods or classes? If not, are you sure you cannot use the 2003 PIAs in all cases? The later apps should be backward-compatible (supporting the same API) so the only reason you'd need an updated PIA is if you needed to access some feature added by 2007 or later, I think.
You may want to take a look at Add-in Express, which promises a one-for-all-versions installer, and is pretty easy to use.
As you can tell by my 3 questions what I am trying to ascertain is whether we can build one single installer via the VS setup utility
You cannot. You must create custom installer packager (setup bootstrapper).
Many years ago I used dotNetInstaller with HTML GUI builder, today WiX toolset would be better solution, I think.
Check how PIA .msi installers are constructed with Orca or .msi and .exe installers flow checking windows installer logs.
Based on registry checks, file checks, installed product checks, windows versions, office versions you can create conditions whether component should be installed or not.
Oh and I advise making plugin installers without prerequisites and installing them conditionally with your custom installer bootstrapper.
I have a product which has been traditionally shipped as an MSI file. It is deployed through some sort of SMS push to thousands of desktops by our various clients. The software we use to create these installers is getting long in the tooth and we are looking to replace it. We have already standardized on InstallAnywhere for most of our products as we support many operating systems. Unfortunately InstallAnywhere cannot produce MSI files.
I am wondering if it is required that SMS use MSI files or if it can handle other installer types (.exe). If not, are there any open source programmes for creating MSI files?
If your clients are using SMS then you're in the clear... SMS supports EXE. You enter a command line when creating 'Programs' and clients are probably already calling msiexec to launch the MSI. Also I'm pretty sure SMS predates the MSI file format :)
However if they're using Active Directory / Group Policy Objects.. then you're SOL as that does depend on MSI format for deployment.
If you do want to stick with InstallAnywhere, there are a number of "MSI repackaging" tools available. Assuming you're looking at a basic application (device drivers might be an issue) then repackaging should be a fairly painless process.
If you want to create MSI files, try WiX: Windows Installer XML (WiX) toolset.
It's an addon to Visual Studio 2005 and 2008, is open-source, and Microsoft developed. You can use XML to specify and create MSI files. There is a wealth of resources available on it, and WiX 3.0 is, although in beta, is very complete.
Also, note that you don't have to start from scratch, you can decompile an existing MSI using the WiX Dark utility, modify the XML in any way you like, and then recompile it into an MSI.
Actually, with group policies, there's the ZAP file alternative, but I would recommend regardless that you learn MSI. It's not that hard, and very flexible.