I was trying to find a way to publish an outlook add in to office store.
But I found out that we can publish only office apps and not the add ins to the office store.
Hence I wanted to know what is the difference between an office app and an office add in?
And is there an easy way to convert an already built add in to an app?
Or will I have to implement the functionality all over again, while developing the app?
Hence I wanted to know what is the difference between an office app and an office add in?
Not so long ago (at #build2015) MS named Office Apps as "add-ins" as well. Classic Office add-ins are based on the IDTExtensibility2 interface (COM). They can't be run on any device or web browser. Office COM add-ins are for the desktop editions of MS Office (x86 and x64). COM add-ins can be implemented using a wide range of programming languages: from unmanaged C++ or Delphi to managed ones (C#, VB.NET and etc.). On the opposite side Office Apps (also called as add-ins now) are a small web based applications (HTML, CSS, JS) that have a limited access to the object model (typically related to the selection or opened item).
And is there an easy way to convert an already built add in to an app?
No, they are entirely different type of applications.
Or will I have to implement the functionality all over again, while developing the app?
Yes, you need to develop an Office App from the ground.
It is not lear what Office application you are talking about, but in case of Outlook you may find the Selecting an API or technology for developing solutions for Outlook 2013 article in MSDN helpful.
Sorry for the confusion. "Add-in" is just the new name for "App". So, you should be able to publish your add-in (built using HTML and JavaScript) to the Store. This is different from the really old COM add-ins.
Related
All the questions/answers I have seen so far are old and do not provide a definitive answer.
Also what can I use locally and what can I use online?
what can I use locally and what can I use online?
You may use your VSTO and VBA add-ins for Office Desktop application on Windows.
Office applications on Web (online) has extensibility via Office.js API. Microsoft current name is "Office Add-ins", you may try them by loading into your Office application (excel) from Office Store. If you want to develop add-in based on this technology I would suggest to start over here: Office Add-ins platform overview. The conception behind of this technology is "build once, use everywhere where Office runs". That means your add-in may work for Office Desktop on Windows, Office Desktop on Mac, Online versions as well as some mobile platforms (subject to availability)
I want to create an Office Add-In with some HTML + JavaScript for sell in Office Store. And this add-in no need using any server side facilities.
But if I understood https://dev.office.com/getting-started/addins the source files of Add-in must hosted on some Web server.
So main question: can I somehow pack all sources and all resources of Add-in to the output DLL file and push to Office Store only the Manifest and DLL files without any web servers?
I need this for allow users from Office Store, install this Add-in to his Office and let work with it even offline (without internet connection).
Also such configuration a little complicate for reverse Add-in, if someone decide steal my sources and create duplicate of Add-in.
No, it is not possible because office add-in have to be located somewhere. When the user "installs" a web based office addin, in reality he just subscribes to a server where the addin is hosted. Microsoft doesn't host the dlls, (i.e they don't provide a server to run your dll), they just establish a link between the final user and your server via the office store and provide an API to ease interaction.
If you want to build an add-in that can be completely offline, you should look VSTO addins, XLA addin , XLL addins or COM addins. However none of these addins can be published on the office store.
It has been possible to use appcache to make offline webapp add-ins for office 2013 (https://code.msdn.microsoft.com/office/Apps-for-Office-Enable-bdcb7a2f).
Its unclear whether this works with newer versions of Office.
This is definitely not possible via the Office Store.
I have a .net solution for converting word/excel to pdf developed in MS Visual Studio .Net 2003.I added references i.e., Microsoft.Office.Interop.Excel, Microsoft.Office.Interop.Word in my project. It is working fine in my local system where MS Office is installed but when I tried to execute in the server where MS Office is not installed, I face some Class ID errors 00024500-0000-0000-c000-000000000046 and 000209FF-0000-0000-c000-000000000046 with respect to Word and excel. So i told my client to install MS Office on server but he wants me to use Office runtime 2010 to convert MS office documents? So what is office runtime actually? Was it helpful in my case? Does MS Office installation is required if I am using VSTO?
I am new here. Kindly help.
Thanks,
Praveen.
There is no "Office runtime".
I added references i.e., Microsoft.Office.Interop.Excel, Microsoft.Office.Interop.Word in my project.
Interop assemblies are used to marshal your calls into unmanaged environment. There is no actual COM servers installed that may handle your calls (i.e. no endpoints).
Anyway, Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. You can read more about that in the Considerations for server-side Automation of Office article.
If you deal only with open XML documents you can use the Open XML SDK. See Welcome to the Open XML SDK 2.5 for Office for more information.
But if you need to deal with binary file formats you have to look for third-party components that are designed for the server-side execution.
Is it possible to use interop dll from Office 2013 in Sharepoint 2010 solutions? I need to use excel in my Sharepoint solution, but on server was installed Office 2013 and i cant chose Microsoft.Office.Interop.Excel.
Thanks a lot
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
You can read more about that in the Considerations for server-side Automation of Office article.
Consider using Open XML SDK or any other third-party components instead.
As there is a drastic change in architecture from SharePoint 2010 to 2013, I would like to know what are the restrictions for a developer while developing Solutions/Apps for Office 365.
In SharePoint 2010, only sandbox solutions were allowed on Office 365, but in SharePoint 2013 the sandbox solutions are depreciated and App model is introduced. Would be glad if someone can throw some light on what is allowed and what is restricted on Office 365 in the new 2013 environment.
Sharepoint 2013 is a game changer, starting with the fact now is possible to use framework 4.5 and, since the new release of visual studio 2013, it's possible to use MVC. From a developing point of view you have to know there are two flavors:
Sharepoint hosted. In this case, your whole application is installed within the Microsoft servers. Because of this, you MUST use client object model and javascript. No server code at all. So you will configure your sites, libraries, lists, etc with 365 and then access this information using the Sharepoint javascripts libraries. If you are familiar with js ans sp js the you won't have any problem.
Autohosted. In this case you can choose between azure or your hosting (provider hosted) in both cases you can use a more traditional aproach, with your server code, classes, aspx and so on. The difference is when you deploy your application, in this case the app is installed just as a reference in 365 and all the code in your hosting provider. In fact all your application will be displayed in 365 within an iframe. Keep in mind you will be dealing with lots of cross domain scripting.
Last but not least, you have one final flavor, but it's not 365, Sharepoin onpremise, in this case this is your own sharepoint, you create, manager, develop or deploy whatever you want. This is very similar to the current sp2010 model, so, I guess you already now what you can do.
For more information:
http://msdn.microsoft.com/en-us/library/office/apps/fp179930.aspx
http://blogs.msdn.com/b/amigan/archive/2012/12/10/part-2-introduction-to-sharepoint-2013-app-model.aspx