I have been building a small App for Office during the weekend. My App is a MailApp for outlook and it was super easy to build, as it is all html and javascript and a few calls to a rest service. But man getting the App production ready and publish it to the Office Store is a whole different story, which I will explain in more detail in another post, here I just want to share the solution to the first problem you might face when you try to publish an app.
For the App Manifest to be valid to go into the Office store basically all settings on the General tab on the settings page must be filled out.
Easy you might say. Well that depends on the order you fill out the information. If you like me fill in the Icon Url last you will end up with a solution that will have build errors like this:
The element 'OfficeApp' in namespace 'http://schemas.microsoft.com/office/appforoffice/1.0' has invalid child element 'IconUrl' in namespace 'http://schemas.microsoft.com/office/appforoffice/1.0'. List of possible elements expected: 'AppDomains, VersionOverrides, Capabilities' in namespace 'http://schemas.microsoft.com/office/appforoffice/1.0'. c:\users\simon pedersen\documents\visual studio 2013\Projects\OfficeApp1\OfficeApp1\OfficeApp1Manifest\OfficeApp1.xml
I will give you the solution first and then talk about how I figured this out. The solution is simple, you have to ensure that the xml nodes within the
[xml]
<?xml version="1.0" encoding="UTF-8"?>
<!–Created:cb85b80c-f585-40ff-8bfc-12ff4d0e34a9–>
<OfficeApp xmlns="http://schemas.microsoft.com/office/appforoffice/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="MailApp">
<Id>85962a5d-e143-42c4-b0bd-bb5631b27998</Id>
<Version>1.0.0.0</Version>
<ProviderName>Simon Pedersen</ProviderName>
<DefaultLocale>en-US</DefaultLocale>
<DisplayName DefaultValue="OfficeApp1" />
<Description DefaultValue="OfficeApp1"/>
<IconUrl DefaultValue="~remoteAppUrl/Images/icon.png" />
<SupportUrl DefaultValue="~remoteAppUrl/App/Home/Home.html" />
<Capabilities>
<Capability Name="Mailbox" />
</Capabilities>
<DesktopSettings>
<SourceLocation DefaultValue="~remoteAppUrl/App/Home/Home.html" />
<RequestedHeight>250</RequestedHeight>
</DesktopSettings>
<Permissions>ReadItem</Permissions>
<Rule xsi:type="RuleCollection" Mode="Or">
<Rule xsi:type="ItemIs" ItemType="Message"/>
</Rule>
</OfficeApp>
[/xml]
My initial thought when I first encountered this error was, well they probably shipped the wrong xsd schema with Visual Studio 2013. So I first opened the XML manifest file, from the top ribbon I selected XML > Schemas, which brings up this window if you are not familiar with it
in the dialog I looked for the namespace http://schemas.microsoft.com/office/appforoffice/1.0 and found that the xsd schema was defined in C:\Program Files (x86)\Microsoft Visual Studio 12.0\Xml\Schemas\1033\offappmanifest.xsd. So I checked out the xsd schema to see if anything was missing, and to my surprise found that everything looked to be correct (no missing IconUrl). If I had looked more closely at the schema definition, I would have seen that the ComplexType named OfficeApp had its child elements wrapped in a sequence element which means that they have to be in the order specified in the xsd, but I didn’t pay attention to this detail at the time.
So in my quest to figure out what was wrong, I jumped in to Visual Studio Options and turned up “MSBuild project build output verbosity” to Diagnostics so I could get some more information from the build process. This helped me identify which build target that was being used.
It was the task ValidateOfficeAppManifest in the PerformManifestValidation target located in C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\SharePointTools\Microsoft.VisualStudio.SharePoint.targets that failed on me. Opening up Microsoft.VisualStudio.SharePoint.targets I could see that the task ValidateOfficeAppManifest pointed to an assembly Microsoft.VisualStudio.SharePoint.Tasks.dll.
[xml][/xml]
[xml][/xml]
Luckily this assembly was not obfuscated (Most MS code is not), so I peeked inside it with dotPeek, and was able to get an understanding of what failed. I reproduced the failing code in a little test project that I have uploaded to github.
When I was able to run this test, then it became clear to me that it was the order of the elements that was messing my build up. Very annoying to spend time on a simple tooling error like this.