Support manifest type choice for WXP

[Rick-Kirkham]

Not a bug. Enhancement request.

IT'S POSSIBLE THIS WILL BE CANCELLED, DEPENDING ON DECISIONS ABOUT HOW MUCH WE WANT TO INVEST IN KEEPING THE GENERATOR UP-TO-DATE WITH THE UNIFIED MANIFEST.

Please enable the manifest type choice if the user picks Excel, Word, or PowerPoint (not Project or OneNote). Same as we currently have for Outlook.

[millerds]

Requires support in WXP for json manifests. Will be added once that support is in public preview.

[yinhx3]

Requires support in WXP for json manifests. Will be added once that support is in public preview.

Is it possible to have a built-in JSON to XML conversion tool before then? This would be quite good for the development experience, considering that the Excel custom contextual tabs function is already using the JSON format. And after the launch of WXP for JSON manifests, we actually need such a tool to support existing versions for a long time.

[millerds]

Requires support in WXP for json manifests. Will be added once that support is in public preview.

Is it possible to have a built-in JSON to XML conversion tool before then? This would be quite good for the development experience, considering that the Excel custom contextual tabs function is already using the JSON format. And after the launch of WXP for JSON manifests, we actually need such a tool to support existing versions for a long time.

This is about the plug-in for yeoman the generates projects to make add-in (or office extensions as they are referred to in json manifests). It doesn't do any good to provide customers with a tool to generate projects and can't be used because the support isn't there in the hosts. Same is true for a JSON to XML conversion.

[yinhx3]

This is about the plug-in for yeoman the generates projects to make add-in (or office extensions as they are referred to in json manifests).

I know. This issue should be placed in https://github.com/OfficeDev/Office-Addin-Scripts. I comment here because there is already a related issue.

It doesn't do any good to provide customers with a tool to generate projects and can't be used because the support isn't there in the hosts.

To be honest, manifest.xml itself and its supporting tools are quite bad. Migrating to json can reduce inconsistencies and optimize the development experience. In web development, we use transpilers and polyfills to make the code adapt to old browsers, so that we will not give up new features because old browsers do not support them.

Same is true for a JSON to XML conversion.

What will happen after the launch of WXP for JSON manifests? Will the project need to include two manifest files?

[millerds]

The project will not need to include both manifest types unless that is what you want. If you look at the Outlook case that is already shipped, you'll find you can use just json or just xml. Ther service that shipped along with the changes to the Outlook client manages the json manifests directly and creates backwards compatible xml manifests that can feed the older clients (through exchange). It can also take the xml manifests, register them, and then pass it on to exchange to feed all the clients as well. There is also a mapping mechanism in the json manifests so the existing store xml manifests can be related to json manifest together. The WXP experience should be modeled after that.

[yinhx3]

Thanks for the explanation, I'm glad that one day I don't need to write manifest.xml anymore. Hopefully that day will come soon.

[Rick-Kirkham]

@millerds Somehow the plan for the UI of version 3.0 got past me. It looks like the following:

Having two entries that are identical except for the "(preview)" after one of them is confusing. Also, it doesn't convey what is in preview.

What I had in mind with the original issue description, is that the user would choose, say, the task pane project, and only after they choose either Excel, PPT, or Word, would they get a prompt to choose a type of manifest.

Alternatively, we could have the choice of manifest come after they've chosen the task pane project but before they've chosen an application. One problem with that design is that if they've chosen the unified manifest, we'd have to suppress the options for "OneNote" and "Project".

BTW, when they choose the application, we can have an additional option: "Combined Excel, PowerPoint, and Word" to support the template that combines all three.

[millerds]

How would you distinguish between the preview vs. not preview status of the unified vs. xml manifests if you don't have different entries? I always thought that having the different manifest options under the single template type will be the update once support for unified manifest in WXP is shipped and the template branches merged (remember they are separate branches to avoid breaking the main branch for existing template).

Restructuring the order of the questions would be a major change for generator office as internal data hierarchy would have to be reworked. You would still have the problem of needing to designate what is preview and what is shipped.

If you pick the preview template there is an option for "All" when you get to the host choice.

I think "preview" is the terminology we use in general to define things that are available to play with but not shipped. This is what we do in the main applications, but I guess there is more documentation on what is in preview even if it's not in WXP directly. The simplest thing is to update the strings to provide clarity on what is being previewed (unified manifest).