Important developer changes from Office and SharePoint 2013 Preview to Office and SharePoint 2013
This post is brought to you by the Office and SharePoint Product and Content Publishing Teams.
One of the great things about the Office and SharePoint 2013 Preview is that it gives developers an early chance to play with the code and jumpstart developing apps and solutions. Some things have changed from the Preview, so there are some things to keep in mind as you update your apps and solutions to work with release versions of Office and SharePoint 2013. We wanted to publish a list of these changes as early as possible, so you can take them into account now.
Changes from Office 2013 Preview to Office 2013
The following are the Preview to RTM changes for Office 2013.
API changes from Office 2013 Preview
The Document.getAllContentAsync method has been deprecated and will be removed.
The getAllContentAsync method has been replaced by the new Document.getFileAsync method and the associated File and Slice objects. The Document.getFileAsync method, the associated File and Slice objects, and task pane apps in PowerPoint 2013 are not supported in Office 2013 Preview. To use these features, you must be running the RTM version of Microsoft Office 2013 (15.0.4420.1017 or later).
Apps that use the getAllContentAsync method should nowuse the new getFileAsync method as described in the Converting code from getAllContentAsync to getFileAsync section of Release notes for apps for Office. For more information about using the getFileAsync method, see How to: Get the whole document from an app for PowerPoint.
The API change is not supported in Office 2013 Preview and is not included in the pre-release version of Office.js. It will be included in the final Office.js, whose CDN will be published later in November. We've attached the release version of Office.js to this blog post so that you can test your apps now, just be sure you use Office 2013 RTM. Update: The Office.js CDN has gone live, here is a link to it .
Changes from SharePoint 2013 Preview to SharePoint 2013
The following are the Preview to RTM changes for SharePoint 2013.
The AccessToken header and property of SPRemoteEventProperties are now called ContextToken
For clarity, we have changed the name of the AccessToken header and property in SharePoint 2013 Preview to ContextToken in SharePoint 2013. If you have created an app for SharePoint that reads either the AccessToken header or property, you will need to update it to read the ContextToken header or property.
To create an app for SharePoint that works in SharePoint 2013 Preview and continues to work in SharePoint 2013, code your app to read both the AccessToken and ContextToken to determine which contains the context token value.
When using the SharePoint REST service, you must now specify that OData = verbose in the appropriate HTTP headers
The SharePoint REST web service uses OData V3 protocol syntax. To stay compliant with changes in the OData V3 protocol, when your app generates REST requests against SharePoint, you must now specify “OData = verbose” in the appropriate HTTP headers.
Specifically, this means:
- For GET and POST requests, include an Accept header as "application/json;odata=verbose, */*"
- For a POST request where you are sending JSON content in the request body, specify the content-type header as "application/json;odata=verbose"
The SharePoint REST service currently only supports the JSON verbose format; the JSON Light format is not supported.
Your app will fail to install if its supported language is not available on the SharePoint installation
If your app specifies supported languages or supported locales, then your app may fail to install if none of those languages are included in the server language packs installed on the SharePoint installation.
Note that this is not an issue with apps installed to SharePoint Online, as all language packs have been installed there.
Locale support information is required for all apps in the SharePoint Store, and is now specified in the <SupportedLocales> manifest element
You are required to specify which locales are supported by your app for SharePoint, or your app will not be accepted by the SharePoint Store. In SharePoint 2013 Preview, you specified this information using the <SupportedLanguages> element. In SharePoint 2013, use the <SupportedLocales> manifest element.
The <Properties> element of the app manifest must always contain a child element that identifies the locales that the app supports. For the final release version of SharePoint 2013, the element is <SupportedLocales> and it must have a <SupportedLocale> child for every locale that the app supports, even if there is just one locale.
The <SupportedLanguages> element will continue to work even on the release version for some time, but it is deprecated in favor of <SupportedLocales>, so on new apps you should always use <SupportedLocales>. And if you have a reason to update an app that uses <SupportedLanguages>, we recommend that you switch to <SupportedLocales> as part of the update.
Updated (March, 12th 2013): Your app will fail to publish to the Office Store if it has more than 25 SupportedLocales declared in the app manifest.
For more information, see the blog post Locale support information is required for all apps in the SharePoint Store.
The value that the {Language} token resolves to has changed format
For consistency with other SharePoint properties, the {Language} token now resolves to “en-US” (or corresponding ll-CC value) in SharePoint 2013, not the “en-us” value it resolved to in SharePoint 2013 Preview.
If your app instance had install/upgrade/uninstall errors in SharePoint 2013 Preview before upgrade, the Details page will not initially display in SharePoint 2013
In SharePoint 2013, the Details page for that instance will not display for any app that had a current install/upgrade/uninstall error in SharePoint 2013 Preview before it was upgraded to SharePoint 2013. This is true until the problematic operation is retried, such as by choosing the “retry” link on the instance on the Site Contents page, or until another appropriate action is taken such as an update or uninstall. In other words, any lifecycle operation will reset the errors, and after that the page should render properly.
Your app should not require a direct dependency on Excel Services
Excel Service is no longer included as a capability an app for SharePoint can depend on. If your app specifies an Excel Services capability ID as a prerequisite, the prerequisite checking operation will fail and your app will be blocked from installation.
Note that this will not affect currently installed apps, but only new purchases or installations.
For SharePoint workflows, the default workflow tasks list template id has changed from 151 to 171
When you add a workflow to an app project, you have the option of having a default workflow tasks list added to the app package. For SharePoint 2013 Preview, the list template id of this default workflow tasks list was 151; for SharePoint 2013, it is 171. If your app package contains a workflow built using SharePoint 2013 Preview, and it contains a default task list, then the app will not work in SharePoint 2013.
To solve this issue, change the TemplateType attribute of the default workflow tasks list to 171. For example:
<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="https://schemas.microsoft.com/sharepoint/">
<ListInstance
FeatureId="{f9ce21f8-f437-4f7e-8bc6-946378c850f0}"
TemplateType="171"
Title="WorkflowTaskList"
Description="This list instance is used for workflow Task items."
Url="WorkflowTaskList"
RootWebOnly="FALSE" />
</Elements>
For SharePoint workflows, workflows and other files deployed as list items cannot be packaged in the same feature definition
If your SharePoint 2013 Preview app package contains workflow files and non-workflow files, deployed as list items under a common <Feature>, app installation will fail on SharePoint 2013.
To resolve this issue, add a new <Feature> item to the app project. Move your workflows from the existing common feature to the new <Feature> in the same project.
The Help icon in the app chrome control does not display
If you have specified a help URL when using the chrome control in your app, the icon itself will not be displayed. The UI area where the icon would be remains, and will take users to the specified help URL if chosen.
Your app can no longer call into selfservicecreate.aspx
Apps are now blocked from calling into Selfservicecreate.aspx.