Outlook Web Add-in清单添加Events扩展点后触发‘Invalid xsi:type=Event’错误
Let’s break down how to resolve this issue step by step—this is a common gotcha with Outlook add-in manifest structure, especially when working with event-based extensions like ItemSend.
Why You’re Seeing the Error
The Invalid xsi:type=Event error happens because the Events extension point isn’t placed correctly in the manifest. Outlook requires event handlers to be nested within VersionOverrides blocks (specifically VersionOverridesV1_1 for modern clients), rather than directly in the base manifest. Adding a top-level VersionOverrides tag is the right first step, but improper nesting or missing namespace declarations often cause follow-up compile issues.
Step 1: Correct Manifest Structure
Here’s the proper way to embed the ItemSend event in your manifest, with all required namespace and nesting rules:
<?xml version="1.0" encoding="UTF-8"?> <OfficeApp xmlns="http://schemas.microsoft.com/office/appforoffice/1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:bt="http://schemas.microsoft.com/office/officeappbasictypes/1.0" xsi:type="MailApp"> <!-- Your base manifest config (ID, name, version, permissions, etc.) --> <VersionOverrides xmlns="http://schemas.microsoft.com/office/mailappversionoverrides" xsi:type="VersionOverridesV1_0"> <VersionOverrides xmlns="http://schemas.microsoft.com/office/mailappversionoverrides/1.1" xsi:type="VersionOverridesV1_1"> <Hosts> <Host xsi:type="MailHost"> <DesktopFormFactor> <!-- Add other extension points (like CommandSurface) here if needed --> <ExtensionPoints> <ExtensionPoint xsi:type="Events"> <Event Type="ItemSend" FunctionExecution="synchronous" FunctionName="validateBody" /> </ExtensionPoint> </ExtensionPoints> </DesktopFormFactor> </Host> </Hosts> </VersionOverrides> </VersionOverrides> </OfficeApp>
Key things to note:
- The
Eventsextension point lives insideVersionOverridesV1_1→Hosts→MailHost→DesktopFormFactor→ExtensionPoints. - Ensure the root
OfficeApptag includes thexsinamespace (xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"), which is required for validatingxsi:typeattributes.
Step 2: Troubleshoot Compilation Issues
If adding the correct VersionOverrides structure breaks compilation, check these common culprits:
XML Syntax Errors
- Double-check for unclosed tags, typos in attribute names (e.g.,
FunctionExectuioninstead ofFunctionExecution), or missing quotes around values. - Use an XML validator (many code editors have built-in tools) to catch syntax issues.
- Double-check for unclosed tags, typos in attribute names (e.g.,
Missing Function Implementation
- Confirm the
validateBodyfunction exists in your specified JavaScript file (usuallycommands.jsfor Yeoman-generated projects) and has the correct signature:function validateBody(event) { // Your validation logic goes here const mailboxItem = Office.context.mailbox.item; // Example: Check if body contains forbidden text mailboxItem.body.getAsync("text", (asyncResult) => { if (asyncResult.status === Office.AsyncResultStatus.Succeeded) { if (asyncResult.value.includes("confidential")) { event.completed({ allowEvent: false }); // Block send } else { event.completed({ allowEvent: true }); // Allow send } } else { event.completed({ allowEvent: true }); // Fallback to allow send } }); } - Even though the manifest specifies
synchronous, Outlook Web Add-ins require you to callevent.completed()to signal the end of your validation logic.
- Confirm the
Manifest Validation Failures
- If you’re using the Yeoman Outlook Add-in template, run
npm run validateto check for manifest compliance with Office’s schema. - For manual builds, use the Office Add-in Manifest Validator tool to catch schema violations.
- If you’re using the Yeoman Outlook Add-in template, run
Final Checks
- Ensure your add-in’s permissions include
ReadWriteItem(required to access the email body duringItemSend). - Test the add-in in Outlook Web App to confirm the
ItemSendtrigger works as expected.
内容的提问来源于stack exchange,提问作者Jaydev Solanki




