CODEWITHSUNDEEP
office-js
Fergie
Fergie

Reputation: 6235

Can't side-load add-in into MS Word on Windows

I am currently developing an Microsoft Word Web Add-in.

Since I use a Mac, I have downloaded a Windows 10 VM and installed Office using my Office 365 subscription.

I can get Word Add-ins to run on Office 365 and Word for Mac, but not on Word 2016 for Windows.

I can't get Word 2016 on Windows 10 to run any add-ins, whether it is one I have written myself, or one downloaded from the store. Word always shows the Add-in frame with "loading" and then it just stays there; the add-in never loads.

I don't get the menu option to attach a debugger, and there are no obvious error messages.

Are there some restrictions to running Add-ins on VMs? Where do I start to debug this?

EDIT:

I just noticed that my own side-loaded add-in throws an error in a popup dialog box that opens behind Word, which then prevents word from opening further add-ins. So if I close the popup dialog box, then add-ins from the store work as expected. However I can't side-load my own add-ins.

The error I get is

Cannot find ‘file://msedgewin10/manifest/boilerplate/home.html?_host_Info=Word$Win32$16.01$en-US’. Make sure the path or Internet address is correct.

However if I paste this address into IE it opens the file with no complaints. Very strange.

Upvotes: 3

Views: 1681

Answers (2)

Fergie
Fergie

Reputation: 6235

Here was the fix in case anybody is wondering:

My initial side-loaded add-in was creating an error that caused Word to create an error notification that popped up behind Word and then blocked execution of all subsequent add-ins. All error popups had to be closed before add-ins would work again

So actually my side-loaded add-in was broken, and this caused all subsequent add-ins not to work.

A bit of a silly error, but a head scratcher none-the-less.

Upvotes: 2

Marc LaFleur
Marc LaFleur

Reputation: 33094

I've don't recommend using file:// uris for side-loading. It is generally easier to use the SMB Share method with Office for Windows. When I'm developing on a Mac I tend to share the wef directory from my Mac so my manifest changes show up in both Mac and Windows at the same time.

The popup issue is something different whoever. This is likely happening because your using JavaScript to open the popup (i.e. window.open(...)). Using this method results is very odd behavior due to the number of browsers and browser engines Office leverages for Add-ins.

For popups, you should always use the Dialog API included with Office.js. This API is custom tailored to work across every supported Office environment (Windows, Mac, iOS, Android, Chrome, Firefox, Safari, IE, Edge). It is particularly useful when you want to have parent/child communication between the add-in and the dialog; something not easily accomplished on Mac or Windows where the popup is running in an entirely different browser instance from the add-in.

One key tip when it comes to developing add-ins is to sign up for the Office 365 Developer Program. This gives you access to a free Office 365 Developer tenant. While this may seem like overkill, it will greatly simplify your life as it allows you to use O365's Centralized Deployment feature to instantly deploy your manifest across a number of Office clients (Windows, Mac, Online, etc.). When it comes to dev/test, it is a huge time saver. It also does some lightweight validation of your manifest which can catch some common mistakes.

Another tip is to use Azure Web Apps for hosting the add-in. This gives you a public URL and SSL cert out of the box (SSL is required by Office for all add-ins). The best part, you can run up to 10 Azure Web Apps for free. I typically push my code up to the size as part of my add-ins build process. Azure supports publishing via FTP/SFTP, continuous integration (VS Team Services, GitHub, or BitBucket) or even from a local Git repository.

Upvotes: 1

Related Questions