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.
Related
I'm developing an application written in Visual Basic 6.0 that supports exporting listViews to Microsoft Excel documents. Everything works perfectly fine if a user has an older version of Microsoft Office installed.
Now I want to add support for users who only have Microsoft/Office 365 on their systems. I've googled my way into depression in the past couple of days because I don't know much (or anything really) about dll/ocx files or registries. I'm not even sure if something like this can even be done because VB6 is really old, as noted here.
I've tried using this approach, but it didn't help me.
Right now, I'm getting a 429 runtime error
ActiveX Component can't create object
on line
Set objExcel = CreateObject("Excel.Application")
I only have Microsoft 365 trial version (no older ones) installed on the system and have these two things checked in my references:
I've also tried searching for Excel.Application in the registry, as suggested here, but I can't find the path to the corresponding ActiveX file (which probably means it is not registered if I understand this correctly).
What can I do? Any help would be greatly appreciated.
Never mind, I found the answer myself. The problem was that I had older Office versions installed when I installed new 365 package and for some odd reason the .dll files for 365 version weren't registered. When I deleted those older versions all the working .dll files were gone with them.
I did a repair of the 365 installation and it's working perfectly now.
I'm developing an office-js addin for corporate client which insists on using legacy versions of Excel (1708 or 1808).
But when I install excel from office 365, I get version 1906.
In the old days, with software, there were installers you could find in a directory that had version stamps on them, and you could create a VM, and just install the version you wanted. But the fancier installers appear to download stuff automatically and always (at least default to) the latest versions.
How do I install a legacy version of Excel on a VM for testing?
There's no special process for getting an earlier version when you are testing add-ins. It should be the same process as an end user would use. Please try the steps at this article: Revert to an earlier version of Office. I think you can find the build numbers that you will need either from your customer or from this page: Update history of Office 365.
We have written a .NET add-in for MS Excel 2010. it is working fine, and we are using the MS deployment package to create an MSI which installs the add-in just fine.
Problem is that sometimes we need to install two versions of the add-in. Perhaps one is todays version, and one is the next version being tested.
What all would I need to update and where to allow the installation of the add-in mroe than once, on the same machine?
To begin with, tried changing the GUIDAttribute, of both the versions of the Add-in project:
<GuidAttribute("75AC751D-AB16-4E37-8940-XXXXXXXXX"), ProgIdAttribute("MyAddin.connect")>
With that change, i think i would need to change the productcode,packagecode and upgradecode in the setup.
Is my understanding correct that if I need to install add-on of my two environments (UAT, Prod) on the same machine, then my productcode, packagecode and upgradecode need to be all unique.
In case later, the user get a new version of the prod add-in, then that add-in should have the same upgradecode, and packagecode, but different productcode only (specific
Can i keep the same ProgIDAttribute for both UAT and Prod in this scenario?
Correct, you should change all 5 of them (and this is enough).
The ProgIDAttribute and GuidAttribute are used to register the addin for the Excel (as name of a key in registery; therefore they both must be changed)
The PackageCode, UpgradeCode, and ProductCode will allow you to install two packages on the same computer. You cannot keep package code (because ALL packages at all should have different package codes). You can't keep product code, because if you do then the second package will reject to install saying you have another version of the same product installed.
So, in the addin project:
ProgID
Guid (i.e. ClassID)
In the installer project
ProductCode
PackageCode
UpgradeCode
If user gets a new build, to allow upgrade, you should change ProductVersion, ProductCode, and PackageCode, but keep UpgradeCode in the installer project (old installation is identified by the UpgradeCode).
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.
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?