# Regression after upgrading Elements from 13.0.0.3081 to 13.0.0.3125 — .resx Icon/Bitmap resources crash .NET Framework 4.8 applications
**URL:** https://talk.remobjects.com/t/regression-after-upgrading-elements-from-13-0-0-3081-to-13-0-0-3125-resx-icon-bitmap-resources-crash-net-framework-4-8-applications/34092
**Category:** Oxygene
**Tags:** visual-studio, oxygene
**Created:** [October 5, 2026, 6:41pm UTC](https://talk.remobjects.com/t/regression-after-upgrading-elements-from-13-0-0-3081-to-13-0-0-3125-resx-icon-bitmap-resources-crash-net-framework-4-8-applications/34092 "2026-10-05T18:41:05Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@claudioh](https://talk.remobjects.com/u/claudioh)
#### Post date: [October 5, 2026, 6:41pm UTC](https://talk.remobjects.com/t/regression-after-upgrading-elements-from-13-0-0-3081-to-13-0-0-3125-resx-icon-bitmap-resources-crash-net-framework-4-8-applications/34092/1 "2026-10-05T18:41:05Z")
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:
```auto
self.NotifyIcon1.Icon :=
(resources.GetObject('NotifyIcon1.Icon') as System.Drawing.Icon);
```
The corresponding `.resx` entry uses this format:
```auto
...
```
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.”
```auto
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 appropriate `DependentUpon` entry.
- 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.Drawing` assembly name does not resolve the inline-image case.
- Compiling the same `.resx` with the .NET Framework `GenerateResource` task produces resources that load correctly.
- In a separate minimal test, referencing an external PNG through `ResXFileRef` also works with EBuild.
- Simply reading and rewriting the original `.resx` using the Framework `ResXResourceWriter` does 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.
---
### Author:  [@mh](https://talk.remobjects.com/u/mh)
#### Post date: [October 5, 2026, 7:54pm UTC](https://talk.remobjects.com/t/regression-after-upgrading-elements-from-13-0-0-3081-to-13-0-0-3125-resx-icon-bitmap-resources-crash-net-framework-4-8-applications/34092/2 "2026-10-05T19:54:39Z")
Reproduced; this is a regression from
Aug 20 `073f505e37bdfee9a39a669e20f69ceffa0764d3` _Improve cross-target RESX processing_. We’ll get this fixed for this week’s build – my sincerest apologies.
---
### Author:  [@mh](https://talk.remobjects.com/u/mh)
#### Post date: [October 5, 2026, 8:52pm UTC](https://talk.remobjects.com/t/regression-after-upgrading-elements-from-13-0-0-3081-to-13-0-0-3125-resx-icon-bitmap-resources-crash-net-framework-4-8-applications/34092/3 "2026-10-05T20:52:11Z")
And fixed, I’ll try and get you a new build today or tomorrow.
---
### Author:  [@claudioh](https://talk.remobjects.com/u/claudioh)
#### Post date: [October 6, 2026, 12:06am UTC](https://talk.remobjects.com/t/regression-after-upgrading-elements-from-13-0-0-3081-to-13-0-0-3125-resx-icon-bitmap-resources-crash-net-framework-4-8-applications/34092/4 "2026-10-06T00:06:23Z")
Thanks, I’m going to start another thread that might be related.