# Wyjątek pamięci systemowej
Gdy deweloperzy używają najnowszej wersji IronOCR w .NET Framework, są przypadki, w których uruchomienie programu spowoduje `System.Memory Exception`, jak pokazano poniżej.
```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)
```
Chociaż ten problem nie jest bezpośrednio związany z samym IronOCR, istnieją znane problemy z kompatybilnością z zależnościami System.Memory. Nawet gdy zainstalowana jest nowsza wersja System.Memory (np. 4.4.5 lub późniejsza) - czy to jako część innej zależności, czy jako bezpośrednie odniesienie - środowisko uruchomieniowe wciąż może rzucać błędami związanymi z wersją.
Dzieje się tak, ponieważ niektóre zależności wymuszają ścisłe wiązanie wersji, co oznacza, że oczekują konkretnej wersji System.Memory, niezależnie od tego, czy jest dostępna nowsza, teoretycznie kompatybilna wersja. W efekcie błąd utrzymuje się, dopóki nie zastosujemy obejścia opisanego poniżej.
## Rozwiązanie
Rozwiązaniem tego wyjątku jest modyfikacja `App.config` z poniższym kodem.
```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>
```
## Wyjaśnienie
Zmodyfikowany `App.Config` ma na celu uniknięcie konfliktów wersji, które mogą się pojawić, gdy różne zależności wymagają różnych wersji tej samej biblioteki. Stosując tę konfigurację, aplikacja załaduje odpowiednią wersję podczas działania programu. Przekierowanie wymusza, aby wszystkie komponenty używały wersji `v4.0.1.2`, eliminując w ten sposób potencjalny wyjątek wspomniany wcześniej. Po zmodyfikowaniu `App.Config`, prosimy o ponowne uruchomienie aplikacji, aby upewnić się, że program nie generuje kolejnego wyjątku.
Aby uzyskać więcej informacji i dyskusji na ten temat, można odwiedzić stronę GitHub, która szczegółowo opisuje wyjątek i obecne obejście [tutaj](https://github.com/dotnet/SqlClient/issues/2082#issuecomment-2195231049).
Gdy deweloperzy używają najnowszej wersji IronOCR w .NET Framework, są przypadki, w których uruchomienie programu spowoduje System.Memory Exception, jak pokazano poniżej.
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
Chociaż ten problem nie jest bezpośrednio związany z samym IronOCR, istnieją znane problemy z kompatybilnością z zależnościami System.Memory. Nawet gdy zainstalowana jest nowsza wersja System.Memory (np. 4.4.5 lub późniejsza) - czy to jako część innej zależności, czy jako bezpośrednie odniesienie - środowisko uruchomieniowe wciąż może rzucać błędami związanymi z wersją.
Dzieje się tak, ponieważ niektóre zależności wymuszają ścisłe wiązanie wersji, co oznacza, że oczekują konkretnej wersji System.Memory, niezależnie od tego, czy jest dostępna nowsza, teoretycznie kompatybilna wersja. W efekcie błąd utrzymuje się, dopóki nie zastosujemy obejścia opisanego poniżej.
Rozwiązanie
Rozwiązaniem tego wyjątku jest modyfikacja App.config z poniższym kodem.
Zmodyfikowany App.Config ma na celu uniknięcie konfliktów wersji, które mogą się pojawić, gdy różne zależności wymagają różnych wersji tej samej biblioteki. Stosując tę konfigurację, aplikacja załaduje odpowiednią wersję podczas działania programu. Przekierowanie wymusza, aby wszystkie komponenty używały wersji v4.0.1.2, eliminując w ten sposób potencjalny wyjątek wspomniany wcześniej. Po zmodyfikowaniu App.Config, prosimy o ponowne uruchomienie aplikacji, aby upewnić się, że program nie generuje kolejnego wyjątku.
Aby uzyskać więcej informacji i dyskusji na ten temat, można odwiedzić stronę GitHub, która szczegółowo opisuje wyjątek i obecne obejście tutaj.
Curtis Chau posiada tytuł licencjata z informatyki (Uniwersytet Carleton) i specjalizuje się w front-endowym rozwoju, z ekspertką w Node.js, TypeScript, JavaScript i React. Pasjonuje się tworzeniem intuicyjnych i estetycznie przyjemnych interfejsów użytkownika, Curtis cieszy się pracą z nowoczesnymi frameworkami i tworzeniem dobrze zorganizowanych, atrakcyjnych wizualnie podręczników.
