I'm using Wix v3.0 (which boils down to an MSI installer) and I'm trying to author a condition to ensure that Excel 2003 is installed. What is the best (most robust) way to detect the presence of Excel 2003 on a machine?
I've seen lots of different suggestions, but no definitive or authoritative answer.
I found a file in the Office 2003 toolkit, Office 2003 Keypath and Default Installation Settings workbooks that contains all the GUIDs for the Components of Office. Based on this, I used a Component Search to locate the Core Excel component. In WiX my condition looks like this:
<Property Id="EXCEL2003INSTALLED">
<!-- This is the Component Id of Global_Excel_Core -->
<ComponentSearch Id="DetectExcel2003" Guid="{A2B280D4-20FB-4720-99F7-40C09FBCE10A}" Type="file"/>
</Property>
<Condition Message="This application requires Excel 2003 to be installed."><![CDATA[Installed OR EXCEL2003INSTALLED]]></Condition>
This page has Component Guids for other Office Apps and other versions.
We check the InstallRoot registry key at:
HKLM\Software\Microsoft\Office\12.0\Excel\InstallRoot
(Replace 12.0 with the relevant version number for your application).
Note that on 64-bit operating systems, this will be reflected to the 32-bit section of the registry (see this Microsoft article for more information on Registry Reflection).
This seems to work well for versions 2000, XP, 2003, 2007 and 2010 at least. The only change for 2010, is that the 64-bit version needs you to look in the 64-bit section of the registry.
you could try checking the registry, or perhaps the typical install path for excel.
Excel (Office) is also installed by windows installer.
Why are you not checking for the excel component codes?
Related
My client recently migrated from 32-bit Excel 2016 to 64-bit Excel under Office 365 and retained 32-bit MS Project Standard 2010.
I have VBA code native to MS Project Standard 2010 which manipulates the Excel 2016 Application by early binding via the Excel 16.0 Object Library reference. Following migration of Excel to the Office365 64-bit version the library reference to it (in MS Project Standard 2010) is no longer available. It is not MISSING it is just not available in the list. It won't even load by GUID. I don't have admin rights and can't inspect or edit the registry. My IT support explained that the issue is probably because we are mixing 32-bit and 64-bit applications.
I have worked round the issue by converting code from Early-binding to Late-binding. I probably didn't catch everything (I have created a very lot of code in a very lot of application tools) and my concern is that some feature of my code that has not been converted correctly may not be discovered for some time.
My question is, should the Project 2010 application (Project 14.0) be able to make reference to the 64-bit Excel 16 under Office365 Object Library? If so, what should my IT support guy be looking at to fix the problem please?
If the answer really is no I will just have to stick with the late-binding and do some extensive testing.
You cannot cross-reference between 64-bit libraries and 32-bit libraries in the same host. The host can only use libraries of the same bitness. Late-binding won't help you in this situation - it helps you where there are version mismatching but not when bitness don't match.
If you need to continue automation between Project and Excel, then you may need to have a 32-bit Excel installation, or consider installing 64-bit Project. There's the third option of shelling out to VBScript or Powershell and running it out of process but that can be a lot of work.
I just updated my MS Office 2016 to version 16.0.8067.2115 (which is the latest version if I'm correct).
I read here that the latest version supposedly has support for using SVG files.
However, I am unable to insert any svg file into any office program (using Insert > Picture from the ribbon or by dragging a file into an office program).
Am I doing something wrong? Does this version of Office not actually support SVG files? Or is there some setting that I missed?
I found the answer to my own question here: https://www.msoutlook.info/question/office-update-channels
Apparently, new updates like the ability to use SVG files are solely available for Office 365 subscribers and not for people who bought a one-time licence for Office 2016 (as I did).
I have a MSI installer that installs an Excel plugin. I'd like to know if Excel is installed and not install the plugin if its missing. MsiEnumProducts gives a list of installed products except Microsoft Office. WTF? Is there a better way to do this?
I'd like my MSI installer UI to display or not a checkbox to install Excel component if we have Excel.
Puzzled,
Gerry
Excel is a feature within one of many Office products. Just because Office is installed doesn't mean that Excel is installed. It also doesn't mean the version of Excel that you need is installed.
I would instead check certain registry key/values based on your exact needs.
Microsoft's vexing dumping of vdproj install projects in VS 2012 leads one to try Installshield LE which is sort of built into VS2012. Sadly, it creates installers that do not work in any way shape or form with 64 bit.
So for instance clicking the Office 2010 installed checkbox only makes a prerequisite for 32 bit Office. It fails to detect 64 bit.
After a lot of chickenless head exploration of Installshield the bottom line is:
1) You need the Professional or Premiere version in order to deal with 64 bit.
2) You need to edit their provided condition to make a compound one that ORs all the guids of Office that you are interested in together as it only checks for one of the many out of the box. This details the structure of the GUIDS: http://support.microsoft.com/kb/2186281?wa=wsignin1.0. I found it helpful to install various versions in a VM and then using regedit to see what the GUID ends up being.
This post is so that someone can actually discover this with a Google search, instead of it being hidden behind a paywall / private support site.
Update October '13 AlBear
There is a beta version of installshield LE for VS2012/13
To build x64 installation packages check on the help files
Look for "64 Bit" .
The way InstallShiel LE recognizes x64 target is by either defining the [INSTALLDIR] property as one of the 64 bit Folder or by defining at least one of the setup components as 64 Bit.
This works as I built an Excel 2013 Add that loads at startup and works fine.
For the Prerequisite for VSTO to work: You need to change file size and hash a it looks like the recommendations from Microsoft article "Deploying Office solutions vsto 2013" are outdated and the XML code recommended has the wrong file size and hash. Not too difficult to fix. However I think that Microsoft is unfortunately going through a period of crisis and this failure to provide reasonable support is uncharted territory .......
Cheers
InstallShield and WiX is like Visual Studio using VB.NET and SharpDevelop using C#. Just as those tools both create EXE's and DLL's using IL code but different language providers,
InstallShield and WiX both create Windows Installer databases using different languages. Just as a VB EXE can consume a C# DLL, an InstallShield MSI can consume a WiX Merge Modules. This gives you the best of both worlds.
The thing to understand is a VSTO AddIn installer isn't a 64bit MSI, it's a 32bit MSI that deploys an AnyCPU DLL with registry entries for either 32bit or 64bit Office. It's the bitness of Office, ultimately, that determines the bitness of your AddIn.
I have a template that I've used for a dozen customers. It uses InstallShield Limited Edition and it's Preq Bootstrapper to lay down all the dependencies and consumes a merge module authored is WiX and IsWiX (CodePlex). Otherwise ISLE is just a container for the UI and it's one feature.
The merge module takes care of all the dependency detection, gating logic, laying down files, installing certificates, setting registry values and so on.
Some more details can be found at:
VSTO 4 ( 2010 ) Lessons Learned
Office 2010 Bitness Pain
Apparently the small print referenced here should have been one clue: Does InstallShield Limited Edition Support 64 bit Installer?
The current Office prerequisite in Installshield is also misleadingly worded. It should really be "Office 2010 Home & Professional 32 bit".
Perhaps they intend to upgrade it over time to be comprehensive or perhaps everyone has to go through the same hassle to fix it for a few cases they care about. The support guy claimed there are too many GUIDS for all the combinations of versions, bitness, releases etc.
Home & Student, Home & Professional, Professional, Office 2010 Professional Plus License
32bit, 64bit, Languages mangled in there, Service Packs, etc. Depending on the set you care about the number of GUIDS is rather large.
It seems if you try to reference the Office COM objects (as you would do in other development environments), Visual Studio gets it wrong - and it just won't work.
So you must use the converted type library that Microsoft hand-converted and makes available for download, and download, and download.
Now it seems that in order for my application to run it needs the Office Interop code, which is contained in an assembly.
Now i don't want to force my customers to install the Office 2007 Primary Interop Assemblies, Office 2003 Primary Interop Assemblies or the Office XP Primary Interop Assemblies. i want an xcopy deployment.
If i manage to get a hold of Microsoft's copy of the interop assemblies, can i just copy them to by Bin/Debug and Bin/Release folders?
If i include the Office 2007 interop assemblies, will it work if the customer has Office 95 installed, or do i have to include all versions of the Office Interop dll's Microsoft has ever published?
This is a common question with a rather complicated answer. Mary Lee of MSFT is a great resource for information about this:
http://blogs.msdn.com/vsto/archive/tags/Deployment/default.aspx
Using ClickOnce to deploy is the closest you are going to get to an XCopy install of any application built on VSTO.
Also, check this post:
http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/1666d2b0-a4d0-41e8-ad86-5eab3542de1e/
Finally, Misha has a great blog:
http://blogs.msdn.com/mshneer/archive/2006/01/05/deployment-articles.aspx
The PIAs are specific to the version of Office you are targeting, so the 2003 PIAs are necessary for targeting 2003 and the 2007 PIAs are necessary for 2007. Automating Office 95 via managed code is something I have not done before, but I can imagine you are directly referencing the type libraries so a RCW is generated for you and has nothing to do with PIAs.
HTH
Colby Africa (MSFT)
From my own experience:
If you wanted to target Office 2003 and above, then you'd use the Office 2003 PIAs - and limit yourself to the Office 2003 API. The code would run on Office 2003 or later. You could still call Office 2007 functions using reflection, but that's not pleasant.
I imagine it's much the same story if your baseline version is Office 2000 - though I've not tried it, and I believe the earliest version for which Microsoft themselves provide PIAs is Office 2002 (XP).
You can create your own Interop assemblies for 2000, and I've no reason to believe that you can't do it for '95, though you're the first person I've ever seen ask for '95 support! It goes without saying that if you create your own Interop assemblies you'll need to deploy them with your application.
In any case, you want to use the highest Office version you can get away with as your baseline, so that you can support as many features as you can without resorting to reflection. You should develop your code on a machine which has only that version of Office installed.
In my case, I develop for Office 2003 and know that my users also have 2003. So, I ask them to ensure that they have the ".NET Programmability Support" feature enabled (which you can do via Office 2003 Setup via Add/Remove Programs if you choose the Change option). That option basically installs the PIAs to the GAC. For those users that can't do this, my setup program detects the lack of the PIAs and installs them prior to installing my application (as it does for the .NET framework).
XCOPY deployment? Yes, I'd like that too - but forget it. For one thing, if your add-in is going to work in 'high' security mode, then you're going to need a code-signed COM 'shim' to sit between your code and Office, and that needs to be registered. I believe VSTO provides its own shim, if you choose to go down that path (I didn't, since I needed to be able to 'drive' Office from scratch rather than relying on the user to start the application).
Deployment - and dealing with the installation & security issues - is one of the hardest parts of Office Add-in development with .NET, and it's a real kicker that it comes right at the end when you thought you were done.
My strong advice is to save yourself days and weeks of hassle, and look at Add-in Express. I've only recently come across this myself, and have been kicking myself ever since because it could have saved me so much time. It has several benefits that I think would be useful to you:
It allows you to create a single add-in targetting Office 2000 to Office 2007 (sorry, not '95), regardless of what version you happen to have on your development PC.
It creates an installer for you (which even works on Vista!), which in itself is worth the price.
It comes with its own COM shim, and is integrated to the extent that you don't need to worry about it.
It will allow you to have a single add-in that has a menu/toolbar interface in Office versions up to 2003, but a ribbon interface in 2007.
Note that I have no affiliation with Add-in Express (other than as a recent customer), but equally I've not yet converted my projects over to using it. The initial tests that I have done lead me to believe it's pretty good - and definitely the way to go for small to medium projects.
If i manage to get a hold of Microsoft's copy of the interop assemblies, can i just copy them to by Bin/Debug and Bin/Release folders?
It worked for me. When I compiled the program I had it reference the interop (PIA) dlls in the bin and then deployed it that way to the customer.
If i include the Office 2007 interop assemblies, will it work if the customer has Office 95 installed?
No, you mst have the interop dlls for the version of Word you are targeting. I suppose it might be possible to write your code so that it chcks the version of word running on that machine and at runtime chooses the correct interop, but you need to include them all.