Hello RemObjects team,
We encountered a resource-loading regression after upgrading Elements/EBuild:
- Previously working version: 13.0.0.3081
- Version exhibiting the problem: 13.0.0.3125
Our existing Oxygene Windows Forms applications, targeting .NET Framework 4.8, worked with version 13.0.0.3081. After upgrading to 13.0.0.3125 and rebuilding, they compile successfully but crash at runtime when loading certain System.Drawing.Icon and System.Drawing.Bitmap resources through ResourceManager.GetObject.
The problem affects both our desktop client and our legacy server application. Previously compiled executables load the corresponding resources successfully, while the newly compiled executables fail.
Our environment:
- Visual Studio 2026.
- Oxygene / Windows Forms.
- Affected applications target .NET Framework 4.8.
- The problem has been reproduced in both Debug and Release builds.
We have not tested the intermediate Elements versions, so we cannot yet identify the first build that introduced the regression.
For example, our server crashes during startup at this line:
self.NotifyIcon1.Icon :=
(resources.GetObject('NotifyIcon1.Icon') as System.Drawing.Icon);
The corresponding .resx entry uses this format:
<data name="NotifyIcon1.Icon"
type="System.Drawing.Icon, System.Drawing"
mimetype="application/x-microsoft.net.object.bytearray.base64">
<value>...</value>
</data>
The Base64 value contains ICO data. Its initial bytes match those shown in the exception.
This is the actual error reported by the application. The message is in Portuguese; its English equivalent is “The input stream is not a valid binary format.”
Erro - v.2.3.13.521
OnUnhandledException
IsTerminating: True
Message: O fluxo de entrada não está em um formato binário válido.
O conteúdo inicial (em bytes) é:
00-00-01-00-04-00-10-10-00-00-00-00-20-00-68-04-00 ...
Source: mscorlib
StackTrace:
em System.Runtime.Serialization.Formatters.Binary.SerializationHeaderRecord.Read(__BinaryParser input)
em System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadSerializationHeaderRecord()
em System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
em System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
em System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
em System.Resources.ResourceReader.DeserializeObject(Int32 typeIndex)
em System.Resources.ResourceReader.LoadObjectV2(Int32 pos, ResourceTypeCode& typeCode)
em System.Resources.RuntimeResourceSet.GetObject(String key, Boolean ignoreCase, Boolean isString)
em System.Resources.ResourceManager.GetObject(String name, CultureInfo culture, Boolean wrapUnmanagedMemStream)
em Server.MainForm.InitializeComponent()
na C:\Sistemas\ProjetoPegasusOOPrism\Server\UCTMainServerAutenticacao.Designer.pas:linha 661
em Server.MainForm..ctor(String aModoInicializacao)
na C:\Sistemas\ProjetoPegasusOOPrism\Server\UCTMainServerAutenticacao.pas:linha 436
em Server.Program.Main()
na C:\Sistemas\ProjetoPegasusOOPrism\Server\Program.pas:linha 64
Our investigation found the following:
- The resource is present and found successfully. This is not a
MissingManifestResourceException, and the project already contains the appropriateDependentUponentry. - The same failure also occurs with inline PNG resources, where the exception shows the PNG signature
89-50-4E-47.... - A minimal Oxygene project reproduces the problem without DevExpress.
- Fully qualifying the
System.Drawingassembly name does not resolve the inline-image case. - Compiling the same
.resxwith the .NET FrameworkGenerateResourcetask produces resources that load correctly. - In a separate minimal test, referencing an external PNG through
ResXFileRefalso works with EBuild. - Simply reading and rewriting the original
.resxusing the FrameworkResXResourceWriterdoes not resolve the problem when the resulting file is compiled by EBuild.
Inspection of the installed EBuild assembly suggests that ResGen.CompileResourceFile obtains raw bytes through ResXDataNode.TryGetByteArrayResourceData and passes them to ResourceWriter.AddResourceData. For these Icon/Bitmap entries, the data appears to remain raw ICO/PNG bytes, while the .NET Framework resource reader expects a serialized object.
Could you please verify whether this is a known regression and whether it has been fixed in a newer build? We checked the published changes through preview 13.0.0.3137, but did not find an explicit reference to this problem. We have not yet tested that preview.
We would prefer to retain the standard .resx / EmbeddedResource build workflow without introducing custom resource-generation steps or changing resources individually throughout the applications.
We have prepared a minimal reproduction project and can provide it if needed.
Thank you.