The title probably doesn't reflect what I'm trying to do well.
I am working on a Task Pane Office Add-in, mainly for Word, that is currently the new type of Add-in using Office.js, however, we need to support Word 2010, so to my understanding we need a VSTO version of the Add-in that does the same things.
We don't need to interact with the document, we don't read or write to the document, so we don't need any code to run outside of the web app, the whole Add-in is written in HTML and JavaScript. So my thinking is we could create a very simple VSTO Add-in that just contains a WebView that loads our web app without Office.js.
Is that a reasonable way of achieving backward compatibility to Word 2010?
My problem is finding a starting place to do this. Word 2010 is very old, and it seems using a WebView has all sorts of compatibility issues and other bugs. I'm having trouble finding reliable information/tutorials.
Is it possible to bundle WebView2 with the Add-in to eliminate the backward compatibility issues?
Or maybe my thinking here is all wrong, and there is better way of achieving backward compatibility?
I'm open to anything, just seeking information.
One option is share code/ libs. If you need the same functionality. This will enable you to continue servicing your users that use the VSTO Add-in on Office on Windows and the ones using Office addins.
Create a shared class library by refactoring code into a .NET class library.
Create a REST API wrapper using ASP.NET Core for the shared class library.
Call the REST API from the Office Add-in to access shared code.
Microsoft Share code docs
It doesn't work that way. The WebView is not enough for running web add-ins on older Office applications like Word 2010. The support for add-ins should be implemented in the host application itself.
The best what you could do is to develop a VSTO based add-in without relying on the existing web add-in. Or just create a web app (without officejs involved) which can be run in a browser hosted on the task pane in Word.
Related
I have a web application that creates complex Office documents in Excel, Word, and PowerPoint; and I need to convert the application from Visual Studio to Visual Studio Code. The previous application uses the Microsoft Office Interoperability Assemblies to generate and manipulate the documents. So far I haven't found any comparable interface or extension for Visual Studio Code. Can someone point me to a possible solution?
You can use the same technique even in VSCode. It allows adding COM references to projects, see Adding Microsoft.Office.Interop.Excel to VS Code for more information.
The previous application uses the Microsoft Office Interoperability Assemblies
Office Automation is used for dealing with Office applications locally. If you are moving the code to VSCode you may also consider using the Open XML SDK instead, of course, if you deal with open XML documents only. Read more about that in the Welcome to the Open XML SDK 2.5 for Office article. Also you may take a look at any third-party components that don't require Office applications installed on the system.
Is there a way to explicitly mention that the Add-in will not be supported in IE11 through the manifest.xml. As there are few features that require IE Edge, the add-in is getting rejected for issues in IE11.
You cannot explicitly declare support for specific versions of Office or Browsers.
More importantly, even if you were able to, failing to support IE11 would result in your Add-in not supporting Office for Windows as both 2013 and 2016 use an embedded IE11 instance to host add-ins.
If you have code that requires support for specific JavaScript or HTML functionality, you either need to provide an alternative for browsers that lack that support or use a polyfill to support that functionality.
I'd highly recommend taking a look at Polyfill.io.
I have started using Git for my other development projects (PHP, HTML, JavaScript, etc.) and can now see how beneficial it is, however I've been unable to find anything similar for Dynamics CRM 2011/2013 as a lot of the solution development is done within the web interface.
I'm guessing this is not possible, but could someone with more experience than me please confirm this or let me know which tools I should be looking into?
Thanks
You can use the Visual Studio Developer Toolkit available in the SDK to version control your plugins and web resources initially. I'd recommend this as your first step.
If you choose to take it further you can also look at using the SolutionPackager tool to version control your solutions. This will split out your solution zip file into separate version controllable files for each component. It works best when you follow the developer workflow outlined in the linked MSDN article
The add-in we have developed works well on Outlook 2010. Can we reconfigure the same exe so that it gets installed on all Office apps like Word, Xls, PPT etc., including Outlook in one shot?
You need to create a separate installer for each Office product (Word, Excel, PowerPoint, Publisher, OneNote, Project, etc.) you want to use your add-in for. If you have shared behavior for the add-in amongst Office products, you can factor it out into its own assembly (i.e. Class Library) and have it shared between all projects.
Visual Studio has separate project templates for each Office product you intend to create Office add-ins for. You can follow the same pattern for integration with VSTO as you did with Outlook to integrate with other products - they just require their own project/assembly since each product is an entirely different application boundary and requires its own deployment manifest.
I have an Excel 2010 Automation project using Microsoft Office Interop library in C#.NET. But now i need to migrate it to work with Open XML SDK 2.0. Any guidelines or suggestions?
OpenXML SDK provides far too many low level access / functions. It consumes some time to master but has huge flexibility.
For starters, use libraries like EPPlus or ExcelPackage. If you have very very large files to process frequently, OpenXML should be best bet.