No one here is against containers. It’s Epicor pathetic rollout of them that has people upset.
There are some gotchas with type conversion in .net 9+ and linux (see method at end of post my comments basically good for once) and they have tripped me up when I have had to map across your REST objects, they are around simple types with a subtle difference between .net windows and .net linux due to hosts (you hit these when doing comparisons on simple types)
docker really doesnt like mixing async and non async code. The os kernal will loose track of the async call if you get stuck on an non async code call and the container will lock, these manifest around http calls.
Im sure you team have this wrapped up but these are helpfull to know how MS have built the reference container image:
Environment.GetEnvironmentVariable(“DOTNET_RUNNING_IN_CONTAINER”)
and err
RuntimeInformation.IsOSPlatform(OSPlatform.Windows) //because Ive got bitten by / and \ too ![]()
If you are getting hangs for ‘no’ reason let me know and I can drop in my watchdog method for debugging async.
// NOTE:
// This mapping logic originally failed to copy nullable types like double? correctly,
// especially when running on Linux. The issue stemmed from the IsSimpleType() method,
// which didn't account for Nullable<T> wrappers. Although double? is a value type,
// reflection treats it as Nullable<double>, and the original check missed it.
//
// FIX:
// Updated IsSimpleType() to unwrap Nullable<T> using Nullable.GetUnderlyingType(),
// ensuring that types like double?, int?, and other nullable primitives are correctly
// identified as simple and mapped.
//
// This fix improves cross-platform compatibility (Windows vs Linux) and ensures
// reliable property mapping for all simple and nullable types.
private static bool IsSimpleType(Type type)
{
var underlyingType = Nullable.GetUnderlyingType(type);
type = underlyingType ?? type;
return type.IsPrimitive
|| type.IsEnum
|| type == typeof(string)
|| type == typeof(DateTime)
|| type == typeof(decimal)
|| type == typeof(Guid); // optionally
}
Did anyone start testing the linux the linux containers yet? any issues?
See this thread:
Ours can’t talk to our Azure File Share, so labels are busted.
Labels busted over here too. Just put in a ticket in epiccare because I have no idea what I should be doing right now.
Same…opened ticket Friday, provided requested info, haven’t heard from them since. Gonna be a goooooooooooooooood week.
EDIT - escalated it FWIW…we’ll see if that gets anywhere
It’s absolutely ridiculous and unacceptable they moved forward with this Linux migration with no notice and known issues. Such as Azure File Share not working for things like labels. And the other known issues.
Same here. Except I am getting an error when trying to connect to the Bartender Drive.
Program Ice.Services.Lib.RunTask when executing task 1548343 raised an unexpected exception with the following message: RunTask:
System.UnauthorizedAccessException: Access to the path is denied.
—> System.IO.IOException: Permission denied
Almost all of my custom reports also have an error where the report style cannot be found.
19 pages of custom code from the custom code report
. Should we look this over? How many pages do you all have?
That report is useless. It reports every time you use a widget, and it reports on their own built in stuff which is by definition . . . NOT CUSTOM. Whoever designed it didn’t spend 5 seconds to make it the least bit usable.
AI models can’t generate code that fast, it was at least 45 seconds
Seems like anything involving a filepath is now broken…BT labels and EDI in/out are the two biggest hits for us right now. Just got done pulling error logs and adding example after example to our ticket.
I had a function go into “Disabled” mode because Epicor decided to run their auto-mess-with-your-code function that supposedly seamlessly converts filepaths to use the new syntax..
It converted some regex that was not at all a filepath to call ConvertPath() function.. and then of course that wouldnt compile so it got disabled.
I just clobbered it with a copy i had solution’ed up, and moved on. I know im not the only one that’s happened to.
It’s just funny because i’m on Flex 2 and my non prods were supposedly not affected by this “maintenance” - per the notice at the bottom that it doesnt affect flex customers… and all my non prods are still on Windows. But yet, they decided to mess with my code. lol
Agreed anything that needs to read or write via a filepath is broken now. ![]()
Brilliant!
Regarding reaching the MES:
Thank you for your patience. We have reported this issue as a defect, and our teams are currently working on a fix. Once the fix is available, it will be published in the PRB linked to this case.
This issue affects only the Kinetic UI (both smart client and web). Classic MES remains fully functional and is not impacted.
At this time, the only available workaround is to continue using the Classic MES UI.
You mean the interface you are forcing us to us after May?
Now got to check labels.
And AZ file share no longer works from Pilot systems unless using a classic interface.
I was going to sarcastically say “Do they test?”.
But no they don’t, they could not possibly have tested this.
I wonder if they somehow broke passing the variables in from the url with ? so it doesn’t see the ?mode=dc parameter.. oof.
It still issues a Data Collection license so it must see the call just not go to the MES screen. ![]()
If you get the DC license, what happens if you try to go to the correct URL manually afterwards?
Terrible feeling.