Classic Outlook for Windows - LaunchEvent functionality completely broken

[pepso]

Provide required information needed to triage your issue

Developing Classic Outlook Add In with LaunchEvents is a major headache as there's no logs, no guidance, nor information what is going wrong within the environment. We have spent now weeks to investigate how to get our Add In to work in Classic Outlook without any luck. Here's a simplest reproducible example what we can come up with:

Your Environment

• Platform [PC desktop, Mac, iOS, Office on the web]: PC Desktop
• Host [Excel, Word, PowerPoint, etc.]: Outlook
• Office version number: Microsoft® Outlook® for Microsoft 365 MSO (Version 2403 Build 16.0.17425.20176) 64-bit
• Operating System: Windows 11

Expected behavior

We expect LaunchEvents to work when Outlook Add In project is generated with yo office generator and by following steps from launch event tutorial.

Also expectation is that there is some way to troubleshoot and get information on why things don't work as the classic Outlook runtime for launch events is silent black box. Currently there is no option to debug or log as there is no process to attach to prior to code execution.

Current behavior

When a new Task Pane Add-In project is generated using "yo office", which then is updated with launchevent example "Automatically set the subject of new message or appointment" from https://learn.microsoft.com/en-us/office/dev/add-ins/outlook/on-new-compose-events-walkthrough?tabs=xmlmanifest, then this causes the Add In to stop working.

Before the launch event is fired for first time, Contoso taskpane opens ok (but "Loading..." is overlayed on it) and ribbon button performs an action just as expected. When you try to compose a message or appointment (first launch event), all goes to bonkers. Taskpane takes 60 seconds to load and this same applies to built in Add Ins like "Send to Onenote".

Based on runtime logs, a resource cannot be loaded when the launch event is triggered first time however manifest and bundle is available in the Wef folder as expected.

Steps to reproduce

1. use yo office to generate "Office Add-in Task Pane project" with following options

• ? Choose a project type: Office Add-in Task Pane project
• ? Choose a script type: JavaScript
• ? What do you want to name your add-in? brokenAddIn
• ? Which Office client application would you like to support? Outlook
• ? Which manifest type would you like to use? XML manifest

2. Add the changes from https://learn.microsoft.com/en-us/office/dev/add-ins/outlook/on-new-compose-events-walkthrough?tabs=xmlmanifest

• update manifest.xml with version override section
• create launchevent/launchevent.js,
• update the commands.html
• update the webpack config
• npm run build
• npm start

3. Select an email from inbox and "Show Taskpane"
4. Perform an action from the ribbon
5. Compose "New Email" and see no subject is being set
6. Close the email or leave it open and go back to inbox to open taskpane or perform an action and everything hangs for 60 seconds

Obviously there's the other issues with Add In ribbon availability issues across the clients and they appear and disappear across the clients over time.

Context

Our clients want to use AddIn on Old outlook, OWA, new outlook, and outlook on mac while ~60% are on classic outlook which makes this a major headache. Most of our clients are not ready to upgrade to new Outlook at least in the coming year because of the Add In ecosystem issues so the support for Old Outlook is required for foreseeable future.

Our Add In itself works well across all other Outlook versions except Classic Outlook, and this issue is based on simplest example we can come up with what is broken.

It's frustrating not to get any input on same or similar issue reported already in October/November 2023:
#3758

Are LaunchEvents supported still in classic Outlook? Is this issue development environment related? Any guidance would be highly appreciated.

Useful logs

Office Add In log lists this when the first event is being fired:
Unexpected Resource The resource you are trying to use does not exist.

bundle.js loaded fine to Outlook cache folder so the resource access error seems odd:

No issues when generating the Task Pane project:

Taskpane with "Loading..." overlay:

Taskpane "loading..." for 60 seconds after the first launch event is triggered:

Performing an action from ribbon "brokendAddIn is working on your Perform an action request." for 60 seconds until it actually works:

Even Send to OneNote hangs for 60 seconds:

Add In is available with hit and miss style and usually within 24h it gets available more or less in uniform way across the clients:

Any somewhat relevant errors/issues in Event Viewer are coming from Microsoft's "Meeting Insights":

I have thus far tried to uninstall office, and reinstall it but the problem still continues. Cleanin up cache(s), registry, or any other logical attempt has not yielded any consistent behavior to fix any of the issues experienced with Classic Outlook Development Environment issues.

Thank you for taking the time to report an issue. Our triage team will respond to you in less than 72 hours. Normally, response time is <10 hours Monday through Friday. We do not triage on weekends.

[pepso]

I also decided to attempt another tutorial to make sure it's not just issue with tutorial documentation, but something with Classic Outlook. This time I completed and used code from "Automatically check for an attachment before a message is sent":
https://learn.microsoft.com/en-us/office/dev/add-ins/outlook/smart-alerts-onmessagesend-walkthrough?tabs=xmlmanifest

I can confirm the broken behavior of the Classic Outlook is 100% the same with this tutorial as well.

[timwan10]

Debugging Launch Events on Classic Win32, isn't great right now, and things are being worked on to improve it.
Usually the underlying issue, is that launchEvents are run in a JS runtime on Classic Outlook, and in a WebView in the other platforms. The runtime doesn't support a lot of stuff in normal javascript. Which usually results in one of two errors:

• Runtime Error -> Results in an uncaught exception thrown, and causes the launchevent to not call Event.completed, and it just kind of sits there until it times out

• Compile Time Error -> Launch event doesn't work, but it's really hard to track down where this error is.

To find the error I usually do the following to catch the Runtime Errors:

Set up the DirectDebugger Registry: (see screenshot) Replace the GUID with your Add-in Id. (you likely don't need the DebuggerPort Entry)

If this is done correctly you should see this Dialog box pop up when the Launch Event is running:

While this dialog is up. Navigate Edge. (Edge should be the new Chromium edge, not "Spartan Edge")

edge://inspect

Under Remote Target you should see the Add-in there. It can take some number of seconds for it to show up. (sometimes I hit F5 to refresh...but it still takes some time for it to come through) If this doesn't show up eventually you can try messing with the DebuggerPort registry entry from the screenshot, and matching the port # in the Edge Debugger.

Once you have this set up. It's a standard JS debugger. You can open up the sources/console and put breakpoints in your files, and step through things. Hit Ok on the dialog that Outlook popped up to start debugging.

The official documentation for the above is here: https://learn.microsoft.com/en-us/office/dev/add-ins/outlook/debug-autolaunch?tabs=windows

If you never even reach that, then there is likely some sort of syntax problem with your bundle. (and it can be something lame that isn't ECMAScript 2016 compatible, like async and await)

Even you can't reach even that point:

Try turning on rutime logging (not the windows event log) here:
https://learn.microsoft.com/en-us/office/dev/add-ins/testing/runtime-logging

Namely add the registry entry:

This should log issues with getting the JS Runtime Sandbox started.

If done correctly this should log some errors to file that you specify here, and may give some more insights.

Note that Runtime Logging incurs a performance hit, so if you set it up on a client machine, or your regular machine, make sure to turn it off when you're done with it.

Barring that, you can upload the contents of your bundle.js and the manifest.xml here and someone can take a look.

[pepso]

Hi @timwan10 and thanks for the reply.

Indeed I have runtime logging turned on, and also know how to attach process to the debugger if I just would ever get thus far.

This is indeed the dialog I hope to see on my localhost:

In the past couple of days I have found out following with the posted example and then our actual Add In:

1. Our actual add-in installed through https://admin.microsoft.com/AdminPortal/Home#/Settings/IntegratedApps was failing on simple JS execution on runtime Intl.NumberFormat on maximumFractionDigits:0 (trident vs edge chromium parameters differ)
2. Execution of launch events only takes place when I deploy our actual add-in (or the example code in this issue) through the admin portal
3. This leads me to believe LaunchEvent's are not firing on localhost at all as the complete same budle.js is executing fine on dev and in production (when deployed through admin portal), but not when sideloaded and hosted on localhost.

Currently this leaves me to an absurd "development flow" which I used to find the above maximumFractionDigit bug:

• Develop code and hope one can guess the trident runtime differences vs. edge chromium
• Push the code to a branch and get it bundled and prepped through the CI/CD pipeline
• Update the add-in through admin portal with custom manifest
• Wait anywhere between 2-24h until add-in manifest version is the latest deployed to classic outlook
• And then finally I actually see runtime logs and add in being firing the LaunchEvents

I tested the same thing with the yo office generated example and oh dear the launch events started to fire after I deployed the add in via admin portal.

Obviously this leaves me unable to debug/test the add-in on localhost so this is not sustainable to develop any features (classic Office JS runtime does require branching of code base due to local storage and few other reasons) which is deeply troubling.

Somehow I'm having a hunch the culprit for this issues revolves around feature described here:
https://learn.microsoft.com/en-us/office/dev/add-ins/outlook/autolaunch#deploy-manifest-updates

Basically I have few leading questions:
Is there a way to make add-in on localhost to be trusted/authorized so it will fire launchevents?
Is there some setting in admin portal or local registry change I can do to avoid this?
Is it possible to add admin consent for localhost add-ins through the admin portal?

[pepso]

Meanwhile I typed my comment it made me think and now I have a bit "easier" local development flow which I just confirmed:

• Develop on localhost and guess what you are supposed to do (using taskpane's runtime, console, and debug options)
• Build the project (or rely on HotUpdates) to get the polyfilled dist codebase for sideloaded add-in
• Copy the bundle.js code (from localhost manifest's Wef Javascript cache folder) to the admin portal deployed add-in's cache folder
• Close and open the current runtime (i.e. close open appointment and open it again) so Outlook 'reloads' the localhost bundle.js from cache for execution

I guess this proves my bundle.js code is not the culprit as it works as long as the manifest is deployed through the admin portal instead of sideloaded. Only thing missing with the localhost add-in is the firing of launch events.

[timwan10]

I can double check with some developers about the Localhost thing, but I believe that is supposed to work. LaunchEvents currently do NOT work via Add-ins installed via the Store (unless by Admin) but that doesn't sound like what you are doing here? How are you installing the manifest for the localhost add-in? (please be specific here, as the method of installing the add-in, can affect if launch events work). It should work if the Localhost add-in is sideloaded.

Modifying the bundle.js in the WEF folder DOES work, and is a reasonable solution for "quickly modifying and testing changes." However, it can be replaced on Outlook boot. (Outlook may download and replace the file in the cache, depending on cache-expiry/updates on server/etc.) So don't save vital changes in ONLY that file, as they may get rewritten at some point.

[pepso]

Hi @timwan10,

Thanks for the reply.

I am attempting to sideload the extension under development using this command from the yo office generated command (here's the console output for the command output):

npm start:

> office-addin-taskpane-js@0.0.1 start
> office-addin-debugging start manifest.xml
Debugging is being started...
App type: desktop
Enabled debugging for add-in f2da3848-bf7c-404f-83f6-e55f250080e2.
Starting the dev server... (webpack serve --mode development)
The dev server is running on port 3000. Process id: 22892
Sideloading the Office Add-in...
running: npx @microsoft/teamsapp-cli install --xml-path "C:\add-in-folder-path\brokenAddIn\manifest.xml"

This command is in preview.
Using account xxxx
TitleId: U_27738cb7-ee5d-d0e9-f3be-c75a066eee22
AppId: f2da3848-bf7c-404f-83f6-e55f250080e2
Sideloading done.

Successfully registered package! (U_27738cb7-ee5d-d0e9-f3be-c75a066eee22)
 STDERR:

Launching outlook via C:\Program Files\Microsoft Office\Root\Office16\OUTLOOK.EXE
Debugging started.

I have tried to load the extension manifest through the Classic outlook's "Manage Add-ins" button which takes you to this screen:

Either way I get the same result (no launch events).

The issue with my current development flow (without functioning localhost launchevents) is that there is no way to attach to the debugger when developing the add in. This then results to a lot of trial and error to understand what happens on the trident's JS Runtime vs. chromium/vebview2 based JS runtime.

[timwan10]

hearing back from the devs, this is supposed to work. (loading from Localhost) There were some issues with this on Windows 10...but you mention that you are loading from Windows 11. Apparently there were some bug fixes to the runtime for the version after this. Is it possible you could check this again on a later version of outlook? I believe the latest version available in production is 16.0.17531.XXXXX

If you are on the insiders' program you should have even later builds (17628)

[pepso]

Hi @timwan10 ,

Currently I'm on: Microsoft® Outlook® for Microsoft 365 MSO (Version 2403 Build 16.0.17425.20176) 64-bit.

Here's my windows info:
Edition Windows 11 Pro
Version 23H2
OS build 22631.3447

I have had multiple versions of the Outlook since I first time experienced this issue in latter part of 2023. None of the versions I had between 2310 to current 2403 fired the launch events. I don't have records what builds I have had in between these two.

It was only now when I exhausted all the options by myself unable to get the events working when I raised this issue.

Here's a link to the comment I made back then when I first time observed the issue. Back then I was using the same build as the person raising the issue: Version 2309 which I updated to 2310.

Since my comments in the issue from end of last year I have updated all the relevant npm packages and I noticed the new way of sideloading using teamsapp-cli since then. Even with the npm package updates nothing changed (launch events not firing).

I'm working on something else this week so won't be able to test the latest version right now but I'm fairly certain this issue is something quite fundamental as the builds between 2309 -> 2403 have resulted in same lack of events being fired.

[teejay001]

Hi @exextoc,

Unfortunately I am also facing the same issue. My launch event does not work and my taskpane takes up to 8 sec to load completely. I am using 2404 build version.

Please, any advice or updates.

[timwan10]

@teejay001 You should probably open a separate github post/issue for what you are facing. It is likely a different issue.

[pepso]

Hi @timwan10, I am working on the extension again and can report that after the Outlook update the problem persists.

Current version: "Microsoft® Outlook® for Microsoft 365 MSO (Version 2405 Build 16.0.17628.20006) 64-bit"

Since I last wrote here, our production extension has worked completely fine for the past 3 weeks in my Outlook. Now, when I side-load the development version (different extension ID), even the production version stopped firing the events.

I believe with the Outlook version 2403 this was not the case so there is some change how the events are handled between these two versions. (The 2403 had 60 second delay "add in name is working on your Perform an action request" before it completed the event.

[pepso]

Hi @timwan10 or @exextoc, any indication of the timeline for issue identification / resolution for the launch events?

[timwan10]

Yeah sorry for the delay, we're having trouble reproing this here. Is there a way you can post the Manifest that you are using, along with the Bundle? (Then I assume you just put the Bundle on your localhost somewhere?)

I know you have the repro steps in the post, but it may help to get the actual files to make sure there isn't a step missing/difference.

[pepso]

Thanks @timwan10 , do you have an email address/url I can post to share the file/link to the manifest?

In the past weeks while "hacking" this dev flow, I have started to grow suspicious the issue is borne somehow with add-in manifest conflict between production version and side loaded version. e.g. maybe I have had the add-in side loaded and then I have installed the same add-in via admin portal, or the other way around.

I feel like there's some underlying registry conflict with the add-in's source files handling and not clearing the cache/registry properly. Is there a way for you to share how to see any add-in registry information in the exchange server (where the centrally managed manifests are deployed), and/or local registry, which I can clean up manually?

An example from the past days is that my Outlook went total belly up for my hacked development flow while I had the production version deployed (through admin, working nice, etc.), and I wanted to test something on my local. I believe I by accident side loaded the production version's (same appId) alike manifest which then introduced conflicting SSO app IDs and all hell broke lose further.

If above is true, and there is some conflict between 2 manifests deep down in some registry, then my suspect is either the AppDomain, or WebApplicationInfo's Id conflict.

I'm right now trying repair and reset my office, remove the admin installed add in, remove the side loaded add in(s), but this looks like is not fixing any of the issues for Classic Outlook.

[carlosb1504]

any joy with this @pepso ? We are seeing a very similar issue with our development add-in which we run in a separate dev tenancy. 60s taskpane load time on Windows Outlook. The add-in implements OnCompose, RecipientChange and AttachmentChange launch events, plus the ItemSend hook.

I've tried stripping down all of the Launch Events to do nothing but call completed() and changed the taskpane to just display the word 'test'.. still see the delay.

Tried creating a separate dev tenancy separate from the one we normally use and deployed the manifest there. Same problem.

Like you I'm wondering if there is some conflict there between some element of the manifest but without being able to debug what Outlook is choking on it's very difficult to faultfind.

[timwan10]

@pepso Usually people create a private github and give @exextoc access.

Admin and Sideloaded Add-ins aren't supposed to cause an error like this. (but obviously bugs could happen). When an Admin and Sideloaded Add-in are loaded. The Exchange Server is supposed to prioritize the Admin installed Add-in, and the client ONLY sees the Admin installed Add-in... Though that means if you are developing an add-in with the SAME Add-in Id, then you would never see updates when you sideloaded it. However, that would only be manifest changes. Most Add-ins Admin or Sideloaded add-in point to the same bundle. (but anything you depended on for the Manifest would break...if for example you added LaunchEvents into the Sideloaded manifest but NOT the Admin deployed Manifest).

Now that I'm looking over your posts, I think I missed what you were explaining. Usually when development testing happens, we would expect the developer to sideload the add-in for themselves. And use that to test. Then when everything is working. Admin deploy that Manifest. OR developers use a different Add-in Id for development and deployment.

If you are using the Same ID for a sideloaded add-in as the Admin deployment, you could certainly see the above issue, and not getting updates in the manifest that is being loaded. (but again that would only affect changes in the manifest)

To answer your other questions this SO post goes into some detail about how Exchange stores XML Manifests for each USER. (NOT Admin):

https://stackoverflow.com/questions/70457104/command-line-or-other-tools-to-collect-outlook-add-ins-installed

However, the actual list of the add-ins is stored in: IPM.Configuration.ExtensionMasterTable. Roaming Settings are stored in IPM.Configuration.ClientExtension.*

Deleting the IPM.Configuration.ExtensionMasterTable would clear all USER installed Add-ins for the user, if you suspect there could be an error in there... (this is NOT a supported decision...I do not recommend you do this on anything aside from a test account)

I personally don't know of a way to get the actual contents for Admin installed Add-ins.

What may be more useful is that the Get-App -Mailbox cmdlet should give you the Add-ins that are being returned from the Exchange Server to that user. (i.e. the de-duped list from Admin installed add-ins and User installed Add-ins)

Perhaps even better than that, would just to be run fiddler and grab a trace from when Outlook boots, and you can see what Exchange is actually returning to that machine for Add-ins.

Additionally, you can check the Add-in manifest Cache for the user:

C:\Users[UserName]\AppData\Local\Microsoft\Office\16.0\Wef{79A24F6F-C404-4062-83C8-7EF1F5BDE719}\AkdbHrg8zpN9Dbs4k6biHA==\bbca517c-48a6-4f63-bf7d-fac9edd1fa4a_ADAL\Manifests

(Username, GUID and Encoding sections will be unique on your machine)

The contents for that are what the client is actually loading.

Of note, there is also another cache here:
C:\Users[username]\AppData\Local\Microsoft\Outlook\HubAppFileCache\

As right now, depending on your account, Outlook is obtaining manifests from the new Teams Server as well. If you are installing XML manifests on Exchange, this should be a duplication of the manifests you have in the WEF folder. But do note a fix was rolled out recently for versions of outlook regarding this:

#4483

But in either case the client should load the newest version of the Add-in.

[pepso]

Great, I'll try to do a private repo today/this week for the "BrokenAddIn" and add a document of different findings, and details I can recall.

What you wrote made me to dig in deeper on the potential GUID conflict and to check the cache folders thoroughly and I think there's now some real pointers to the problem I was able to dig up:

1. When the issue is ongoing, the Wef folder cache has WellKnownResources and Javascript folders, which gets populated nicely (with corresponding json/bundle). This for the both, dev and production AddIn GUIDs. However, the Manifests-folder is empty. That's odd right?
2. If I recreate GUID "conflict" between side-loaded and production Add-In, npm start nicely and "side loads" the app with the teams cli tool. Uninstalling the side-loaded is totally another story:
   

So it seems somehow I get "Unacquire failed." error.

3. When I try to exact same with the BrokenAddIn, the same issue follows. Somehow I "cannot unacquire" the side loaded AddIns:
   

@timwan10 Is this helping you narrow down the problem? I'll any case share the broken add in with you/exec later on so you have the exact same copy as I have it (what ever version I happen to have right now).

[pepso]

@timwan10 I have just added @exextoc to private repo called brokenAddIn. I recommend you check the information PDF as a supplementary information.

[timwan10]

Thanks, exextoc has access to that add-in right now.

I'm not sure when the developers will be able to take a look.

I did take a look at your PDF in there and had some comments.

In this thread and the PDF there are a lot of different things going on. Right now it seems like the thing that the Devs can take a look at is Broken Add-in and why the Launch Event isn't firing?

• I'm not sure why you are getting the error on unacquire. This means that the side loaded add-in is probably left on the server. Hopefully it can be manually uninstalled via aka.ms/olksideload

• You mentioned in the PDF, but just to make sure. Prod, Dev and Broken Add-in all have different Add-ins IDs. I just want to make sure that you aren't sideloading and admin deploying an add-in with the same ID. (the admin deploy should take precedence in this case if you are... but wanted to rule out any bugs in this scenario if this is the case)

• The main issue to solve is that the Dev and Broken Add-in aren't running their launch events.

• Have these been tested independently from each other? (i.e. without the others installed?) The reason I ask, is that issues with One launch Event, could affect the others. The 60 second delay in ALL Taskpanes, is when an error occurs in ANY LaunchEvent. (this isn't ideal and is something that the team wants to fix...but ultimately fixing the error with LaunchEvent will cause this issue to not surface)

• There is a feature rolling out that is moving the Add-in cache from the WEF folder cache to the HubAppCache. It's not weird to see nothing in the WEF folder cache, if they are in the HubAppCache. The HubAppCache will contain the JSON manifest, that includes the XML Manifest as a property in it. This feature is currently at 50% saturation, so you will see different behavior across different machines/versions.

(To be more technical about this, Outlook used to get Manifest from Teams (HubApp) and Exchange (WEF)). It is changing so that Outlook only gets add-ins from Teams...but Teams gets the add-ins from Exchange at the server level, which is why you see the XML manifest "inside" a JSON manifest)

[pepso]

@timwan10 I agree I might have been too verbose in the PDF (and the thread). I can only observe the problem (no launch events) from all the directions as I have no in-depth knowledge of the implementation and/or logs for narrowing down the problem.

Here's my attempt to keep the order of your questions:

1. Throughout the development period (~6 months) npm stop / unaquire has been more consistent removing the side loaded add in than the web screen. The aka.ms/olksideload often times have shown error 300 without details when attempting to remove it through there. With passing time (i.e. some hours), and side loading, re-sideloading, unacquiring has eventually resulted in "clean slate" situation. Sometimes it takes a lot of attempts (i.e. up to 5 times to side load and switching classic outlook to new outlook and attempting again).
2. Yes, they all do have different IDs + are generally speaking version controlled. It is my belief I might have by accident attempted at some point load manifests which might have had colliding IDs as part of the dev and test flow (because it's so convoluted process how I copy files from dev's dist to cache folder). In ideal circumstances we would only sideload the dev version (and brokenAddIn) and nothing else.
3. Yes. Indeed the point here is the dev is not running launch events. The brokenAddIn was my attempt to "simplify" the problem without "custom" code from our side which results to same issue as our own dev version.
4. Yes. You can see in doc that indeed brokenAddIn and dev versions are independently installed at the given time time when I compiled the PDF (screenshots from "Manage Add-ins" button which I assume is same as aka.ms/olksideload?). Also when the production version is running alone (no side loaded dev or brokenAddIn) it's working fine. Interestingly your question made me wonder why did Classic Outlook attempt to load all 3 add ins in its startup (based on the outlook logs) when aka.ms/olksideload clearly showed there's only production and dev versions installed. Here's the scenarios I have tested in the past months for Classic Outlook (based on status visible through "Manage Add-ins" button in Classic Outlook):
   [ ] production manifest works when admin deployed (100% independent)
   [ ] production manifest side-loading does not fire events (100% independent)
   [ ] dev manifest side-loading does not fire events (100% independent)
   [ ] dev manifest side-loading does not fire events (when with production version)
   [ ] brokenAddIn manifest side-loading does not fire events (the production version installed)
5. Got it. So we should prepare the bundle.js copy over technique based dev flow will disappear in the short future when the migration from Wef to HubApp progresses?

Maybe it's worthwhile to remind that everything above I talk is regarding Classic Outlook. Add ins work fine in new Outlook and OWA after local changes are propagated across the versions fairly consistently (i.e. 95% of times). Sometimes I need to unacquire/side load, and wait and things get back to normal in short period of time (i.e. wait for an hour).

You do have access to production code base as it's available through the AppSource (just google/search with the name you see in PDF document). I'm happy to get exact development version (manifest/code) for the devs if this would somehow be yielding results instead.

[pepso]

Hi @timwan10, I added second PDF regarding HubAppCache folder inconsistencies. Just in case it helps on narrowing down the conflicting manifest loading sequences (or any case excludes that as a root cause).

[pepso]

Hi @timwan10,

I have spent time this morning with a client of ours who is now experiencing #4483 with our production version with a twist tied into the launch events not firing.

Here's the steps that have happened this morning:

• My client upgrade our production add-in version via admin console (non marketplace manifest) on last week's Wednesday
• Today morning the update finally came through to their local Outlook
• I was on a call to troubleshoot why my client couldn't send any meeting invites since the update (they were stuck on the loop described in issue Classic Outlook Windows ItemSend Add-in: Endless looping after updating manifest version #4483 )
• After a "few hours" has passed since the add-in update they get a message "Add-in is taking too long to respond" when trying to send an invite and no launch events are firing anymore in their Outlook.

Is this a separate issue or is the launch events not firing for side-loaded add-ins now found their way to production version of the Outlook? Does this mean it's not anymore a local dev flow issue only?

Personally I'm on the latest https://learn.microsoft.com/en-us/officeupdates/current-channel version (2406 Build 16.0.17726.20126) and my client in question is on monthly enterprise https://learn.microsoft.com/en-us/officeupdates/monthly-enterprise-channel (Version 2404 Build 17531.20190).

I updated to the latest Outlook available for me and can confirm we don't get launch events for production version anymore. Outlook logs show following (on production Add-In), but that's where the logging ends:

01/07/2024 14:57:13	Verbose	Runtime	[Console] [Log] Platform Bundle - Office exists!		
01/07/2024 14:57:13	Verbose	Runtime	[Console] [Log] Platform Bundle - Office.actions exists!		
01/07/2024 14:57:13	Verbose	Runtime	[Console] [Log] Platform Bundle - Office.actions.associate exists!		
01/07/2024 14:57:13	Verbose	Runtime	[Console] [Log] Outlook Batch JS loaded!		
01/07/2024 14:57:13	Verbose	Runtime	[Console] [Log] Outlook LaunchEvent JS loaded!		

With previous versions I saw at least "InvokeMailboxCreateOM was invoked!" which would indicate the event fired.

Here's the screenshot of my Outlook's version as I'm not sure what build number is more important, the one on the info dialog, or the popup which opens when you click the "About Outlook":

Do you want me to open a separate issue for the production launch events not firing between versions 2406 Build 16.0.17726.20126 (not firing) and Version 2405 Build 16.0.17628.20006 (they were firing)?

[exextoc]

Sorry there are a lot of updates/questions here. I'll try to answer best I can.

1. The Wef Folder -> HubAppCache should only affect Manifests. The wef......\Javascript folder that contains the bundle.js should not change, and can still be used (and replaced)

2. The devs sideloaded the "BrokenAddin" (after hosting it on localhost) and were able to see this work. don't repro any issues :( The only launch event in BrokenAddin is "OnMessageSend" which seems to run fine, along with the taskpane.

3. I did install your add-in from the store, and manually sideloaded the Manifest that was downloaded. This launch event is failing with the "Intl is not defined" exception. This error, can actually cause a lot of problems. I need to double check with the devs, but I'm not sure how you are supposed to get this error...aside from noticing that LaunchEvents don't fire. This makes it so that Launch Events don't fire. (and potentially cause the 60 second delay in ANY other taskpane add-in that is opened)

I suspect this combined with the fact that there is a delay when sideloading addins via aka.ms/olksideload. That may have caused us to misdiagnose some of the problems above. (i.e. I'm not sure the "brokenaddin" is actually broken...but it could have been that the prod add-in is still loading and causing issues in other add-ins?)

4. I think you already know, but only the LaunchEvents that work with Add-ins installed from store are the On*Send LaunchEvents. The other LaunchEvents only run when sideloaded or admin deployed. (which you are...doing). But anybody installing your add-in from the store directly (without admin deployed)...will see no launchevents fire, aside from OnSend events.

5. The Classic Outlook Windows ItemSend Add-in: Endless looping after updating manifest version #4483. Does not sound like this is what's happening here. That issue happened when the version # of the add-in was increased. And the LaunchEvent actually launches (repeatedly). It will never "time out" and would never produce the "Add-in is taking too long to respond" error. This sounds more like an error in the Javascript again. You mentioned the customer installed a non-marketplace add-in manifest. Does this use a different bundle than the version currently in the marketplace?

Any manifest that you can provide, that repros the problem can help us diagnose the issue. Currently, the only manifest I have that was able to repro the problem was the Marketplace Manifest that I manually sideloaded.

Most issues we're seeing with LaunchEvents right now have something in the bundle.js that is hard to diagnose. (i.e. we aren't seeing any blanket "launchevents" aren't firing in any version of Outlook). So any specific manifest you can provide that our devs can take a look at can help.

6. I was made aware that Outlook just rolled out a change to production to change the JS engine that runs from Chakra to V8. (this rollout goes as far back to version 16.0.17414+ on the monthly channel...(but not the Semi-Annula (SAC) channel, or Monthly Enterprise Channel (MEC)). So there could be changes here that affect the Add-in, but it should have been for the positive. (i.e. V8 supports a lot more than Chakra). Again if we think this is the issue, sending us a manifest with the error can help determine the problem.

I will follow up with the devs to see if there is a way for you to diagnose these JS problems yourself.

Responses will be delayed this week, as a lot of the team are gone due to the July 4th holiday.

[pepso]

Thank you @exextoc for the comprehensive responses. I think with the above we can at least exclude some of the things on the list.

Regarding the #4483, that was happening at my client's environment/Outlook (who did update the manifest version). The problem sorted itself out in 24 hours. This is indeed separate issue and I believe will be fixed around 7th of July when 2404 update gets rolled out so I'm not too concerned about it at this stage.

I believe there is 2 completely separate problems I'm having right now:

1. launch events not firing on my Windows/Outlook combo when side-loading any add-in, and
2. the production version's Intl package errors, maybe related to update you mention, or something else.

I raised the Intl as a separate issue because that is not "impacting" the launch events not firing but "just a code execution issue" on latest Outlook version in the current channel #4631.

Just to wrap up, here is my best understanding of the steps how launch events take place in Classic Outlook:

1. Detect a launch event and find manifests matching for it (or load manifest and hook its events to some event handler)
2. Download the add-in bundle to cache, validate .well-known code, prepare the add-in code on file system side
3. Prepare the the launch event sandbox
4. Wait and execute tests the Office.js is loaded in the sandbox (i.e. Platform Bundle - Office exists!)
5. Test the sandbox is ready (i.e. Outlook LaunchEvent JS loaded!)
6. Load the add-in code from bundle.js to the sandbox
7. Execute the launch event action against the sandboxed code

Now, attempting to summarize everything thus far and excluding certain things from the scope of this issue:
While I was debugging the Intl issue yesterday I found a reference to the Intl package outside of a function code (i.e.
var timezone = Intl.DateTimeFormat().resolvedOptions().timeZone;
was causing "silent" launch event execution. I saw the launch events in the logs, but they just did not report anything meaningful for me as a dev. (Failure on step 6)

When I commented out the above style variable declaration from Intl package the Invoke of our code took place and got to the execution part of our code. This then resulted into a runtime error "Intl is not defined" from function(s) which are executed within a launch event invoke. (Failure on step 7).

After my Intl-package debug attempts I wanted to test the brokenAddIn with Intl package reference as simple as possible: 'console.log("Intl support?", Intl)' in the action code to exclude our add in has some bundling issue. When I 'npm start' / side load the brokenAddIn the launch events went completely silent just like before (no invokes for brokenAddIn, nor for the production-like version which was just throwing console errors of "Intl is not defined").

Above steps make it clear the production version does fire events (as is reported here) when it's loaded as a standalone (without side-loading). Our current issue with production errors is indeed a completely separate issue for side loaded add-ins not firing events. For side-loading, I don't get any logs like: "[Console] [Log] Platform Bundle - Office exists!" which indicates there is a problem with Step 1, 2, or 3 built into our Outlook/side-load process?

Just a FYI: Here's how the brokenAddIn behaves on Outlook when it is side loaded for me:

As of writing this (12h since the above attempt of side-loading and removing the side-loaded brokendAddIn) the production launch events has started to fire again (cache expiry/cache refresh/cache rebuild?). I decided to see if I can replicate the behavior described above. After I side loaded the brokenAddIn just like yesterday, no launch events for the brokenAddIn, nor for the production-like add-in either. This time it took only 30 minutes after "npm stop" / removal of side loaded brokenAddIn, and my production-like add-in was firing launch events happily again.

Here's my logs just before I side loaded the "brokenAddIn" from the production-like version with Intl "code issue" as a comparison:

03/07/2024 08:50:53	Medium	Web Add-In Runtime Logging Session Started			
03/07/2024 08:50:53	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/appforoffice/1.1" : Element Name "TabletSettings", Line=1, CharPosition=6776		
03/07/2024 08:50:53	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/appforoffice/1.1" : Element Name "PhoneSettings", Line=1, CharPosition=6996		
03/07/2024 08:50:53	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/officeappbasictypes/1.0" : Element Name "Urls", Line=1, CharPosition=8366		
03/07/2024 08:50:53	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/officeappbasictypes/1.0" : Element Name "ShortStrings", Line=1, CharPosition=8550		
03/07/2024 08:50:53	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/officeappbasictypes/1.0" : Element Name "LongStrings", Line=1, CharPosition=9940		
03/07/2024 08:50:53	Unexpected	Manifest	Issue encountered while parsing manifest, add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Error at element "Resources" : Add-in manifest parsing encountered unexpected node termination, Line=1, CharPosition=14571		
03/07/2024 08:50:59	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/appforoffice/1.1" : Element Name "TabletSettings", Line=1, CharPosition=6776		
03/07/2024 08:50:59	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/appforoffice/1.1" : Element Name "PhoneSettings", Line=1, CharPosition=6996		
03/07/2024 08:50:59	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/officeappbasictypes/1.0" : Element Name "Urls", Line=1, CharPosition=8366		
03/07/2024 08:50:59	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/officeappbasictypes/1.0" : Element Name "ShortStrings", Line=1, CharPosition=8550		
03/07/2024 08:50:59	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/officeappbasictypes/1.0" : Element Name "LongStrings", Line=1, CharPosition=9940		
03/07/2024 08:50:59	Unexpected	Manifest	Issue encountered while parsing manifest, add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Error at element "Resources" : Add-in manifest parsing encountered unexpected node termination, Line=1, CharPosition=14571		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] Platform Bundle - Office exists!		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] Platform Bundle - Office.actions exists!		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] Platform Bundle - Office.actions.associate exists!		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] Outlook Batch JS loaded!		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] Outlook LaunchEvent JS loaded!		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] InvokeMailboxCreateOM was invoked!["SENSITIVE DATA REDACTED"]		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] SDX Control is ready!		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] RunLaunchEventHandlerFunctionWithData was invoked with funcName = action		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] 'configurationAPIProtector start:', false		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] 'Using cached config - config age:', 35, 'minutes.'		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] MailboxHostExecuteApi invoked!		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] MailboxHostExecuteApi invoked!		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] MailboxHostExecuteApi invoked!		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] MailboxHostExecuteApi invoked!		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] MailboxHostExecuteApi invoked!		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] MailboxHostExecuteApi invoked!		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] MailboxHostExecuteApi invoked!		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] MailboxHostExecuteApi invoked!		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] MailboxHostExecuteApi invoked!		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] MailboxHostExecuteApi invoked!		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] [ReferenceError: Intl is not defined]		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] LaunchEventObj.completed was invoked: 8		
03/07/2024 08:50:59	Unexpected	Runtime	[Error] [Log] ReferenceError: Intl is not defined
createPresentation
C:\Users\FOLDERREDACTED\bundle.js:1181:28
calculate
C:\Users\FOLDERREDACTED\bundle.js:1136:2
_callee17$
C:\Users\FOLDERREDACTED\bundle.js:1253:10
tryCatch
C:\Users\FOLDERREDACTED\bundle.js:122:1061
Generator.<anonymous>
C:\Users\FOLDERREDACTED\bundle.js:122:3007
Generator.next
C:\Users\FOLDERREDACTED\bundle.js:122:1698
asyncGeneratorStep
C:\Users\FOLDERREDACTED\bundle.js:123:69
_next
C:\Users\FOLDERREDACTED\bundle.js:124:162
u
foundation.win32.bundle:70:156
<unknown>
    at foundation.win32.bundle:70:868
		
03/07/2024 08:50:59	Verbose	Runtime	[Console] [Log] Event completed message sent to host!

Here's the logs without a single reference to the launch events after side loading the brokenAddIn:

03/07/2024 09:00:52	Medium	Web Add-In Runtime Logging Session Started			
03/07/2024 09:00:52	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/appforoffice/1.1" : Element Name "TabletSettings", Line=1, CharPosition=6776		
03/07/2024 09:00:52	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/appforoffice/1.1" : Element Name "PhoneSettings", Line=1, CharPosition=6996		
03/07/2024 09:00:52	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/officeappbasictypes/1.0" : Element Name "Urls", Line=1, CharPosition=8366		
03/07/2024 09:00:52	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/officeappbasictypes/1.0" : Element Name "ShortStrings", Line=1, CharPosition=8550		
03/07/2024 09:00:52	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/officeappbasictypes/1.0" : Element Name "LongStrings", Line=1, CharPosition=9940		
03/07/2024 09:00:52	Unexpected	Manifest	Issue encountered while parsing manifest, add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Error at element "Resources" : Add-in manifest parsing encountered unexpected node termination, Line=1, CharPosition=14571		
03/07/2024 09:00:54	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/appforoffice/1.1" : Element Name "TabletSettings", Line=1, CharPosition=6776		
03/07/2024 09:00:54	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/appforoffice/1.1" : Element Name "PhoneSettings", Line=1, CharPosition=6996		
03/07/2024 09:00:54	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/officeappbasictypes/1.0" : Element Name "Urls", Line=1, CharPosition=8366		
03/07/2024 09:00:54	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/officeappbasictypes/1.0" : Element Name "ShortStrings", Line=1, CharPosition=8550		
03/07/2024 09:00:54	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/officeappbasictypes/1.0" : Element Name "LongStrings", Line=1, CharPosition=9940		
03/07/2024 09:00:54	Unexpected	Manifest	Issue encountered while parsing manifest, add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Error at element "Resources" : Add-in manifest parsing encountered unexpected node termination, Line=1, CharPosition=14571	

And here's the logs after I removed the sideloaded brokenAddIn (and waited for half an hour before restarting Outlook) firing nicely for the production-like add in:

03/07/2024 10:00:36	Medium	Web Add-In Runtime Logging Session Started			
03/07/2024 10:00:36	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/appforoffice/1.1" : Element Name "TabletSettings", Line=1, CharPosition=6776		
03/07/2024 10:00:36	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/appforoffice/1.1" : Element Name "PhoneSettings", Line=1, CharPosition=6996		
03/07/2024 10:00:36	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/officeappbasictypes/1.0" : Element Name "Urls", Line=1, CharPosition=8366		
03/07/2024 10:00:36	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/officeappbasictypes/1.0" : Element Name "ShortStrings", Line=1, CharPosition=8550		
03/07/2024 10:00:36	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/officeappbasictypes/1.0" : Element Name "LongStrings", Line=1, CharPosition=9940		
03/07/2024 10:00:36	Unexpected	Manifest	Issue encountered while parsing manifest, add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Error at element "Resources" : Add-in manifest parsing encountered unexpected node termination, Line=1, CharPosition=14571		
03/07/2024 10:00:40	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/appforoffice/1.1" : Element Name "TabletSettings", Line=1, CharPosition=6776		
03/07/2024 10:00:40	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/appforoffice/1.1" : Element Name "PhoneSettings", Line=1, CharPosition=6996		
03/07/2024 10:00:40	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/officeappbasictypes/1.0" : Element Name "Urls", Line=1, CharPosition=8366		
03/07/2024 10:00:40	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/officeappbasictypes/1.0" : Element Name "ShortStrings", Line=1, CharPosition=8550		
03/07/2024 10:00:40	Monitorable	Manifest	Skipped unrecognized XML element for add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Element Namespace "http://schemas.microsoft.com/office/officeappbasictypes/1.0" : Element Name "LongStrings", Line=1, CharPosition=9940		
03/07/2024 10:00:40	Unexpected	Manifest	Issue encountered while parsing manifest, add-in ID : bc13b9d0-5ba2-446a-956b-c583bdc94d5e, Location : Error at element "Resources" : Add-in manifest parsing encountered unexpected node termination, Line=1, CharPosition=14571		
03/07/2024 10:00:41	Verbose	Runtime	[Console] [Log] Platform Bundle - Office exists!		
03/07/2024 10:00:41	Verbose	Runtime	[Console] [Log] Platform Bundle - Office.actions exists!		
03/07/2024 10:00:41	Verbose	Runtime	[Console] [Log] Platform Bundle - Office.actions.associate exists!		
03/07/2024 10:00:41	Verbose	Runtime	[Console] [Log] Outlook Batch JS loaded!		
03/07/2024 10:00:41	Verbose	Runtime	[Console] [Log] Outlook LaunchEvent JS loaded!		
03/07/2024 10:00:41	Verbose	Runtime	[Console] [Log] InvokeMailboxCreateOM was invoked!["SENSITIVE DATA REDACTED"]		
03/07/2024 10:00:41	Verbose	Runtime	[Console] [Log] SDX Control is ready!		
03/07/2024 10:00:41	Verbose	Runtime	[Console] [Log] RunLaunchEventHandlerFunctionWithData was invoked with funcName = action	
......

I think above logs should tell exactly what I have tried to tell in the past months:

1. launch events fire nicely
2. npm start / side load brokenAddIn - no launch events
3. npm stop / remove brokenAddIn - and wait for a while
4. launch events fire nicely

Is there a better or faster way to troubleshoot this issue than over GitHub commenting? We have had this issue since November of last year (albeit raised as a own GitHub issue only in April) and we are still at the point of where you cannot replicate the behavior, and we don't have side-loaded launch events to develop our production add-in locally for Classic Outlook properly.

[JuaneloJuanelo]

Hello @pepso thank you so much for sharing your feedback. OUr team as of now is unable to repro your issue. we would love to follow up with you offline, would you mind sending me some contact info so we can arrange a meeting? please email me thank you !

[ragnarstolsmark]

We are experiencing the same issue. The tutorial for launch events is not working for us as well.

[pepso]

Thank you @JuaneloJuanelo. Sent you an email on Wednesday titled "Contact Re: GitHub office-js issue #4391: local launch events not firing"

Looking forward to your response over there.

[bgauthierdatasolution]

I see the exact same problem.
It's a shame because there's not much missing so that we can finalize add-ins that work equally well on the old Outlook interface and the new one.
Thank you for your attention and correction

[JuaneloJuanelo]

Hello folks we will meet with @pepso and hopefuly we can solve the problem for all thanks for your participation!

[pepso]

So, here comes my summary of the issue on the local box after call with MS team, and a couple of more days of debugging.

The problem is clearly rather complex in nature, but I attempt to keep it as simple as possible and give you a way to circumvent the issue.

1. We are using webpack to bundle launchevent code, in our case: commands.js/commands.html for universal Outlook support.
2. When running the build (dev/production) using webpack (without the dev-server dependencies) the bundle.js works completely fine on Classic Outlook
3. When you run the local dev environment via npm start, webpack injects webpack server client and hot reload code + dependencies to the resulting bundle.js code (commands.js).
4. When Outlook Classic loads the resulting bundle it fails 100% silently without a single log indication
5. This failure then causes orphaned process to hang in your OS (msoadfsb.exe with CMD argument "...localhost...")
6. When this (orphaned) process is running in your OS, any further launch events wont fire
7. The orphaned process survives even the Outlook restart so better check if it is there

This all led me to debug the webpack produced bundle.

While debugging, diffing, and removing dependencies from the bundle I narrowed down to following potential culprits imported to the bundle.js (with alternating hot/client devServer configuration options):

/node_modules/ansi-html-community/index.js
/node_modules/events/events.js
/node_modules/html-entities/lib/index.js
/node_modules/html-entities/lib/named-references.js
/node_modules/html-entities/lib/numeric-unicode-map.js
/node_modules/html-entities/lib/surrogate-pairs.js

There seems to be a few issues underlying the launch events not firing:

1. Silent process which fails to load the bundle
2. Silent JS code issue when loading bundled dependencies of the file
3. Hanging process which makes all future launch events to continuously fail

Eventually I did find a way to configure the devServer in a way that local launch events do fire on the code base independent how the code is being built (devServer/dev/production):

devServer: {
      hot:false,
      client:false,
}

This obviously comes with a drawback when you develop taskpanel / other browser based code as you lose the hot reloading at other client configuration options.

@ragnarstolsmark, @bgauthierdatasolution maybe you check if you excess processes running (msoadfsb.exe) and try configuring your webpack dev-server with hot:false, and client: false flags.

[bgauthierdatasolution]

@pepso Thanks for the feedback, I'll try it.

[1TheMuffinMan]

I just want to state that I'm not injecting Webpack stuff into my javascript file for events and of the 3 events that I'm using only the OnMessageSend handler has issues. In fact, on message send Outlook classic fires the handler for RecipientsChanged for some reason rather than

In New Outlook for Windows and in the browser my OnMessageSend handler is invoked and works fine.

So I'm in a tough spot because I have nothing to debug.. the breakpoint is never hit.

[millerds]

Another way to use a launch event file in webpack w/out getting the webpack injected stuff is to add this to the devServer section of webpack config:
static: { directory: path.join(__dirname, "dist"), publicPath: "/public", },
And then update the manifest to point to "https://localhost:3000/public/launchevents.js" for the launch event file. This tell webpack to serve up the file unaltered. Hot reload still works on the other files.

[JuaneloJuanelo]

I just want to state that I'm not injecting Webpack stuff into my javascript file for events and of the 3 events that I'm using only the OnMessageSend handler has issues. In fact, on message send Outlook classic fires the handler for RecipientsChanged for some reason rather than

In New Outlook for Windows and in the browser my OnMessageSend handler is invoked and works fine.

So I'm in a tough spot because I have nothing to debug.. the breakpoint is never hit.

@1TheMuffinMan This seems to be a different issue can you please open a separate case? thanks!

[1TheMuffinMan]

Thanks, I got it working.
Outlook classic for Windows JS runtime doesn't support async/await keywords, a handful of global variables and the .well-known file had to be created for CORS. I do a lot in the events file so I duplicated it and then refactored a version specifically for Outlook classic.

In my manifest, Outlook classic uses one version and in the other clients that use the HTML file the HTML file loads a different script.

[fedeisas]

Hi! I'm facing similar issues to the ones exposed in this thread.
My Outlook add-in needs LaunchEvent for MessageCompose, which contains an autorun command and a taskpane.

I'm testing on Win10/Win11 using Office Deployment Tool to switch versions. When I use those versions (16.0.11929.20946, 16.0.10730.20348) I get Skipped unrecognized LaunchEvent on my runtime logging.

My add-in works perfectly on Outlook for Mac, iOS, Android, and recent versions for Win10/11 (both using legacy and new Outlook mode). But our last add-in update* broke support to ~10% of our customers. Even when they're using the same Outlook version, it seems they're using a different web engine.

• Which Outlook versions should we use to target different web engines while still supporting LaunchEvent?
• Do all BetaChannel versions of Outlook support overriding the engine using the WebViewSelection registry key?
• Do all Outlook versions support RuntimeLogging?

Thanks

** we definitely changed our autorun routine, and we may be missing some polyfill. I just can't get a hint of which.

[pepso]

After Office update 2407 the process of side loading have gotten a step less efficient. Even after removing a side loaded add-in, and ensuring this is the case through "Manage Add-ins" screen and making sure the Ribbon icon is gone, the msoadfsb process kept on hanging on the previously side loaded add-in.

It seems the latest update introduced some changes which makes the add-ins more prone to hang the process by executing code which is not found anymore. What I did find out was the only way to recover from this was to identify a hanging process, kill it, and empty BOTH Wef folder and HubAppFileCache. Followed by restart of Outlook one finally had "normal" state to proceed with attempts to develop / test the code changes.

It is coming ever harder to maintain any sort of coherent development environment for Classic Outlook Launch Events.