I'm working on an add-in used in Word (already published and used). Our requirements are Word 2016 but that should be it as far as I know. Usually, when we had users complaining about not being able to install our add-in, it turned out they had an older version of Word etc.
This is in our manifest file:
<Requirements>
<Sets DefaultMinVersion="1.1">
<Set Name="WordApi" MinVersion="1.1"/>
<Set Name="DialogApi" MinVersion="1.1"/>
</Sets>
</Requirements>
This client has the following:
Commercial License of Office 2016
Office Professional Plus
When installing the add-in, they get the message: version of Word is not compatible. When installing other add-ins, the client claims they install fine.
Could this be on their end (and if yes, why?) or is there something that can be done on our end (for instance, in the manifest file) to make our add-in more compatible with all versions of 2016 Word?
Support for DialogAPI 1.1 and WordAPI 1.1 depends on the build of Office 2016 being used.
If your client is using a click2run install, they need to be on Version 1602 (Build 6741.0000) or later
If they are using an MSI install, they need to be on Build 16.0.4390.1000 or later
For more information on DialogAPI support requirements, see here, for WordAPI support requirements, see here
Related
We're currently trying to publish an add-in on the office store, but it uses functionality from the 1.9 version of the ExcelApi requirement set. This requirement set is not supported on Excel for OSX 2016 (which is fine, none of our clients are on OSX of any kind). However, when I update my manifest to reflect this requirement, manifest validation (as well as the manifest upload section of the MS partner center) still shows Excel for OSX 2016 as a supported platform, and we've been rejected because our add-in fails testing on that platform. This is what the Requirements section of the add-in's manifest looks like:
<Requirements>
<Sets DefaultMinVersion="1.1">
<Set Name="CustomFunctionsRuntime" MinVersion="1.1"/>
<Set Name="ExcelApi" MinVersion="1.9"/>
</Sets>
</Requirements>
According to this page, Office for OSX 2016 doesn't support ExcelApi above 1.1, and doesn't seem to support the CustomFunctionsRuntime at all, so I'm not sure why it's still considered a valid target: https://learn.microsoft.com/en-us/office/dev/add-ins/overview/office-add-in-availability
Any insight would be appreciated. Thanks.
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.
Recently Microsoft recanted their decision to drop support for Windows XP with Visual Studio 2012 Update 1. I've been told by our product manager that I can move to using the Visual Studio 2012 compiler provided:
We continue to support our Windows XP customers.
We don't introduce any additional pre-requisites beyond Windows XP SP3 (since we have a contract with some customers to that effect).
I've tried converting our solution to use the VC2012 XP tool set and all now works well from a code point of view. However, our WiX installer project complained about the fact that we were now trying to include the VC2012 Runtime Merge Modules and that these only support Windows Installer 4.5. This version of Windows Installer wasn't available in Windows XP SP3 so it would mean that our customers would have to install the Windows Installer 4.5 Redistributable package in order to be able to install our product.
Is it possible to work around this issue and still use those merge modules in a way that would support Windows Installer 3.0?
So we're currently setting:
<Package InstallerVersion="300" />
But the merge modules appear to need us to set:
<Package InstallerVersion="405" />
Which would mean we couldn't support Windows XP SP3 out of the box.
Here's the error from WiX:
warning LGHT1104: Merge module 'Microsoft_VC110_ATL' has an installer version of 405 which is greater than the product's installer version of 300. Merging a module with a higher installer version than the product it is being merged into can result in invalid values in the resulting msi. You must set the Package/#InstallerVersion attribute to 405 or greater to merge this merge module into your product.
Install Windows Installer 4.5 with your product. It is available for Windows XP SP2 and SP3. After all, the VC 2012 runtime does not come with Windows XP either.
You might be stuck with the idea that you can only install your product as an MSI with any needed merge modules. With WiX's Bootstrapper projects (WiX 3.6 and later), you can easily create a chain of installers and bundle them into one EXE file. The engine (known as Burn) handles any needed reboots, too. If you've installed a recent version of WiX, you've seen burn in action.
If you go this route, you can also remove the merge modules from your MSI and instead all the VC 2012 runtime to your chain.
You need to set the InstallerVersion attribute in Package element to set the required Windows installer for Setup.
Ex. for 3.0 Windows Installer
<Package InstallerVersion="300" />
Recent Visual Studio 2005 security updates may be causing problems for us.
We build and internally distribute SDKs written in C++. These SDKs are a collection of header files and static libraries only. After installing the security updates our SDKs now depend on the newer versions of the MSVC CRT DLLs. These SDKs are used downstream in projects which produce EXE files.
If one of these EXE files is built with a mix of SDKs (some from before the security updates, some from after), then the EXE file produced makes reference to two sets of MSVC runtime DLLs. E.g:
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.4053" processorArchitecture="amd64" publicKeyToken="1fc8b3b9a1e18e3b">
</assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762" processorArchitecture="amd64" publicKeyToken="1fc8b3b9a1e18e3b">
</assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>
Does this mean that at runtime this EXE will be using both versions of the DLL? Does this mean we must distribute both versions of the MSVC Runtime DLLs with this EXE?
Is there a simple way to avoid this problem without forcing all SDKs to be built with the Visual Studio 2005 security patches in place? (This would be undesirable for some of the older and quite stable SDKs that we don't want to rebuild unnecessarily)
Is is possible to simply rewrite the manifest file on either the SDKs or the final EXE file so that only one version of the MSVC CRT DLLs are mentioned?
My understanding is that the relevant updates are as follows:
Security update for Microsoft Visual Studio 2005 Service Pack 1: KB971090
http://go.microsoft.com/fwlink/?LinkId=155934
Security update for Microsoft Visual Studio 2008 Service Pack 1: KB971092
http://go.microsoft.com/fwlink/?LinkID=155933
I have discovered two other questions which are similar:
VC++: KB971090 and selecting Visual C Runtime DLL dependencies
Does the latest Visual Studio 2005 Security Update cause C runtime library issues when hot fixing customer sites
1) Yes it means the runtime is using both versions - something you never want to happen. It should only ever reference a single version of the DLL(s)
2) There is a method that I've developed to force the version to be the SP1 version (without the security update). I've outlined it here
3) You could disable manifests entirely and do them by hand, but I don't recommend this, as it's a pain to maintain different manifests for your debug and release, and it's an error-prone way of dealing with the problem. It would be better to use the workaround I mentioned in (2) above.
As Ted says, at runtime your executable will be trying to use both versions of the DLL. This is probably because you haven't fully recompiled the entire project (or you are using external libraries that have been compiled to depend upon the .762 runtime).
The good news is that if both these libraries are installed on your client systems then the side-by-side redirection policy will mean that only the latest is loaded. By far the more detrimental side-effect you will notice is when only one is installed (probably .762) that the application will fail to start with the old "application is not configured correctly, reinstalling may fix this problem" error message.
Does this mean we must distribute both versions of the MSVC Runtime DLLs with this EXE?
The easiest solution for you would probably be to just ship the latest version of the visual c++ runtime redistributable which you can get from the following link.
http://download.microsoft.com/download/6/B/B/6BB661D6-A8AE-4819-B79F-236472F6070C/vcredist_x86.exe
It can be a bit of a pain because it asks the user to click "I agree" on a EULA page and requires admin priveledges but by general consensus it is the best option if you can get the user to install it.
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?