Building apps for SharePoint and Office 365

 

Update 6/10/2014: This post mentions autohosted apps for SharePoint. The autohosted apps for SharePoint preview program is now closed. For information about the closure of the program see Update on Autohosted Apps Preview Program. For instructions about how to convert an autohosted app to a provider-hosted app, see How to: Convert an autohosted app for SharePoint to a provider-hosted app.

This article is brought to you by Howard Crow, Principal Group Program Manager for SharePoint Developer Experience team. Thanks for reading us !

My name is Howard Crow, and I have been working on SharePoint since the beginning. I am now the Group Program Manager of the Developer Experience team. Today I finally get to tell you about what our team has been working on, which is a dramatic reinvention of the SharePoint and Office 365 developer platform.

We began planning SharePoint Server 2013 knowing that our move to the cloud was going to have a dramatic effect on the developer platform. The scale, security, resilience, and openness of the cloud would mean that we would need to rethink our architecture for the coming generation of apps. The challenge would be exacerbated by the fact that we needed a design that would benefit people who build solutions for both the cloud and our on-premises offerings and not be so different that our enormous ecosystem wouldn’t be able to transition easily. We did a lot of work in the new release, so this post will just be the beginning of the discussion!

Before I begin talking about the new, new thing, I would like to remind everyone of the post Brian Jones made and reiterate that your current solutions will keep working. However, the new model is definitely our big bet in this release. And we encourage developers to think about how to build a solution on this model first, as it provides the best user experiences and great benefits in terms of development and management for both developers and IT professionals. In many ways, the capabilities of the cloud app model are already well beyond that of the current solutions model, and in some ways it is more restrictive so we can work with the cloud. Many things will be done differently in the new model and we will need feedback to make sure all the legacy scenarios get covered. The new model is designed to solve a host of problems both on premises and in the cloud that were impossible to solve using the old architecture, and so we have made the bold change. We are dedicated to supporting our customers through this journey.

Our goals for the release were based on a huge amount of feedback we have received from our partner and developer community:

The Cloud

The software universe is moving to the cloud. Not just on the Internet, but inside companies as well. More than ever, Enterprise Central IT treats their SharePoint deployment like a cloud deployment. It is locked down with little access to business unit developers and partner apps for fear that they will trample each other. Deploying code to these central ”appliances” is difficult, if not impossible. At the same time, our distributed code model has matured tremendously. Windows Azure Web Sites, SQL Azure, and Windows Azure Workflow are powerful and flexible hosts for your custom logic and data. The Cloud App Model brings together the best of all these services. A critical investment to make this come true has been our declarative remote evening API. Our Integration with Windows Azure Workflow uses this feature, and you can too.

0-60

With the new model, it now takes less than 10 minutes to get to “Hello World”. You can write apps for SharePoint in ASP.NET, ASP.NET MVC, PHP, JavaScript, or whatever you want. SharePoint will even deploy, host, and life cycle your code in Windows Azure if you want—you don’t need to figure out a hosting plan. Or if you already have a service, you can reuse the logic you already have inside your app. Please read a Scott Guthrie’s article on Windows Azure and Office 365 integration.

The Store

With our new SharePoint Store and the App Catalog, customers can purchase directly from the Microsoft-managed Store, and IT organizations can manage a private App Catalog with control over licensing. The deeper implication here is that we now support a full life-cycle model, with updates and retractions. In addition, to protect the SharePoint system from attacks, we isolate the apps from the runtime with domain isolation and OAuth2. Empowered users with control for IT—the best of both worlds.

Devices

We now support a plethora of devices with our new APIs. Our choice to expose our interfaces through JavaScript and OData means that you now have libraries for all the major device makers–and some not so major ones. Importantly, the Cloud App Model doesn’t just support ”apps” sold through our Store. The APIs are more open than they ever have been, and they support server-to-server patterns as well as devices. Stay tuned for some future blog posts about this!

The Cloud App Model

For the first time, we have brought together all of Microsoft’s enterprise assets into a unified app model. We call it the Cloud App Model. The easiest way to describe this is to talk about the .app package and what it contains:

The .app package is a ”super-package” that contains all the elements of a modern multi-tier app in one package. This includes both server-side packages, such as the SQL DAC Pack, and client manifests for Office, which declare where an app for Office should appear in the client. You will learn more about the anatomy of an app for Office in our next article on this blog. None of the sub-elements are required for an app to deploy. You can mix and match. It’s like a SharePoint WSP +++.

The simplest scenario is an app that just links off to a webpage hosted on another web server. In this case, the .app is really nothing more than a URL in the manifest. At deploy time, SharePoint instantiates an app web with an iFrame that points to the URL (More on app webs later).

In the case of a very sophisticated app, you might have a SharePoint document library, SQL Server tables for complex relational data, custom coded workflows, and custom task panes in Word and Excel. The model, package, and life cycle will support all the derivatives.

Visual Studio 2012 supports these apps and can deploy them directly to the cloud and F5 remotely to Office 365:

In Solution Explorer, you will be able to see all the various sub-packages that make up the Cloud App Model and work with them as one solution.

At run time, the model builds on the work we did in SharePoint 2010, and it should feel familiar to folks who have worked with our OData and client object model (CSOM) interfaces. In the Cloud App Model, all coding is done remotely through the new interfaces. I will call out a few major changes we have done to enable this and make it as easy as possible for folks:

• We have implemented OAuth 2.0 in SharePoint and Office 365. We have covered almost every major API with OAuth. There are a couple of exceptions (Excel Services) that we could not get to in this release, but Lists, Social, Search, Workflow, etc… are all available.
• We have built a remote event handler system. You will declaratively register for events inside your WSP and then write code in Windows Azure to process the event. An obvious side effect of this is we don’t have fully synchronous events.
• We have updated our namespace, and all the APIs that are valid in the new model (and can be used in apps sold through the SharePoint Store) are prefaced by _API. The previous namespace of _vti_bin will remain to support former solutions. This should make it obvious what can be used when. The _API members will support new REST based grammar. CAML will be available for advanced queries, but is no longer the first option as OData syntax is becoming our standard.
• Every app for SharePoint gets its own app web. This app web is special because it gets its own domain, which allows us to isolate it from the rest of SharePoint. In order to maintain security, we don’t allow apps to put code in pages outside of the app web. If you would like to surface UI in other SharePoint sites, you will use declarative insertion points, notably App Web Parts, ribbon buttons and in-item menus. Over time, we will expand the available insertion points as we get feedback.

One thing to note is that your code can run on any back end. We just happen to really like Windows Azure, and will optimize our tooling and life cycle around it.

Hello World

Fundamentally, there are three app “patterns” for apps for SharePoint. When creating an app in Visual Studio, you will see them:

1. A SharePoint-hosted app – there are no external services or code. It is just an HTML page with JavaScript running in SharePoint.
2. An Autohosted app – you have custom code and a database. Office 365 manages the deployment and life cycle of your custom code inside Windows Azure. Each app instance (deployment) receives its own isolated runtime and database storage in Windows Azure. Microsoft Access 2013 builds this kind of app.
3. A Provider-hosted app – you are Yammer and would like to build an app for SharePoint but manage your own central service.

For a simple getting started example, I highly recommend this piece on our Developer Center: How to: Create a basic app for SharePoint by using "Napa" Office 365 Development Tools.

To learn more about “Napa” Office 365 Development Tools, I recommend “Introducing "Napa" - Office 365 Development Tools" article from Jason Zander. In the rest of my article, I will refer to “Napa” Office 365 Development Tools as just “Napa“.

The first step is to get a Free Developer Subscription on Office 365. Click here to get started ! This is a complete Office 365 Subscription that has everything you need to get started. It is currently limited to one user per tenancy. In particular after getting your subscription set up, you will want to navigate to your SharePoint Developer site. The URL will be paperdoll.sharepoint.com (where paperdoll is the name of the subscription you chose). Note that this is a full subscription and you will get email, the Office client, a public website and many other goodies.

The core of the developer tenancy is the Developer Site and the Developer Feature. The Developer Site is really just a SharePoint template that we use. The Developer Feature is more interesting, as it contains a key ability: the code that allows tools to side-load an app directly into the site from Visual Studio. We call this bundle of goodness “Remote Development” because it is the ability to hit F5 directly against our server and service. This allows you to build apps without having to install SharePoint and a whole host of DLLs to your machine.

In the developer site, click Get Tools to Build Apps. This takes you to the SharePoint Store – because “Napa” is actually an app. You use an app to build apps. Mind bending. In the developer site, click “Get Tools to Build Apps”. This takes you to the Store – because “Napa” is actually an app. You use an app to build apps. Mind bending.

Before Napa can be installed into your Office 365 tenancy, you will get the now familiar  prompt. Under the covers, the app will run with the intersection of the rights that the current user and the app have. All access and updates done by the app are also logged as “AppX running on behalf of HumanY”. In this particular case, Napa is installing and requesting access to the site it was installed in and no more. This will allow Napato deploy apps into the site as part of the F5 experience. In a future blog post, we will talk about tenant apps, which have broader rights and can only be installed by tenant administrators.

Note that “Napa” is actually a “provider-hosted app”. The Visual Studio team runs their own service where all the logic for “Napa” lives. The app has installed a subweb that provides the frame for “Napa”.

“Napa” is running ”inside” Office 365 and is actually inheriting the theme of the parent site (there is now a remote API for that). It is using the Office365 chrome control (the blue bar at the top). This allows users to remain in the same familiar user experience.

The default experience in “Napa” is a fully formed running app. You will see folders with script files and images, but you are ready to go. The IDE is stunningly rich, with autocomplete and other features you wouldn’t necessarily expect in the browser. The default experience in Napa is a fully formed running app. You will see folders with script files and images, but you are ready to go. The IDE is stunningly rich, with autocomplete and other features you wouldn’t necessarily expect in the browser.

I can't just leave it alone, so I add the text “Hello World” to the default app in the App.js file.

At this point I could open the app in full Visual Studio, but I need instant gratification and want to run directly from the browser.

I hit the Run project button. This is the moral equivalent of hitting F5 in the full Visual Studio Suite. Sadly, F5 was already taken.

This packages up the .app file and pushes it into the SharePoint Developer Site. It is doing this remotely, from service to service. In the case of Visual Studio Professional, it would be doing F5 remotely from your desktop. In order to make this fast, we have done datacenter colocation planning with Windows Azure and SQL Azure to ensure that during the deployment phase there are minimal delays and bandwidth consumption. We can now launch the deployed app…

Now, how to publish apps to users?

You have two options to publish apps to users. An app can be published into the new SharePoint Store via a Seller Dashboard. A validation process handled by Microsoft will ensure that apps available on the Store are secure and conform to the description. We will talk more about the Store in future posts.

In some cases you will want to get into the App catalog, which is the internal marketplace IT organizations can run:

The App Catalog came through as a pretty huge ask from our customers. The underlying design is pretty simple – it’s a SharePoint List. This means you can add metadata, create approval workflows and do all the great things you can do on list items – but on apps! This includes apps built with Access.

Come with us

Whew, we have been pretty busy for the past few years. Sorry for the long first blog, but I wanted to scratch the surface of the new areas so you would know what to look for while exploring. We will have a lot more posts with more detail on various areas.

Please build apps, and keep the feedback flowing, we just began the new model and are really looking forward to hear back from you. Your feedback is essential to building our platform in a way that supports your apps and services.

We are on a journey to the cloud, come with us!

- Howard

Comments

• Anonymous
  August 07, 2012
  Fantastic article and very valuable information too :) Thanks for sharing !!

• Anonymous
  August 07, 2012
  Glad you liked it Amol. Do give Apps for SharePoint and try and let us know if you have any feedback. There is a contest going on now so you can even have a chance to win some cool prizes and get your app featured.  http://dev.office.com.

• Anonymous
  August 27, 2012
  "In the developer site, click Get Tools to Build Apps. This takes you to the SharePoint Store – because “Napa” is actually an app. You use an app to build apps. Mind bending. In the developer site, click “Get Tools to Build Apps”. This takes you to the Store – because “Napa” is actually an app. You use an app to build apps. Mind bending." ================ Truly mindbending...

• Anonymous
  November 24, 2012
  Hi How can I make visual studio to just update my app and dont create new app site. I want to keep my list data and nearly after every deploy it keeps recreating my app with empty lists. I have already disabled retract after debug option but still no luck. I am running on sharepoint.com cloud. Thanks Martin

• Anonymous
  June 14, 2013
  Fantastic web page loved the content articles keep up the great work

• Anonymous
  July 25, 2013
  its very useful

• Anonymous
  December 05, 2013
  I have a php application that i have which uses Oracle as a database. But I want to know how I can add it on our SharePoint site and run it from there.

• Anonymous
  January 16, 2014
  Thank you. It was very useful and user-friendly

• Anonymous
  February 11, 2014
  Thank you. It was a Nice and Useful Article.

• Anonymous
  October 27, 2014
  Very useful article, one question is there a way to use third party dlls in Office 365, I have used a dll that I load to bin of SharePoint root directory but how will I achieve this in Office 365? Appreciate your help. Thanks, Gurdeep