Update: I restarted the upgrade and followed the sequence below and was able to make it work until I upgraded CMS but as soon as I upgraded Commerce, it started throwing error. So the issue is not with EPiserver Framework version but Commerce version.

• Upgrade EPiServer Find related packages - No issue
• Upgrade TinyMce and EPiServer Forms - No issue
• Upgrade EPiServer ServiceAPI and ImageSharp - No issue
• Upgrade EPiServer and AspnetCore packages from 12.21.7 to 12.22.0 - No issue
• Upgrade Commerce.UI+Personalization.Commerce+Tracking.Commerce from 14.23 to 14.28 - No issue
• Upgrade Commerce 14.28.0 to 14.29.0 = Failed with above error

Thanks for the report. We are aware Commerce has an old dependency to BinaryFormatter. We know how to remove the dependency but it is some work, especially doing it without breaking changes. I have brought this up for prioritization again, but for now Commerce can only run on .NET 8.

Thanks @Magnus. 

After failing to make it work with 14.29.0 I tested following two scenarios. Sharing in case someone else encounters and it may help them.

• If you upgrade from 14.29.0 to 14.30.0 the solution loads without any error.
• If you upgrade directly from older version of Commerce to 14.30.0, it fails to load the site with expected BinaryFormatter error. 

Conclusion: We will use .NET 8 for the time being. 

I noticed too that I sometimes got an error already in startup, in another project I didn't. But you will get an error as soon as you publish a product update (or price update etc). So it is not currently usable on .NET 9.

There is an official compatibility package available on NuGet: https://www.nuget.org/packages/System.Runtime.Serialization.Formatters

It enabled us to use CMS 12 with .NET 9. But it's great to hear that Optimizely is working on replacing BinaryFormatter with something modern and more secure!

Oh, really? Surprised it works as a drop-in replacement without any changes to our code. Thanks for the tip!

We're going to rip it out anyway I think, it isn't actually needed for anything, it is a legacy to send remote events from the time when there was a separate Content Manager application. We can solve the same thing using regular in-process events now.

Hi

Has anyone tested with placing an order? I received "Type provided must be an Enum" exception from calling OrderRepository Save method

  System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
       ---> System.ArgumentException: Type provided must be an Enum.
         at System.ComponentModel.EnumConverter..ctor(Type type)
         at Mediachase.Commerce.Shared.ResourceEnumConverter..ctor(Type type)
         at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
         at System.Reflection.MethodBaseInvoker.InvokeDirectByRefWithFewArgs(Object obj, Span`1 copyOfArgs, BindingFlags invokeAttr)
         --- End of inner exception stack trace ---
         at System.Reflection.MethodBaseInvoker.InvokeDirectByRefWithFewArgs(Object obj, Span`1 copyOfArgs, BindingFlags invokeAttr)
         at System.Reflection.MethodBaseInvoker.InvokeWithOneArg(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
         at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
         at System.Reflection.ConstructorInfo.Invoke(Object[] parameters)
         at System.ComponentModel.ReflectTypeDescriptionProvider.CreateInstance(Type objectType, Type callingType)
         at System.ComponentModel.ReflectTypeDescriptionProvider.ReflectedTypeData.GetConverter(Object instance, Boolean verifyIsRegisteredType)
         at System.ComponentModel.TypeDescriptor.DefaultTypeDescriptor.GetConverter()
         at System.ComponentModel.TypeDescriptor.GetConverter(Type type)
         at Newtonsoft.Json.Serialization.JsonTypeReflector.CanTypeDescriptorConvertString(Type type, TypeConverter& typeConverter)
         at Newtonsoft.Json.Serialization.DefaultContractResolver.CanConvertToString(Type type)
         at Newtonsoft.Json.Serialization.DefaultContractResolver.CreateContract(Type objectType)
         at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
         at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeObject(JsonWriter writer, Object value, JsonObjectContract contract, JsonProperty member, JsonContainerContract collectionContract, JsonProperty containerProperty)
         at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeValue(JsonWriter writer, Object value, JsonContract valueContract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerProperty)
         at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.Serialize(JsonWriter jsonWriter, Object value, Type objectType)
         at Newtonsoft.Json.JsonSerializer.SerializeInternal(JsonWriter jsonWriter, Object value, Type objectType)
         at Newtonsoft.Json.JsonConvert.SerializeObjectInternal(Object value, Type type, JsonSerializer jsonSerializer)
         at EPiServer.Commerce.Order.Internal.DataAccess.SerializableCartDB.Save(SerializableCart cart)
         at EPiServer.Commerce.Order.Internal.SerializableCartProvider.Save(ICart cart)
         at EPiServer.Commerce.Order.Internal.DefaultOrderRepository.Save(IOrderGroup order)

Bumping this. Does anyone know if commerce works with .NET 9 (or newer) yet?

I second to Andreas post - the .NET 8 end of support is 10th of November 2026.
https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core

We can safely assume that CMS 13 and Commerce 15 will support .NET 10 when they will be released, but I don't think all current projects will migrate to 13/15 before November, so some plan must exist for existing projects, but we didn't get anywhere clear communitcation in this regard.

We understand the situation. Our focus now is 100% getting CMS 13 and Commerce 15 to .NET 10 support first, as the preferred path. But we are going to validate .NET 10 compatibility in CMS 12 after CMS 13 is released. How that turns out also affects the plan for Commerce 14 vs .NET 10. But in the Commerce case we know we have to make changes to the BinaryFormatter usage. Those are technically going to be breaking, but we'll do our best to find a pragmatic path forward there even though it might not be technically correct versioning wise or particularly clean on upgrades (the dependency version range between Commerce.Core and Find.Commerce which uses the BinaryFormatter based event channel is the known challenge, then there may be more yet unknown challenges).

Thanks for the update, Magnus — it's good to hear this is on the radar.

That said, the BinaryFormatter dependency was identified in November 2024, and with .NET 8 reaching end of support in November 2026, the remaining time is getting quite short. I understand the focus on CMS 13 / Commerce 15 for .NET 10, but for teams running CMS 12 / Commerce 14 in production, we seem to be left on unsupported runtime.
It's a very different situation to Commerce 13, where the .NET Framework is still supported by Microsoft.
Is there any indication that the Commerce 14 would support .NET 10 before November?