How to check in WiX (Product.wxs) if Office is installed in version 2010, 2013, 2016, 2019 or later?
2007, 2003 or older should be ignored (as if Office is not installed at all).
I'm aware of this question: C#: How to know whether certain Office 2003 or 2007 application is installed?, but don't know how to check and combine multiple conditions in WiX. I totally can't come up with anything beyond what's in the above question...
Thank you in advance.
I would not do that. There are too many options how office can be installed nowadays. "Office 365" version that is installed with ClickToRun and not MSI as an example (and may use different registry keys), 32 vs 64 bit options, etc. User can even install office after installing your tool, or update office version later.
Instead, you could detect the version in your VSTO tool (use something like Application.Version for this). And simply give some error message if it's not the one your tool supports.
Check out this topic as well for an overview: How to detect installed version of MS-Office?
You can use a registry search like shown in the following snippet:
<Property Id="OFFICEPATH">
<RegistrySearch Id="OfficeReg" Root="HKLM" Key="SOFTWARE\Microsoft\Office\14.0\Common\InstallRoot" Name="Path" Type="raw" />
</Property>
<Condition Message="This application requires Microsoft Office 2010. Please install Office then run this installer again.">
<![CDATA[Installed OR (OFFICEPATH)]]>
</Condition>
Also you may consider using the Windows Installer APIs to find out if the relevant product/package/component codes are present on the machine. These can be done via P/Invoke calls.
Everything depends on which Office editions you need to support. There are Click2Run editions of MS Office that don't add the usual or necessary windows registry keys. In that case you need to have a special case for that, for example, if your add-in is for Outlook, you could check the following path in the windows registry:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\15.0\Common\InstallRoot\Virtual\VirtualOutlook
Read more about that in the Determine whether Outlook is a Click-to-Run application on a computer
Related
I have a few add-ins for Excel and Word 2007-2016. And I don't understand a few things. My project use some dlls, like Microsoft.Office.Tools.Common, Office.dll, some excel, word and common interop's. And these files can be found in a few places at the same time, different versions of them (like program files, windows/assembly, windows/Microsoft.Net/assembly). So I don't know which version to use. And also, if user has VSTO installed, I suppose he has these files. So why do I need to provide them? What do we install exactly when we install VSTO? Which part is for what and which installation place is from which component? I think I don't do it right, because I found out that Excel loads two different versions of the same file at the same time.
Those are a lot of questions, and many of them depend very much on exactly what you provide with your solution...
The case of the PIAs ("Office dlls") is relatively clear cut:
You do NOT need to (and should not) distribute the Office PIAs with a VSTO solution, with the possible exceptions of 2007 and 2010. In these versions, installing .NET support was optional and not default. That's why there are redistributables for these versions, and not for others. Your installer needs to check whether they're present (same as with the VSTO runtime and the version of the .NET Framework) and install only when necessary.
Office always installs the PIAs into the GAC and your solution will find them there. It makes no difference where you referenced them on your developer machine.
The PIAs in the GAC are only available via the COM tab in the Visual Studio dialog box for inserting references. Many .NET developers didn't find them there, so Microsoft delivers a (ONE) single set of PIAs with VSTO and copies them to a Visual Studio folder so that they'll show up in the .NET tab of the dialog box. The only problem with this is that you get only the set of PIAs for the version of Office that was "current" when that version of Visual Studio was released, meaning you may get the impression you can't develop against any other version because you don't find the PIAs in the .NET tab (but they will be in the COM tab).
Rule of thumb: Always, always develop your code using the earliest version of Office you plan to support. There are two reasons for this: 1) You can only use functionality that will be available to all versions of the Office application (Office is generally backwards compatible); 2) Office is designed to migrate references to older sets of PIAs to newer sets, but not the other way around.
There's a good article on deployment pinned at the top of the VSTO forum on MSDN that "sorts" a lot of requirements for various versions of VSTO and Office: https://social.msdn.microsoft.com/Forums/vstudio/en-US/1666d2b0-a4d0-41e8-ad86-5eab3542de1e/deploying-office-solutions-to-end-user-computers?forum=vsto for add-ins targeting 2007-2010. For later versions, see the MSDN documentation: https://msdn.microsoft.com/en-us/library/bb386179.aspx
I have a VSTO-Add-In for Outlook and need the information when i have to provide the VSTO-Runtime with the installation of the Add-In.
I have already found this article describing the prerequisites but I could construct cases which do not fit this description:
The article says "If Office 2010 Service Pack 1 (version 14, build 6029) or any newer Office version is installed, Office will take care of configuring the VSTO runtime."
=> This is telling me I do not need to provide the VSTO-Runtime in this case.
In the case that I have installed Office 2010 and manually install the ServicePack 2 I have the buildversion 7015 in my Outlook which is a greater version than 6029.
My installer recognizes this and does not provide the VSTO-Runtime.
But on starting Outlook after the installation I get an error saying, the .vsto-file could not be read.
This error only disappears after installing the VSTO-Runtime. Then the AddIn works fine.
What are the real cases in which i need to provide the VSTO-Runtime?
if you're using windows installer, just add it as prerequisite, which will create a Setup.exe, and add it as Launch Condition in your installer to show an error message, that Setup.exe should be run, or just make the Setup.exe run always, it will launch your .msi
have a look here - I guess this is also valid for Office 2013 .. just use the right components IDs !
Utility under discussion: Microsoft word 2010 add in using .Net3.5
Target platform Windows Server 2008 R2, Microsoft Office 2010 professional 32 bit
In Visual studio setup project i add registry enftries in HKCU as well as in HKLM. As per my research Addin to be made available to all users registry has to be added in
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\Word\Addins\myaddin.
but when i install my addin on target machine HKCU entries are correcrt so administrator can use the installed addin but for HKLM it becomes
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Wow6432Node\Microsoft\Office\Word\Addins\myaddin
so when users logg in through AD they dont see the add in. every time i have to manually write enties in
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\Outlook\Addins\myaddin
through server administrator account. Why is extra Wow6432Node added after Wow6432Node
please guide what am i missing.
You are not supposed to add "Wow6432Node", it is handled automatically by the system, depending on your setup type (x86/x64). In particular, depending on whether the component in setup is x86 or x64.
Visual studio generates x86 setup, this this node should be added automatically.
Try simply removing this "Wow6432Node" part.
I am migrating a VS 2010 Project Add-in to VS 2013. In the process, because they got rid of the built-in installer in 2013, I am changing my installation package to Wix. I have already done this for my Outlook add-in. In the Outlook add-in installation Bundle I used this block of code to check for Outlook prerequisites:
<util:ComponentSearch Id="SearchOutlook2010" Guid="CFF13DD8-6EF2-49EB-B265-E3BFC6501C1D" Variable="Outlook2010"/>
<util:ComponentSearch Id="SearchOutlook2010PIA" Guid="1D844339-3DAE-413E-BC13-62D6A52816B2" Variable="Outlook2010PIA"/>
<util:ComponentSearch Id="SearchOutlook2013" Guid="F9F828D5-9F0B-46F9-9E3E-9C59F3C5E136" Variable="Outlook2013"/>
<bal:Condition Message="This Setup need Outlook 2010 or 2013 to be installed">
Outlook2010 OR Outlook2010PIA OR Outlook2013
</bal:Condition>
This is working great so I'm trying to do the same thing for MS Project but I am having little luck finding the appropriate Component ID values to use to find Project 2010/2013. Will someone please help me?
Also, another question regarding the PIA. If "Outlook2010PIA" is true, should that be enough to continue? I copied this from an example elsewhere and found that odd.
Thanks!
Using Wix 3.5, my initial MSI package (MyProduct v1.0) contained quite a few features, e.g. MS Word 95/XP/2003/2007/2010, MS Excel 95/XP/2003/2007/2010, MS PowerPoint 95/XP/2003/2007/2010.
Their feature level was initially set to 0 but set to 1 if the specific app existed (using AppSearch). In other words, if MS Office 2003 was installed, only Word 2003, Excel 2003 and PowerPoint 2003 features had level=1, and the rest remained as 0.
Recently I made the upgrade MSI package (MyProduct v2.0) using the same approach people said, such as, in How to implement WiX installer upgrade?
And I scheduled "RemoveExistingProducts" After="InstallValidate" in "InstallExecuteSequence".
Here is a fatal bug: suppose the user had MS Office 2003 when he installed MyProduct v1.0. Now he upgraded MS Office to Office 2007 (therefore Office 2003 no longer exists), before he upgrades MyProduct to v2.0. My installer can't handle this. Why? I've tried to remove the old features (e.g. Word 2003, etc.) using the type 1 custom action by calling MsiSetFeatureState function. Although that function returned ERROR_SUCCESS, their states didn't get set to ABSENT but remained as NULL (I know the feature levels for Word 2003 etc. are 0 since they don't exist any more, and I believe that's why feature state unchanged), and I gave up eventually. (If you have any idea to make it work, please guide me to the light!!!)
Anyway, my main question is not about the above bug. For now, I am more concerned about unable to remove the existing product, v1.0:
Case1: upgrade without upgrading MS Office (works)
When I tested the upgrade without upgrading MS Office, the upgrade works, and there is only one entry (MyProduct v2.0) in Add/Remove Program (aka ARP): the upgrade removed the earlier product entry from ARP.
Case2: upgrade after upgrading MS Office (disaster)
However, if I upgrade Office from Office 2003 to Office 2007 and then perform the MSI upgrade, not only Word 2003 feature / Word 2007 feature were installed, but also there are two entries (MyProduct v1.0 and MyProduct v2.0) in ARP. If I tried to uninstall v1.0 in ARP, it seemed to uninstall it, but if I refresh ARP, v1.0 re-appears, so I couldn't even uninstall v1.0.
I compared the log files generated for both cases but it didn't tell me why.
And I have no idea why. Can anyone help me?