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.
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.
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.
Need to use older version of RTF without overwriting the MS Word version
Hi
I have a system that was developed in VB6 (Shortly to be rewritten in VB.NET) which uses rtf documents saved from MS Word 2002 which I scan to isolate certain details and change them. The user now wants to upgrade to MS Word 2010 but this causes problems within my system because it uses a later version of RTF. Is there any way that I can take the .DOC or .DOCX inputs and run them through an earlier version of RTF? I do not mind the fact that it will drop some functionality.
Regards
Mac
You could use DocX to read the data you need directly or possibly down-convert the documents.
You might need to make the DLL COM-visible (DocX source code is available on GitHub) or write a wrapper DLL that is COM-visible so this can be used in VB6.
This approach should save you time when you rewrite the app in VB.NET.
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
Long ago writing VBA macros for MSFT Office was part of my job.
Now it looks like I may be traveling down that road again, and I have not touched MSFT Office for anything serious in years.
Is VBA still the de-facto standard for creating msft office extensions?
Is it possible to write (non-second-class-citizen) MSFT office extensions in any language besides VBA yet?
Macros are still good for prototyping. However, since they are an easy attack vector for malicious code I would try to avoid them for wide use. Have you consider Visual Studio Tools for Office as a platform?
The "state of the art" is to use a .NET language for Office development, using VSTO. This is typically done via C# or VB.NET.
My take on this would be to integrate VSTO and IronPython. We have made several solutions with this combo and are very happy with it. It enables you to write core parts of your solution in C#, but at the same time have a flexible environment to customize your application.