# Systemspeicherausnahme
Wenn Entwickler die neueste Version von IronOCR auf dem .NET Framework verwenden, gibt es Fälle, in denen das Ausführen des Programms zu einem `System.Memory Exception` führt, wie unten gezeigt.
```txt
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)
```
Obwohl dieses Problem nicht direkt mit IronOCR selbst zusammenhängt, gibt es bekannte Kompatibilitätsprobleme mit System.Memory-Abhängigkeiten. Selbst wenn eine neuere Version von System.Memory (z.B. 4.4.5 oder später) installiert ist—entweder als Teil einer anderen Abhängigkeit oder als direkte Referenz—kann die Laufzeit weiterhin versionsbedingte Fehler auslösen.
Dies geschieht, weil einige Abhängigkeiten strikte Versionsbindung erzwingen, was bedeutet, dass sie eine spezifische Version von System.Memory erwarten, unabhängig davon, ob eine neuere, theoretisch kompatible Version vorhanden ist. Infolgedessen bleibt der Fehler bestehen, es sei denn, wir wenden die unten beschriebene Problemumgehung an.
## Lösung
Die Lösung für diese Ausnahme besteht darin, den `App.config` mit dem unten stehenden Code zu ändern.
```xml
<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>
```
## Erklärung
Der modifizierte `App.Config` zielt darauf ab, Versionskonflikte zu vermeiden, die auftreten können, wenn mehrere Abhängigkeiten unterschiedliche Versionen derselben Assembly erfordern. Durch die Verwendung dieser Konfiguration wird die Anwendung zur Laufzeit die geeignete Version laden. Der Redirect zwingt alle Komponenten, Version `v4.0.1.2` zu verwenden, wodurch das Potenzial für die oben erwähnte Ausnahme beseitigt wird. Nachdem Sie den `App.Config` geändert haben, führen Sie bitte die Anwendung erneut aus, um sicherzustellen, dass das Programm keine weitere Ausnahme auslöst.
Für weitere Informationen und Diskussionen zu diesem Thema können Sie die GitHub-Seite besuchen, die die Ausnahme und die aktuelle Problemumgehung [hier](https://github.com/dotnet/SqlClient/issues/2082#issuecomment-2195231049) im Detail beschreibt.
Wenn Entwickler die neueste Version von IronOCR auf dem .NET Framework verwenden, gibt es Fälle, in denen das Ausführen des Programms zu einem System.Memory Exception führt, wie unten gezeigt.
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)
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)
Text
Obwohl dieses Problem nicht direkt mit IronOCR selbst zusammenhängt, gibt es bekannte Kompatibilitätsprobleme mit System.Memory-Abhängigkeiten. Selbst wenn eine neuere Version von System.Memory (z.B. 4.4.5 oder später) installiert ist—entweder als Teil einer anderen Abhängigkeit oder als direkte Referenz—kann die Laufzeit weiterhin versionsbedingte Fehler auslösen.
Dies geschieht, weil einige Abhängigkeiten strikte Versionsbindung erzwingen, was bedeutet, dass sie eine spezifische Version von System.Memory erwarten, unabhängig davon, ob eine neuere, theoretisch kompatible Version vorhanden ist. Infolgedessen bleibt der Fehler bestehen, es sei denn, wir wenden die unten beschriebene Problemumgehung an.
Lösung
Die Lösung für diese Ausnahme besteht darin, den App.config mit dem unten stehenden Code zu ändern.
Der modifizierte App.Config zielt darauf ab, Versionskonflikte zu vermeiden, die auftreten können, wenn mehrere Abhängigkeiten unterschiedliche Versionen derselben Assembly erfordern. Durch die Verwendung dieser Konfiguration wird die Anwendung zur Laufzeit die geeignete Version laden. Der Redirect zwingt alle Komponenten, Version v4.0.1.2 zu verwenden, wodurch das Potenzial für die oben erwähnte Ausnahme beseitigt wird. Nachdem Sie den App.Config geändert haben, führen Sie bitte die Anwendung erneut aus, um sicherzustellen, dass das Programm keine weitere Ausnahme auslöst.
Für weitere Informationen und Diskussionen zu diesem Thema können Sie die GitHub-Seite besuchen, die die Ausnahme und die aktuelle Problemumgehung hier im Detail beschreibt.
Curtis Chau hat einen Bachelor-Abschluss in Informatik von der Carleton University und ist spezialisiert auf Frontend-Entwicklung mit Expertise in Node.js, TypeScript, JavaScript und React. Leidenschaftlich widmet er sich der Erstellung intuitiver und ästhetisch ansprechender Benutzerschnittstellen und arbeitet gerne mit modernen Frameworks sowie der Erstellung gut strukturierter, optisch ansprechender Handbücher.
