Outlook Web Add-in Blazor Example for OnMessageSend Event

[CraigCallender]

Question
(asked on stackoverflow, but was directed to ask here)

I've seen and followed the sample for creating an Outlook Web Add-in using Blazor for a TaskPane add-in. I've tried adapting it to work with the OnMessageSend event of web add-ins. I've hit a wall though trying to get it to load. From what I can tell, the main difference between a TaskPane and OnMessageSend add-in that stops this from working is that a TaskPane add-in requires an HTML endpoint to be invoked/called and the OnMessageSend add-in requires a JavaScript function. But there doesn't seem to be a way with a Blazor app to make the entry point a javascript function (it has to be a web page being loaded)?

Am I missing something obvious that would enable a web add-in targeting the OnMessageSend feature to use Blazor or WASM?

Thanks!

[davidchesnut]

Hi @CorithMalin82,

Unfortunately, I don't think this scenario will work. When Outlook on Windows launches your code to handle an event it uses a plain JavaScript engine. There's no UI or browser runtime, which likely Blazor WebAssembly would expect.

It's possible it might work in Outlook on the browser. In that case Outlook will use the browser to run your event code. Have you tried that scenario?

@aafvstam do you have any ideas here?

Thanks!
David

[CraigCallender]

Hi @davidchesnut,
We were testing in the browser and on Windows Desktop with Outlook 365. Both would work with a TaskPane but neither would work when trying to use the OnMessageSend feature. I suspect you're right on about the UI or browser runtime, as the issue we've encountered is an inability to get the blazor app to load because it seems it's never being hit.

Do you know if Blazor apps for the OnMessageSend feature are in the works? It would enable my company to drastically speed up the processing of our web add-in as right now we end up having to do the processing remotely using the GraphAPI instead of locally via JavaScript. It would also save us compute resources as we could do our processing on the client's computer instead of in our clouse services.

Thanks for your thoughts and comments.

[davidchesnut]

Hi @CorithMalin82, thanks for sharing your scenario. I found this documentation on Blazor webassembly which I think confirms it is dependent on a DOM (from diagram and descriptions). I know the JS Runtime used for Outlook events doesn't have a DOM. I do have a question out to the Blazor team to see if there is any workaround, and will post an update if I find anything. Unfortunately for now, I don't think it's possible.

[CraigCallender]

@davidchesnut - Just wanted to check in with you to see if the Blazor team ever got back to your question. No worries if they didn't as I appreciate that you reached out to them. :)

[davidchesnut]

Hi @CorithMalin82, yes I checked into this more and discovered that the JavaScript engine that runs your event code doesn't support loading JS libraries. There's no way to provide an HTML Script tag to point to any libraries. So right now there isn't a way to load Blazor with event code in Outlook.

If you want to request this feature, please go to our feature request site for Microsoft 365. You can create a request with more details there. One thing we are curious about, since there is no UI in events, is are you just wanting Blazor to run c# code, or is there more to your scenario? We'd like to know more.

Thanks!
David

[CraigCallender]

Hi @davidchesnut - I'll put more info in the feature request form and thank you for all this research and re-assurance that what we were trying to do is actually impossible at this time. :)

We mainly do want Blazor to run C# code for the send events. The main reason for this is that we have a well developed library for data extraction and analysis and it is written in .Net as, at the time, we wanted to be able to run it everywhere. What we've found is that having our web add-in call a service in the cloud which then contacts graph, which then uses our extraction library, and then returns the results back to the web add-in... it's just too slow (especially for messages with attachments). On top of that, many clients prefer extraction is done locally and our system only receives the metadata about what was extracted.