When is your code run?
Try runing your code on an earlier stage. ex at the same stage as you run Geta.NotFoundHandler.Infrastructure.Initialization.NotFoundHandlerMiddleware. Or use a Migrationstep.
I would start with checking the database. Is there any rows in tblScheduledItem
matching that Forms assembly?
If so, first delete all rows matching that jobs ID from tblScheduledItemLog
and then finally delete the job from tblScheduledItem
.
There are no rows in either tblScheduledItem or in tblScheduledItemLog containing Forms. I did just found a sole record in tblPlugin for the Forms assembly, deleting that resolved the problem! At least locally it did. What's the best way to remove this record on our DXP environments, where we (at least me, a power user) don't have direct access to the databases?
You can contact support@optimizely.com and provide them with the SQL query you want executed on the production environment.
When we go into our CMS 12 admin interface and open up the scheduled jobs page, nothing shows on the page. Looking at the logs we see an exception saying it could not load file or assembly EPiServer.Forms.UI, which makes sense because we haven't used Forms in the past two years or so. But apparently, its scheduled jobs are still in the database somewhere.
I have tried deleting these misbehaving by running the following code:
In the first run it matched two jobs to be deleted. Rerunning it will result in no matches. However, the error stubbornly remains the same. I have restarted the app in case of caching.
While scouring this forum, I came across the thread (Cannot load content types or schedules jobs after upgrade to CSM) that describes something very similar. The content types page loads just fine for us. We have tried the mentioned SQL delete statements, but that also had no effect.
We have all packages up to date (12.7.0). Any help with this would be greatly appreciated.
The exception we're getting: