On an Intranet web page, I have a link to an Excel document that resides on a network drive, like so:
ms-excel:ofv|u|file:///N:/folder/file.xlsx
This is an office protocol handler described here.
On computers with Office 2019 installed, the Excel document opens with the registered application (Excel) without problems; on computers with Office 2016 I get the following error:
The action couldn't be performed because Office doesn't recognize the command it was given.
I compared the registry keys at \HKEY_CLASSES_ROOT\ms-excel\ and they are basically the same (of course the path to protocolhandler.exe is different).
When I execute protocolhandler.exe on the command line on the computers with Office 2016, I always get the above error regardless of how I try to launch an Excel or Word document (e.g. ms-excel:ofv|u|file:///... or ms-word:ofv|u|http://...)
Versions of Office:
Office Professional Plus 2019 Version 1808 (Build 10382.20010 click-and-run) 64-bit
Office Professional Plus 2016 Version 16.0.5266.1000 MSO 64-bit
Is there any way to make the protocol handler work with Office 2016?
As you can imagine, that exe handles all the different protocols integrated into MS products. Because of this, every variation of office (or windows) need to have their very own version of this file, in order to operate correctly. Which is also why this file comes deeply embedded within the Office product folder.
Related
I am developing a COM object that implements the excel RTD interface using .NET c#. It is a x64 bit project and office is also 64bit.
The 64bit RTD COM object works just fine in Office 2016 (also 64bit).
I can register the COM object at the CURRENT user level and Office 2016 loads it just fine. Machine level registry works just fine too.
However, when using office 365 64bit version. I can only get it to work when registered at the HKLM level.
I would like to get it to work at the User level. Not everyone in the organization using it may have admin rights to their machine.
Is there some way to get it to work? Am I missing more registry settings or is there some policy that is blocking it at the user level?
NOTE: excel does recognize my COM object, but disables it. I cannot enable it at all. This all feels like some policy restriction new to office 365.
It looks like you didn't find the right hive in the windows registry for registering your RTD COM server on a machine with Office 365. See Add-ins for Office programs may be registered under the \Wow6432Node for possible routes.
I'd suggest investing your time for exploring capabilities of Add-in Express which allows creating installers for you. Also you may take a look at ExcelDNA.
One of my add-ins, Formula Formatter, works well in Office 365. However, one client told me it cannot be loaded in Office Professional Plus 2016.
Does anyone know what may be the reason? Should we do something special in the manifest xml for Office Professional Plus 2016?
In its manifest, Formula Formatter specifies the requirement set ExcelAPI with a minimum version of 1.2. Per the documentation for that requirement set (https://dev.office.com/reference/add-ins/requirement-sets/excel-api-requirement-sets) your customer will need to be running "Version 1601 (Build 6741.2088) or later". Customers that have a non-subscription version of Office won't have that requirement set.
If you remove the requirement set from the manifest, your add-in would be available on Office 2016 but you would need to ensure that your add-in has a good user experience when they are not present.
One of our users has an Excel VBA project that references Microsoft Windows Common Controls 6.0. The corresponding MSCOMCTL.OCX file is no longer in our image, and so of course the project won't run due to a missing reference.
Rather than installing Microsoft Visual Basic 6.0 Common Controls on our Windows 7 64-bit systems with Office 2016 64-bit, is there something different that the user can reference in their project that is more modern and supported?
Side question: If we do install it, will it even be able to work, with 64-bit Excel calling a 32-bit OCX?
Answer: I tried on a 64-bit Office installation, and the answer is No. You can install it, register it, and reference it, but you can't actually use any of the UI controls from it. They simply don't appear in the list.
I developed a 64-bit Addin.
For testing I added it on a laptop (64-bit machine with 64-Windows7 Enterprise and 64-bit Office 2010) [other than the one i developed the Addin on], its works fines i can call n use its functions. but when i add the same addin on a desktop machine (64-bit machine with 64-Windows7 Enterprise and 64-bit Office 2010), its functions are not available and no error message displayed as well. But when i re-launch Microsoft Excel 2010 a message appears.
Message text : "The file you are trying to open, 'MyAddin.xll', is in a different format than specified by the file extension. Verify that the file is not corrupted and is in from a trusted source before opening the file. Do you want to open the file now?"
As per the message text i verified that the location for xll is included in "trusted location". Yet the issue not resolved.
Whats your opnion in this regard,
Thanks & Regards,
Maverick.
Check that you have compiled it Release and not Debug (if you've done the latter it will only work on machines with the debug versions of included DLLs, which usually means machines with Visual Studio installed).
I have a site developed in Microsoft Office SharePoint server 2007 and I have installed Microsoft office 2010 on my machine. When I try to access excel file stored in document library. It gives me an error saying that it requires a Windows SharePoint Services compatible application.
It was working fine when I have Microsoft office 2007. So I am confused whether SharePoint is compatible with office 2010 or not...?
Thanks
Sachin
Yes it is compatible and it should work. A number of things could be going on.
The OWSSUPP.DLL may not be registered correctly.
You could register it manually or reinstall
If you have the 64 bit version of office there are some known issues opening data in SharePoint.
http://www.knowsharepoint.com/2010/06/sharepoint-datasheet-view-and-office.html
Windows SharePoint Services Support files may not be installed.
in this case install these through Add/Remove programs. It's in the office tools section of the MS Office application.
If you have some applications that were part of Office 2003 or earlier you may need to uninstall them.