I'm developing an add-in for Word, and so far it has worked, I was able to sideload the add-in by creating a network share & adding it as trusted catalog.
But after I made a small change to the manifest.xml it has stopped working. Under Insert => Add-in => Shared Folder it keeps showing "No add-ins currently available. "
I've tried a different share, a different manifest.xml from a different app, deleting the office cache, but it still doesn't work. It keeps showing "No add-ins currently available. "
I've clicked Refresh multiple times.
Very annoying.
I'm on Windows 11 and Office 2021.
Any ideas?
Related
I'm working on a modern Word Add-In that we would like to work inside Word for the Web on Office Online Server (2019) via WOPI. For testing, we would like to sideload the Add-In. I can do this in the O365 version of Word for the Web without problems, but the only option on OOS appears to be loading Add-Ins from AppSource. I also understand from various (informal) posts that centralized deployment is not available in OOS. Does anyone know if it is possible to enable sideloading in OOS?
By sideloading, I mean manually uploading the manifest.xml file via the "Add-Ins" button on the ribbon bar. In O365 this option is called "Upload My Add-In".
Unfortunately, I don't think this is possible - see a related question answered by a Microsoft person.
I have built a Word add-in that works in both native desktop Word and browser Word. I have an Outlook add-in which works in browser Outlook but when I add it to native desktop Outlook I see this:
add my addin through Get Add-ins > My Addins > Add from File
I see the addin
I close the dialog
the addin does not appear in the ribbon
I re-open the Get Addins dialog and my addin is not there.
Outlook version: Outlook for Office 365 MSO (16.0.12228.20322) 64 bit
Just in case someone else does something silly...
I followed the good old process of elimination, starting with a working manifest from here.
One thing that confused me slightly is that Outlook Desktop often takes a while to show the add-in in the ribbon.
However the solution was that I had duplicated one of my Url elements. When I removed the duplicate Url then the manifest worked in Outlook desktop.
If anyone from the Office addin team reads this it would be great if Outlook threw an exception when I had duplicate Url elements, rather than accepting the manifest.
We developed an Outlook Web addin in React, build with Webpack. It works on the web, on apps, and on desktop.
We have a very strange case we cannot explain with a customer. We did test on a virtual machine (Windows : 10.0.16299.0 ; Office license : Microsoft Office 365 ProPlus ; Outlook desktop version : Outlook for Office 365 MSO 16.0.10730.20264 32 bit) with both administrator account and normal user account :
Addin is working well with an administrator account, web and desktop.
Addin is working well on web with non admin account, but JS seems not to be executed on desktop. Static HTML content appears, meaning it is not a network or firewall issue.
We have another version of the addin, not using Webpack and React, just pure JS : it is working well both on web and desktop, meaning JS can be executed on the non admin account. We can see the addin loaded in the cache files of AppData.
Is there any problem of React based addin which could explain this very strange behavior (why this difference between an admin and non admin account ? how could JS could be interpreted differently depending on the type of account ?) ? Or any known incompatibility with Webpack ?
Microsoft Store developers did not find this problem running tests on the code...
I have a Web API service that is tested and working well. In a separate project I have an Outlook Web Add-In. The UI is working just fine. Now, I would like to make calls to the Web Service I've created.
The Web API project launches IIS (using SSL)
I've copied (copy/paste) the Office Add-In folders to what would be the root folder ... (at least I think I have the web root folder)
After launching the Web Service from Visual Studio, I run OWA and side load my Add-in. The right Icon appears. When I click on one of the commands in the drop down, nothing happens. Chrome's debugger doesn't show any messages that would indicate that my Add-in has been called. No errors.
My team is in the process of developing an Office 365 add-in, specifically to enable interaction with a hosted web application, and we're encountering a "Permission needed / Bad Request" error that we can't seem to pin down.
Context:
Developing and testing the add-in involves configuring an Azure Active Directory v2 application via the management portal as well as (for development purposes) creating an xml manifest file (which is for v1 apps as opposed to the json format for v2) that can be side-loaded via the O365 interface to provide access to our hosted app (currently only xml manifests can be side-loaded). We're still very much in the process of figuring things out in Office 365, as well as Azure/Active Directory and Microsoft Graph, and the documentation is fairly broad and doesn't always seem to be up to date.
Problem Description:
One of the problems that we're run into occasionally is encountering a "Bad Request" dialog message (in a browser dialog titled 'Permission needed') that is displayed when clicking the toolbar icon for our add-in. The actual URL being requested is similar to https://store.office.com/client/consentnotification.aspx with a number of parameters representing our application and it's required permissions. This results in an HTTP 400 with "Bad Request" being the only response content.
This is happening when the user clicks on our add-in in the O365 application toolbar and is occurring at the point where the user would have to authorize permission for the add-in.
This error seems to be related to the application configuration, but we can't seem to sort out how specifically (ie, some developers are encountering it, and others are not. Sometimes it'll show up if we recreate the Azure Active Directory application using one version of portal or another (there are currently two, with the v2 version being in preview).
Can anyone offer suggestions as to what might be causing this or provide information on why this might be occurring? We're not blocked, but it is rather annoying to deal with in development. I've done a fair bit of research trying to sort out why this is happening and I've gone through a number of tutorials/introductions on configuring Azure apps without success.
This turned out to be related to the Azure Active Directory Application configuration.
For the applications where this was occuring, the AADv2 application manifest was using a "signInAudience" value of "AzureADMyOrg". For cases where it was working as expected (ie, properly populating the permission request dialog) the "signInAudience" was set to "AzureADandPersonalMicrosoftAccount".
After some testing, the solution for our particular problem seemed to be either manually editting the AADv2 application manifest (json) to have "signInAudience": "AzureADandPersonalMicrosoftAccount", or via the Portal by setting the Application's Authentication Supported Account Types setting to be "Accounts in any organizational directory" (this results in a manifest setting of "signInAudience": "AzureADMultipleOrgs" which also seems to work).