Apps for Office: Publishing and Distribution

We close out the series on developing Apps for Office by reviewing the different publishing options available for distributing your apps. Although the most likely scenario is publicly distributing a completed app, there may be situations where you want to limit access, such as for testing and internal use. We’ll look at the different options available to the different app types.

We’ve already seen how Visual Studio simulates distribution to enable debugging, but this is only intended for local development. For actual publication of the app, there are four general options:

• Office Store – This is the official public collection of applications managed by Microsoft for Office, allowing you to list both free and paid packages for purchase by consumers from the marketplace.
• Organizational App Catalog – This is also a repository for listing applications, but their distribution is limited to users within the Organization via its SharePoint tenancy.
• Shared Network Folder – A public folder on a network share can be configured as a private catalog.
• Exchange Server – Mail apps specifically must be installed into an Exchange Server for use by Outlook.

App Hosting and Deployment

Regardless of the hosting option you choose, one additional consideration when publishing your app is where the app itself will be hosted. Although you are of course free to use any hosting solution of your choosing, Apps for Office is clearly designed to give you the best experience when using Azure.

In fact, you can deploy from the One-Click Publish option in Visual Studio directly to Azure.

This step can also be executed from the Publish option of the App Project itself, which presents additional helpful tools such as a validation check.

Once your app website is live, select the option to “Package the app”, which prompts you for the live URL, and finally updates and packages the manifest which you’ll use to upload and publish to the Store.

Now that we’ve seen how the app website is published, we can review the different options for listing the manifest for use by others.

Submitting Apps to the Office Store

If you intend to distribute your application to the general public, you should submit it for listing in the official Office Store. The store conveniently lists apps both by type as well as by the Office application they target, helping users find your app more easily.

As mentioned previously, apps in the store can be either free or paid. However, regardless of the option, before you can list an app you must first create and register a Seller Account, which can be either for an Individual or a Company; be sure to select the appropriate option when registering or there may be delays in processing the account.

Seller Accounts are meticulously vetted, so pay careful attention to the approval process instructions, as well as this handy checklist for creating a Seller Account or you may once again experience delays.

Once your account is approved, you can proceed to submit your app to the Store. Apps are also thoroughly reviewed, but there is a checklist for app store submission that can help streamline the experience. One key thing to remember is that the information you submit via the dashboard should exactly match the information listed in your app manifest, including the name and version number.

Another tip is that screenshots must have file extension .png, jpg, .jpeg, or .gif, must be exactly 512 pixels wide and 384 pixels high, and be no larger than 300 KB.

You can also specify the pricing model for your app during submission, either free, a one-time fee, or an ongoing subscription:

When your app is approved by the Office Store team, it will be available for install via the Office Ribbon of the Office applications for which it was created.

Deploying to Your Organization Catalog

If you need to distribute an app for use by your organization, but not by the general public, you can leverage your organizations SharePoint tenancy for publishing. SharePoint administration is outside the scope of this series, however there are helpful documentation articles for both setting up SharePoint and SharePoint Online with App Catalogs to list the apps.

Once the App Catalog is configured, you can use it to publish both Task Pane and Content Apps. These apps will then be available to Office applications via the same Office Ribbon as Store apps, but are instead listed under the “My Organization” section when you are logged in.

In this example below I am logged in to Office with my work credentials, and can see our internal app catalog, which we used for testing different versions of the EventBoard apps.

Office 365 Small Business

If you are using Office 365 Small Business, you already have an App Catalog installed. For more information take a look at this quick tip from Jason Follas: Office 365 Small Business: Where’s the App Catalog?

Deploying to a Network Share

So far the options we’ve reviewed are designed to reach larger audiences such as an entire organization or the general public. If you are developing something that has a small, targeted list of users who happen to be on the same network, you can leverage a shared folder to distribute your application.

The option to add a catalog is location within the Trust Center of the application, shown here for Excel.

Specify the network path to the shared folder, and select the option for “Show in Menu” to enable it. Note that although you can point to multiple catalogs of different types, only one of each type can currently be enabled at a time.

You can now distribute the app manifest file to this folder. Once you restart the Office application, you’ll have access to a new catalog called “Shared Folder” form which you can install the apps from the manifests that were placed there.

It’s important to reiterate the fact that this must be a network share, not a local file path. In addition, this same catalog must be manually be registered (and of course, accessible) by all individuals who intend to access these apps.

This is an excellent way to test your apps with other users outside of your immediate development environment before publishing to a public or organizational store.

Deploying Mail Apps to Exchange

The last option for publication is specifically for Mail Apps, which must be deployed to Exchange. As a result, these apps are best published by uploading directly to the Apps for Office Store as shown in the first option above, since they will be made available to all Outlook users.

However, it is also possible to install and test apps by manually publishing to an Exchange Server. This task must be completed by an Exchange administrator, and is outside the scope of this series. However, documentation for this is available here: Deploy and install mail apps for testing in Outlook

Wrapping Up the Apps for Office Series

Over the past few weeks we’ve taken a peek at how Apps for Office can help you extend and enhance Microsoft Office applications. Task Pane apps let you present a helpful interactive sidebar, while Content apps let your users show and manipulate content directly within their documents. Mail Apps provide the same rich extensibility to messages and appointments, with special activation rules so that they are only presented when it makes sense to the user.

Regardless of the type of app, your Apps for Office can be built with any modern web technology, unlocking endless potential for interaction and productivity. These apps are served via any webserver technology, embedded directly within the app, and interact with your live documents through robust and powerful JavaScript API.

Finally, they can be published in a wide variety of ways, from simple local development to internal networks and organizations, to the full general public where your apps can be sold to generate a profit.

All the while, Microsoft continues to expand and improve the Office developer experience. As a result, I encourage you to watch the Office Developer Center for the latest news, features, changes, and events that can help you take your Office development to the next level.

As 2014 winds to a close along with this series, I look forward to seeing and sharing what develops throughout the next year. Until then, as always, thank you for reading, and I hope this was helpful!