System Memory Exception
When developers use the latest version of IronOCR on the .NET Framework, there are instances where running the program would result in a System.Memory Exception, as shown below.
Could not load file or assembly 'System.Memory, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)Although this issue is not directly related to IronOCR itself, there are known compatibility challenges with System.Memory dependencies. Even when a newer version of System.Memory (e.g., 4.4.5 or later) is installed - whether as part of another dependency or as a direct reference - the runtime may still throw version-related errors.
This occurs because some dependencies enforce strict version binding, meaning they expect a specific version of System.Memory, regardless of whether a newer, theoretically compatible version is present. As a result, the error persists unless we apply the workaround described below.
Solution
The solution to this exception is to modify the App.config with the code below.
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Memory" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.0.1.2" newVersion="4.0.1.2" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>Explanation
The modified App.Config aims to prevent version conflicts that may arise when multiple dependencies require different versions of the same assembly. By using this configuration, the application will load the appropriate version at runtime. The redirect forces all components to use version v4.0.1.2, thereby eliminating the potential for the aforementioned exception. After modifying the App.Config, please re-run the application to ensure the program doesn't raise another exception.
For further information and discussions on this topic, you can visit the GitHub page that details the exception and the current workaround here.
Curtis Chau holds a Bachelor’s degree in Computer Science (Carleton University) and specializes in front-end development with expertise in Node.js, TypeScript, JavaScript, and React. Passionate about crafting intuitive and aesthetically pleasing user interfaces, Curtis enjoys working with modern frameworks and creating well-structured, visually appealing manuals.
