Native EBuild-generated image and icon resources fail at runtime on .NET 10 — BinaryFormatter dependency

Elements Oxygene
,
1

I would like to report a resource compatibility issue with .NET 10 that appears to be distinct from the RESX regression I previously reported.

The previous issue affected .NET Framework 4.8 after upgrading to Elements 13.0.0.3125, producing the error “The input stream is not a valid binary format.” Your team reproduced that regression and announced a fix. Downgrading to 13.0.0.3081 restored the .NET Framework application’s behavior.

However, the following .NET 10 issue also occurs with 13.0.0.3081.

Environment:

  • Oxygene / Elements / EBuild 13.0.0.3081
  • .NET SDK 10.0.302
  • Microsoft.WindowsDesktop.App 10.0.10
  • Target: .NET 10, Windows, x86
  • Visual Studio 2026; the reproduction was built directly with EBuild.

We created an isolated Oxygene test project with a newly created .resx containing:

  • A string.
  • A ResXFileRef referencing a newly generated PNG as System.Drawing.Bitmap.
  • A ResXFileRef referencing an ICO file as System.Drawing.Icon.

These were new test resources, not resources copied from our legacy application.

The project uses the standard EmbeddedResource approach, as shown in the installed WinForms Core template, without external resource generation:

<TargetFramework>.NET10.0-windows</TargetFramework>
<NETCoreRuntime>Microsoft.WindowsDesktop.App</NETCoreRuntime>
<NETCoreRuntimeVersion>10.0.10</NETCoreRuntimeVersion>
<NETCoreSDKVersion>10.0.302</NETCoreSDKVersion>

<EmbeddedResource Include="Resources.resx">
  <LogicalName>ProvaRecursos.Resources.resources</LogicalName>
</EmbeddedResource>

After a successful build, the test reads each resource using System.Resources.ResourceManager.GetObject.

Results:

Test Result
Native EBuild compilation Successful
String resource Loaded successfully
Bitmap resource Failed
Icon resource Failed

Both the bitmap and icon fail with:

System.NotSupportedException:
BinaryFormatter serialization and deserialization are disabled within this application.
See https://aka.ms/binaryformatter for more information.

In our actual .NET 10 application, generating resources separately through the Microsoft SDK’s GenerateResource task with UsePreserializedResources="true" works. EBuild then embeds the generated .resources files.

However, our goal is to use native resource processing directly from .resx, as we would expect for a new Oxygene .NET 10 application, without maintaining a separate resource-generation project and resource list.

Could you please clarify:

  1. Is there a supported EBuild setting to generate image and icon resources that load correctly on .NET 10 without enabling BinaryFormatter?
  2. Is the direct EmbeddedResource approach the recommended configuration for a new Oxygene WinForms application targeting .NET 10?
  3. Is this behavior related to the previously acknowledged RESX regression, or does it require a separate fix?

Thank you.

2

Reated to the previous reort, but not quite the same issue indeed. we’re investigating.

3

I’ve uploaded RemObjects Elements with Water - 13.0.0.3138.exe, can you check if both issues are addressed for you?

4

Yes, I tested Elements 13.0.0.3138, but encountered additional compilation problems that prevented me from validating the original RESX fix at runtime.

Our previous version was 13.0.0.3081. With 3138, the builds reported:

  • .NET Framework 4.8 Client: 13 errors.
  • .NET 10 Server: 4,115 errors, potentially including cascading diagnostics.

The errors affect existing Oxygene code and appear to involve the resolution of parameterless method calls without parentheses. Expressions previously evaluated as method calls now appear to be treated as method groups.

Examples from the compiler output:

Parameter 1 is "<method group>", should be "IWin32Window",
in call to XtraBaseArgs.<Write>Owner(value: IWin32Window)

No overloaded method "Append" with these parameters on type "StringBuilder",
best matching overload is "Append(value: UInt64): StringBuilder"

No overloaded method "ToString" with these parameters on type "Double",
best matching overload is "ToString(provider: IFormatProvider): String"

There are also similar errors involving DateTime.ToString, String.Format, and MessageBox.Show.

The builds were run directly through EBuild. We have not changed the affected calls or compiler settings to work around this behavior.

Could this be another regression in 3138 related to implicit invocation of parameterless methods?

5

Curious, these are unrelated; could I see the code snippets that cause these? Not much has changed compiler-side since 13.0.0.3125, I believe, aside from the Delphi compatibility changes that landed; these sound possibly related…

6

Here are three actual source excerpts that produce errors with 13.0.0.3138.

Both affected projects have this setting enabled:

<DelphiCompatibility>True</DelphiCompatibility>

For clarity, our previous working version was 13.0.0.3081; we are not comparing against 3125.

1. Parameterless ToString passed to StringBuilder.Append

Source: [ChamadaController.pas, line 219 (line 219)](/C:/Sistemas/ProjetoPegasusOOPrism/PegasusCore/PegasusServerCore/Controllers/ChamadaController.pas:219)

var TextoToolTip := new StringBuilder;
for DR: DataRow in DTGuardiao.Rows do
  TextoToolTip.Append(DR['CODLOJA'].ToString)
               .Append(' - ')
               .Append(DR['NOMELOJA'].ToString)
               .Append(DR['COMENTARIO'].ToString)
               .Append(Environment.NewLine);

Compiler output:

No overloaded method "Append" with these parameters on type "StringBuilder",
best matching overload is "Append(value: UInt64): StringBuilder"

parameter 1 is "<method group>" should be "UInt64"

2. Parameterless method returning IWin32Window

Source: [USoftSystemINIGenerica.pas, line 8513 (line 8513)](/C:/Sistemas/ProjetoPegasusOOPrism/UnitsCompartilhadas/USoftSystemINIGenerica.pas:8513)

The method is declared as:

method get_MessageBoxOwner: System.Windows.Forms.IWin32Window;

The failing call is:

var args : XtraMessageBoxArgs = new XtraMessageBoxArgs();
args.Owner := get_MessageBoxOwner;

Compiler output:

Parameter 1 is "<method group>", should be "IWin32Window",
in call to XtraBaseArgs.<Write>Owner(value: IWin32Window)

3. Parameterless ToString used as a numeric format string

Source: [UCGeraRelatorios.pas, line 1105 (line 1105)](/C:/Sistemas/ProjetoPegasusOOPrism/Client/Relatorio/UCGeraRelatorios.pas:1105)

Here, Valores is an array of Double, and DTCampos is a DataTable:

Valor := DTCampos.rows[i]['TextoTotalizacao'].tostring + ' ' +
         Valores[I].ToString(DTCampos.rows[i]['Mascara'].tostring);

Compiler output:

No overloaded method "ToString" with these parameters on type "Double",
best matching overload is "ToString(provider: IFormatProvider): String"

parameter 1 is "<method group>" should be "IFormatProvider"

The common pattern appears to be a parameterless method referenced without (), where its return value is expected. These examples come directly from our projects; we have not yet tested whether adding parentheses or disabling Delphi compatibility changes the result.

7

Ah, okay, that explains it, I think. My colleague is having a look to see whether these are regressions or expected changes.

Does adding () to the methid call [should not be necessary, i agree] alleviate any of these trhee cases?

8

es, adding () resolves these three cases.

However, requiring this change would disrupt our maintenance workflow. We regularly compile older versions of our system to release fixes. Those versions still contain the existing syntax, so we would have to keep switching Oxygene versions to build them.

Preserving compatibility with this syntax would therefore be important for us.

9

I agree. I asked this only to help narrow it down, not to imply thats the actual solution. This is Pascal, not C. Using Delphi compatibility should not make it less compatible with Pascal conventions ;).

() should only be required in extreme ambiguituy cases (eg calling a delegate vs. using its value)

10

were you able to identify this case of ( )

11

Uploaded a new RemObjects Elements - 13.0.0.3138 (B).exe for you that has the resources fixes AND th compiler regression fixes. :crossed_fingers:

No designer yet :wink:

12

Hi Marc,

We tested 13.0.0.3138 (20261007-105612):

  • Both RESX issues passed: images/icons load correctly in .NET Framework 4.8, and native EBuild resources load in .NET 10 without the previous BinaryFormatter errors. Our complete client also passed: 695 resource entries loaded successfully, without our custom resource-generation workaround.

  • One method-call issue remained: ToStr is our parameterless extension method on Object, returning String. This previously valid code failed:

    Pegasus.Append(DR[I].ToStr);

    Error:

    No overloaded method "Append" with these parameters on type
"StringBuilder", best matching overload is
"Append(value: UInt64): StringBuilder"

    We manually replaced .ToStr with .ToString at four call sites, which allowed compilation. This is our workaround, rather than confirmation that the original syntax is fixed.

  • We found an encoding regression: Windows-1252 .pas files without BOM, which worked in 3081, now produce corrupted literals:

    Memória Física → Mem�ria F�sica

    A minimal test confirmed that Windows-1252 fails, while UTF-8 with or without BOM works. Source bytes remain unchanged; the corruption is already in the compiled assembly.

Is the encoding change intentional? Is there a compiler/project setting to retain Windows-1252 compatibility? This matters when rebuilding older branches for maintenance fixes.

Thanks!

13

@david.millington ^^^

14

This encoding issue is causing me quite a bit of trouble, if you can get a hotfix for it as well

15

We’re working on it.

16

RemObjects Elements - 13.0.0.3138 (G).exe should include this fix as well. As will today’s official build.

17

I repeated the original minimal reproduction using byte-for-byte identical source files, a fresh output directory and --rebuild.

Source file encoding .NET Framework 4.8 .NET 10
Windows-1252, without BOM Incorrect characters Incorrect characters
UTF-8 with BOM Correct Correct
UTF-8 without BOM Correct Correct

For example, this string literal in a Windows-1252 source file:

Memória Física Instalada | Configurações do Servidor | Descrição

Returns the following when executing the compiled method:

Mem�ria F�sica Instalada | Configura��es do Servidor | Descri��o

The replacement characters are U+FFFD in the compiled string, so this is not merely a console or UI display issue.

The original source bytes are valid Windows-1252 and remain unchanged. The behavior still appears consistent with interpreting those bytes as UTF-8.

Could you please investigate this remaining issue in build 20261009-115312 / 21ee3c5?

18

This is unrelated and is “as designed”.

Oxygene was changed to treat BOM-less source files as UTF-8 rather than “system default”. This was becoming necessary because the system default differs widely (e.g., on macOS it is UTF-8), and we kept having errors where files were just fine when built and worked on on Mac, and then building the same file on Windows would fail (best case) or have bad encodings in string literals (worse). Having a consistent default across platforms was imperative.

Three options:

  • save your files with a proper BOM
  • save your files as UTF-8 (w/ or w/o BOM, though I’d suggest with.)
  • Set the DefaultCodePage setting in your project to the code page you want BOM-less files to default to.

Option two with BOM is my suggested option. Fire/Water already always saves files with a proper BOM.

19

I’m going to adapt to the new encoding method and analyze which option works best for my situation.