Then the problem is on your machine.
For some complex BPM code blocks I’ve been using Claude to update to EF Core.
AI is usually a good thing to start with. Sadly, Microsoft didn’t do much documentation on how to update EF Classic to EF Core. Most of it was runtime errors, not compile errors, so you don’t even know about it until it breaks. I added some code analyzers that run whenever you save BPM/EF to try to catch some obvious EF Core issues, but there’s no way to catch them all.
When we did have specific application code with EF Core runtime errors, I used AI unless I already knew the issue just by looking at the LINQ query. Some were pretty obvious after you’ve seen it 10 times.
As always with AI don’t trust and always verify.
In 2026.100 some of my BPMs were showing warnings in Conversion Workbench like:
warning ECF9004: The string.Compare function overload is not supported in EF Core. See the String Functions section of the EF 6 to EF Core migration · GitHub
However, rather than just a warning, in 2026.100.5 these were actually causing BPM runtime errors:
Business Layer Exception
BPM runtime caught an unexpected exception of ‘InvalidOperationException’ type.
See more info in the Inner Exception section of Exception Details.Error Detail
Correlation ID: bc28ffda-d514-4a45-9975-b561322b0ace
Description: BPM runtime caught an unexpected exception of ‘InvalidOperationException’ type.
See more info in the Inner Exception section of Exception Details.
Program: Microsoft.EntityFrameworkCore.dll
Method: Translate
Table: undefined
Field: undefined
The offending code was string.Compare statements such as this one:
string.Compare(Part_Row.TypeCode, ttPartRow.TypeCode, true) != 0
100% I was making a joke. I did fix many but as you said, my prompt for the AI grew as we ran into runtime errors even after some of my fixes so I did recruit the AI for help.
I’m a little confused. Do MARS incompatibility issues only come into play if we’re using SqlReader like @hkeric.wci 's example? (which of course we shouldn’t be doing anyways)
Or can it come into play with LINQ queries as well?
@Randy you said in another thread you had 50 BPMs to modify! What were some of the issues?
Based on Haso’s post this is the only thing I’m seeing that I think we need to deal with in our environment:
but based on Randy’s 50 BPMs maybe I am underestimating.
No MARS issues come in if your code has nested calls opening DB objects like:
foreach(var ttOrderDtl_Iterator in ds.OrderDtl.Where(x=> x.Company == Session.CompanyID && (x.RowMod == "A" || x.RowMod == "U")))
{
var Part_Row = Db.Part.With(LockHint.NoLock).Where(x=> x.Company == Session.CompanyID && x.PartNum == ttOrderDtl_Iterator.PartNum && x.CheckBox03).FirstOrDefault();
...
}
That is an open query in the foreach AND the Parts call. So the Parts call can be changed to:
var Part_Row = Db.Part.With(LockHint.NoLock).Where(x=> x.Company == Session.CompanyID && x.PartNum == ttOrderDtl_Iterator.PartNum && x.CheckBox03).ToList();
.ToList() materializes list for use in EFCore Contains()
As I mentioned Claude helped me uplift the BPMs I needed to modify. If you ask it to comment the lines modified it’ll do so and explain the changes. It also cleaned up some un-needed Foreach loops and such as most of our C# BPMs weren’t written by me.
Test the BPMs after uplifting either manually or with AI help of course. Sometimes the AI didn’t quite fix it correctly.
Thanks Randy! I think I understand now.
ToList()-ifying nested LINQs shouldn’t be too difficult. If I actually do want to use a FirstOrDefault for some reason I assume it would work to do a: ToList().FirstOrDefault(); ?
I vaguely recall folks claiming that ToList().FirstOrDefault() was better for performance anyways.
Yes, I believe that ToList().FirstOrDefault() should work fine.
I’m sorry, I don’t know if I’m having a bad day, or if it’s just me, but does anyone else feel like we have not had adequate time to prepare for either of these issues? (Other is to ef core)
Sure we had a webinar / meeting a bit ago, but some of us have thousands of lines of code to review and debug.
I’d like to know if I missed some earlier announcement? When was this first communicated? As well as how?
These are BIG changes.
I’m not trying to stir the pot, unless it needs to be stirred. I honestly want to know if I have a right to be mad, or if it’s my fault?
The first I was aware of it was after 2026.100 got released in pilot. I am not aware of any prior communication or warning.
Pretty sure Linux going live the same weekend as 2026.100 was known early on…but not the EFcore issues.
That was announced a long time ago but completely unrelated to these changes.
Agreed…just throwing the Linux mention out there. 
Yes the Linux conversion has been communicated but the changes to EFCore and removal of MARS --I believe EFCore still allows MARS-- was a shock to me when we got PILOT upgraded to 2026.100
Same…was expecting some hiccups on the First Monday tests…but not to this level. It’s worrisome. We’re three weeks out from go-live and…
Us too and I have a week of vacation so we’re down to TWO weeks here.
My users are finally starting to test and the errors are starting to come in..
Linux + 2026.100 wasn’t enough, they had to pile another thing on too!?
They did say this is when things would break according to the new CI/CD approach.
This is nothing to do with the new CI/CD approach. This is them moving to EFCore and disabling MARS.