I am planning to develop a outlook add-in which will work with the desktop version of outlook 2010 and 2013.
Can i publish it on the online office store (https://store.office.com/) or is it that the store only allows submission of office 365 apps???
I tried looking at the store's documentation but it does not mention anything on the topic.
I have tried contacting Microsoft support but they seem to have no clue.
You can't publish COM add-ins to the Office store.
COM add-ins (like any other Windows desktop applications) can be published to the Windows store.
Office Store only accepts JS based addins. COM addins for the desktop versions of Outlook cannot be distributed though the store.
Related
Is it possible to create .msi installation file to load a modern outlook web add-in (not native) on your pc to avoid to ask the user to load the add-in manifest manually?
Office web add-ins are not designed for deploying using MSI. Possible deployment options are described in the Deploy and publish Office Add-ins article.
In a cloud deployment, to distribute your add-in to users in your organization by using the Microsoft 365 admin center. To distribute your add-in publicly to users you can publish it to the AppSource (add-ins' store).
We're developing an Outlook addin that is specific and proprietary to our organisation. So we'd rather not put it on AppSource and we'd rather not put the addin source files (all the js,css etc) on a publicly accessible url even if we can keep the manifest file private.
Is there a way, through centralised admin and deployment, to distribute this Outlook addin to our staff, using Group policies, and still keep all the addin files privately hosted somewhere?
Yes, you can deploy an add-in by side-loading the add-in manifest xml file using Centralized deployment.
Yes, you can host add-in files privately but make sure the add-in host is accessible from your Outlook client.
If add-in is bound to work only when the user is connected to a particular network/VPN, it is good to educate the user that the add-in is unavailable outside the network boundary.
For on-premises and online environments that do not use the Azure AD identity service, you can deploy Outlook add-ins via the Exchange server.
Outlook add-in deployment requires Office 365, Exchange Online, or Exchange Server 2013 or later. Outlook 2013 or later.
To assign add-ins to tenants, you use the Exchange admin center to upload a manifest directly, either from a file or a URL, or add an add-in from AppSource. To assign add-ins to individual users, you must use Exchange PowerShell. For details, see Install or remove Outlook add-ins for your organization on TechNet.
Read more about possible ways in the Deploy and publish Office Add-ins article.
Hi I have a SharePoint Farm Solution developed in SharePoint 2010, We have a requirement to migrate it from SharePoint 2010 to office 365.
Is it possible to migrate it without any difficulty or it is not recommended to migrate SharePoint 2010 to Office 365.
You can not directly use the farm solution in office 365, as Farm solutions are not supported in office 365/SharePoint Online. Please see this reference link: https://community.office365.com/en-us/f/156/t/232435
You will have to transform the farm solution in app model and then you will get the same functionality in office 365.
Click Here to see more about the transformation of Farm solutions to App Model.
Note: It's not mandatory that you use Apps only for this. You can use other approaches as well i.e. JSOM, OOTB etc.. It depends on the functionality of your farm solution.
I am integrating Office applications with custom IM solution.
I have implemented the COM class as suggested by http://msdn.microsoft.com/en-us/library/office/jj900715.aspx
I have also registered the COM implementation and hosted the COM server in my exe.
Do I also need to additionally register the typelibrary of my com class ?
I am seeing issues with type library regsitration and lync client 2013.
When I uninstall the type library, Lync Client breaks
Generic COM Exception. Code is 0x80080005.
at Microsoft.Lync.Model.LyncClient.EnsureOI()
at Microsoft.Lync.Model.LyncClient.GetClient()
I understand that Lync 2013 provides its own typelib which I am overwriting.
Is it required for me to register my typelib for Office integration to work ?
I realize this question is dated but I ran into this problem today. I found this article that points to having both Lync 2010 and Lync 2013 installed on the same machine.
Uninstalling Lync 2010 worked perfectly for me. COM operations began working immediately.
I've created several add-ins for PowerPoint 2010 and Excel 2010 using VBA (I don't have Visual Studio available). The add-ins work fine on thin clients using Windows 7 Enterprise SP1 32-bit and Office Professional Plus 2010 14.0.6123.5001 32-bit. On thick clients (regular PCs) with Windows 7 and Office 2010 32-bit, the add-ins will not work. Nothing happens when users try to install them; the toolbars do not appear, but there are no error messages or notification bars. The add-ins display as loaded in the add-in manager, though, and it's possible to run macros manually from the VBA editor.
I've investigated issues with security settings and digital signatures. The add-ins are digitally signed, although the add-in manager does not display the publisher information. Users are prompted to trust the publisher when attempting to install the add-ins; trusting the publisher does not make the add-ins work and does not lead to any error messages.
In the add-ins tab of the trust center, the option to "Disable notification for unsigned add-ins" is checked and grayed out on the thick clients where the add-ins do not work, and unchecked on the thin clients where they do work. When checked on the thin clients, the add-ins continue to work, so I don't think this is the problem. And both deployments use the 32-bit version of office, so it's probably not that either.
Any ideas what might be causing the problem, and how to fix it?
I was having a similar problem, and the instructions for trusting publishers recorded on this website helped me to resolve the problem:
http://www.excelguru.ca/content.php?199-Security-In-Microsoft-Office
However, for mine to work I could not use the certificate created using the selfcert.exe program that comes with Microsoft Office.