I felt compelled to write this series after I downloaded the sample office apps from MSDN (all of them) and descended into the 7th level of hell trying to get it to work. The goal was to create an office apps to implement a Word task pane app to allow insertions of bindings, pushing bindings/tags to a SPS 2013 List, and access the SPS taxonomy to allow for tagging of bindings within a Word document. Seems simple enough. I had a pile of samples, a mess of MSDN and TechNet links, I was ready to go or so I thought.
There is actually a good deal of documentation on the Apps for Office, some good MSDN samples, and some great videos. You can certainly go through these and get a pretty good base level of knowledge on Apps for Office. When you take it to a complex solution though, you quickly find some serious gaps which hopefully will be plugged and render this post pointless. This is especially true when your intention is to self-host your apps and use a local app catalog for the manifest. This series is about the gaps I encountered which hopefully will help someone else out.
As I state throughout this series, I am really in the midst of ramping into this area and even through the course of the project the documentation has been changing. So please chime in if you have any additional info to share or questions.
Clarification on terminology
So before I go too far, I want to clarify a couple things on the terms I use. There are 2 parts to a deployment. First, you are pushing your manifest to a catalog. Second, you are deploying the actual app functionality somewhere. When I refer to deployment in this series, I am referring to the deployment of the functionality not the manifest. I will specifically call out the manifest deployment when that is what I am referring to.
Hope you like client side code
Additionally, client side code is blocked from doing most modifications to the local machine. It runs in its own special little area, and is tightly controlled from what it can do to protect people from malicious code. This plays a large role in the architecture you decide to use for your application and how you code it.
Not just client side code
So the good news for server side coders, as I mentioned, the office app is a web site. So that means, you can code it as an ASP.Net site, and enjoy all the wonders of server side code as well. The solution we wrote did in fact use a god deal of C# code to make some calls and save some information. Also, for the types of calls we needed to make, a server side web service call to SharePoint was needed. So you do not need to have server code but you can have it if there is a need. Another good reason may be to run confidential business logic. That way, you are not exposing it through client side code.
Understand the model
There is a way around the missing Sp.Js and SharePoint context. I found a solution in MSDN that had a task pane app embedded in a SharePoint app. This gave me the ability to simplify the deployment, to get access to the SP.Js and all its references, to capture SPS Context info on the client side and do some real easy coding. However, it does deploy to an App tenant in SPS 2013, and there are implications to that. Additionally, when you do this, it is only going to allow client side code. This may not matter, but bear it in mind.
Plan your deployment
While coming up with the design know how you intend to deploy this app. Will it be hosted in SPS? Will it be part of an SPS App? Will it be on an IIS server? Azure? This decision can have a very big impact on what is possible. As an example, if I am deploying to a SharePoint App, or to a SharePoint site, I am deploying typically client side code only. Meaning no compiled dlls, but my code will have access to SP context on the client and Sp.js. If I am going to IIS Server, I will be able to code whatever I want on the backend/server side, I will not have direct access to SP context or SP.Js (assuming I care for this app).
For each deployment model I will also need to consider security and user context unique to that situation as well as infrastructure considerations, firewall rules, etc.
Testing can be painful
- Apps for Office Training videos – http://msdn.microsoft.com/en-US/office/dn448488
- Apps for Office Samples – http://code.msdn.microsoft.com/office/Apps-for-Office-code-d04762b7
- How to: Create an app for SharePoint that contains a document template and a task pane app – http://msdn.microsoft.com/library/office/fp179815.aspx
- Fiddler – http://fiddler2.com/