I have an Office Word add-in that I wish to make it work with Office Word 2016 for Mac. I tried looking into official Microsoft documentation and could not find anything. I want to reuse as much code as possible while still having the extension to work with older versions of Word as well as Office Word 2016.
Is there any way to do this? Any help, even if it is something remotely related to this is appreciated.
TL;DR;
There is no way to do that.
Microsoft has bet on a new technology suite also called Office add-ins but web based. They are compatible with Mac. The old COM based approach (on which VSTO .NET add-in are built on) are legacy.
There is no way to reuse .NET code with this new technology, except of course to port business logic to the web server (which serves the web based add-in).
More reading on the comparison with the two add-ins generation: see this article I wrote
I second Benoit's answer. In addition, Not sure how complex is your add-in in terms of interactions with the document content, or if its a service that then inserts or imports data from a backend. Depending on that you will have more reusable code.
I would recommend you to do a full analysis on what APIs you need for your add-in to work properly. The new model offers big value with both supporting multiplatform and an easier deployment model. It also provides many rich APIs you can use, however the API depth its still not as rich as VSTO. Our goal is to get there.
I would be curious to understand if there are any gaps on you migration analysis.
thx!
Related
Well, that's a very important thing, or at least, I think it is, so, please read it carefully.
Introduction
My background is the COM/VSTO land and due to new requirements, I'm slightly merging to office.js.
First, I was very pleased by the concept that unlike Word, Excel & PPT ofiice.js add-ins, Outlook Web Add-ins install directly on the user's exchange inbox, which means: install once, run everywhere. This worked for me very well at the beginning but it quickly turns out, in some situations, to be terrible, or at least in two of my cases.
We have to agree that Outlook Web Addins (and office.js addins in general) are not mature enough to completely replace COM/VSTO/VBA addins. The ONLY clear benefit is the multi-platform support. So, as I already have clients who use COM Outlook addins, which works more than perfect for their needs, they just needed a way to have the same addin on Mac, Web and Mobile, and I spend some time learning how to build addins using office.js and did deliver some good results but after they started using the new addin, some unexpected drawbacks flopped to the surface which made me think twice!
Now, on Windows, we have both addins running for Outlook the COM & Office.js one but as far as I can tell, there is no comparison between the two, the COM addin is far more superior than the equivalent Web Addin. If I have to state ONLY one benefit of COM over office.js in Outlook, I'd say that office.js lacks the support of inboxes that not use Exchange server as a backend, so Gmail, Yahoo and 3rd-party email providers are not supported which is too frustrating and we should keep the COM addin there.
Problem: Below I'll provide two use cases where the Outlook Web Addin is very [un-welcome] with the presence of a COM addin.
Scenario #1
In one addin, we intercept and parse the email before it is sent to see if it will allow Outlook to send it or not. This works perfectly with both, for COM addin we use ApplicationEvents_11_ItemSendEventHandler event and for Web Addin, we use the horribly implemented <Event Type="ItemSend" FunctionExecution="synchronous" FunctionName="checkEmail" />, the terrible weakness in this implementation is, unlike in the COM add-in, you cannot give the user the option to turn ON/OFF this option and they will always have to see the annoying msg, "[You Add-in] is working on your request"
and, in addition to your inability to customize the msg's text shown, you cannot hide it or disable it which results in a bad UX.
To make things even worst, I was expecting that if both addins are there and waiting for the Send Event to intercept, I assumed it's the COM add-in which should receive the event first then when processing it, it will set its Cancel variable to true, this way the Web Add-in won't be aware of the event at all, but, surprisingly, the exact opposite happens, the Web Add-in received the event first, process it and cancel it: event.completed({ allowEvent: true });, while the COM addin was having good dreams.
Scenario #2: Having an addin that acts as a Spellchecker.
While we have full control over the Word editor for [Windows] Outlook, the COM addin provides excellent results, which is not the case in Web Addin where you stick with a custom task pane and provide a minimal user experience that does the very basic things, so, we find ourselves having the two spellcheckers in Outlook one is excellent and the other one is ugly and its presence ONLY makes sense when it runs in Outlook for Mac. For Outlook.com, a chrome extension would be the ideal solution and for mobile, Compose Mode is not supported yet!!
The Question
Having said all the above, hope you didn't skip it, Is there a way to disable a Web Addin for Outlook in Windows and, possibly, Online? In other words, can we SELECT the platforms that are supported by an Outlook Web Addin? or let's say it again, like: can we SELECT the platforms that an Outlook Web Addin existence makes sense?
First of all I want to thank you so much for taking the time to share the detailed feedback. I agree for your specific type of Add-in there might be challenges to provide a better experience, more on this later.
Second, to answer your specific question, no, we dont support a way to disable Add-ins on specific platforms or select the platforms your Web Add-in will be targeting, in Outlook.
That been said, I think you are requesting many features on this post, the right place for this is our uservoice channel.
considerations:
We have a feature than enables COM/Web Add-ins compatibility in
Win32, basically disables the Web Add-in if you have a
still-betterCOM Add-in. You can find the details here.
However, this feature is not yet supported in Outlook (just in
Excel, Word and PPT) but its something we are planning to add. Let
me know if you find this useful, it will solve the issue of
conflicting item sends events you mentioned.
We dont have APIs to
provide rich interaction of the mail content, for a spell checker I
appreciate if you can share that in uservoice.
Hope this helps.
I'm looking for an explanation as to what I can and can't do as well as advantages and disadvantages to using Visual Studio for coding instead of the built in text editor in Excel.
From my perspective
Use VBA editor (VBE) if you
develop ad-hoc apps for yourself, friends
are the only one who works on a project
mainly works with the Office object model - no communicating with System, Web, database etc.
don't use source control (Note: Rubberduck is here to help if you do so)
don't include too many dlls from the Reference form
don't want to learn new platform (.NET)
Note, I did all the above and I could live with just VBA for long time without too many problems and in a few ways VBA is much better than VSTO e.g. in debugging (here I mean, you can change almost everything when you are debugging VBA and you'll be still able to continue, there is no way to do the same in VSTO)
Use VSTO if you
want to better support for System, Web, XML, database tasks. NET is
much more better especially if we're talking about web or database
stuff
want to have better support (sometime out of box) for version control
(GIT, SVN, TFS, Perforce)
don't won't to have problems with dependencies (this could be
actually painful as well)
want to use new VSTO objects like NamedRange incl. events
want to learn new platform
I remember myself a few years ago when I thought VSTO brigs something new to Office object model, and it doesn't if you don't count the VSTO objects. So if you're heavily working with just Excel object model (manipulating with ranges, sheets, workbooks, calculating) you can still live with VBA only.
I also remember that with VSTO you can't easily create UDF (custom function)
Also seems like that MS is not going to invest too much effort to add/update/improve VSTO, they rather focus on Office API
VSTO blog - comments
Thanks for your question Ben, we have already publically announced that we will not be turning off VSTO or VBA in the next version of Office. All of our new investments are in Apps for Office and Apps for SharePoint and making the Office 365 APIs more robust. We will not be making any future investments in VSTO or VBA
It might look like I'm against VSTO but I'm not, I've been using it for more than 4 years daily and returning back to VBA just for quick testing or quick projects.
Hope this helps
From developing language, Excel Editor is VBA, and VS is C#/VB.NET. If you have a light function, you could use VBA directly, if you have a large requirement, .NET/VSTO would be suitable, it would be convenient to manage your code in VS, .NET.VSTO is managed code, it’s performance is better than VBA. With VSTO, you could custom Office UI. From distributing your project, you need to copy the office file with macro enabled. You could use ClickOnce or Windows installer to distribute .net/VSTO solution.
I have googled, but can´t find a good answer. I´m a .net developer and looking into starting with Microsoft Dynamics (CRM and AX). My question is if I can use .net on this platforms or do I have to learn x++?
Yes and no. Dynamics CRM consists of a bunch of different customizational entries and some of them are .NET based (plugins, custom workflows, WCFs, external webs) while some are not (default workflows, JavaScript, XML customizations, FetchXML).
In my experience, at least based on the reality where I'm stationed, there's an abundance of people who can configure CRM but there's an embarrassing scarcity of skilled developer who can code .NET (and JS) to program the thing.
MS does what it can to make it possible to configure everything without coding but in the end, some things can't be resolved other than by good old hacking. Plugins is the golden goose, I'd say. If you learn how to write and install them, you're set. It's a bit of a threshold, that's true. But then again - if it'd be easy, everybody would be able to steal your job.
Yes .NET is the platform of choice for server-side customization of Microsoft Dynamics CRM. Start here: https://msdn.microsoft.com/en-us/library/gg327971.aspx. There's a lot of reading but you could be writing your first plugin in a few days.
I'm intentionally vague here because you should really take the time to read the materials out there to learn the right way. It will help you out a lot more then me giving you a paragraph summary.
My company has a 30yo hypermedia system, based on SGML. It's somewhat similar to HTML. Now some of the customers want to use Microsoft VS to write their screens. I'm new to .NET and have no idea where to start. I'd like to have syntax highlighting, auto completion and available properties suggestion. We'll only support VS 11 and start the development on the beta.
It sounds like you want to implement a Language Service.
MSDN has extensive documentation and thorough tutorials on the basics of building a Language Service. You can start with Language Service Overview (Managed Package Framework) and its related topics.
I heard Microsoft allows use of commercially available Office UI controls, with the exception of competing products, such as a word processor or spreadsheet app, etc.
How true is that?
Also, if it is not true, do you know of any free Ribbon controls?
You should look at Jensen Harris' blog entry about licensing the Office user interface which explains it in great detail. However I believe the relevant point here is:
There's only one limitation: if you
are building a program which directly
competes with Word, Excel, PowerPoint,
Outlook, or Access (the Microsoft
applications with the new UI), you
can't obtain the royalty-free license.
You can still build a word processor with a ribbon. You just can't use Microsoft's ribbon. There have been ribbon-like interfaces around for a lot longer than Office 2007 (the one that sticks in my mind most is the pallet in C++ Builder: very similar to a ribbon), so they definitely don't own the concept, if that's even possible. I've seen a number of third-party or even open source ribbon controls.