MessagingToolkit.BarCode wymieniaSilverlight 5i Windows Phone 7 jako platformy docelowe. Oba produkty zostały wycofane z rynku wiele lat temu. Jeśli ta biblioteka jest w twojej bazie kodów, zamiana jest praktycznym następnym krokiem.

Zrozumienie MessagingToolkit.BarCode

MessagingToolkit.BarCode był portem biblioteki kodów kreskowych Java ZXing na platformę .NET, rozszerzonym o dodatkowe integracje z komunikacją. Biblioteka została uruchomiona około 2011 roku i widziała aktywny rozwój do 2012 roku, a nawet do 2013 roku. Jej ostateczne wydanie — wersja 1.7.0.2 — zostało opublikowane 27 kwietnia 2013 roku. Strona projektu nie jest już aktywnie utrzymywana i nie pojawił się żaden publiczny opiekun od tamtego czasu.

Biblioteka została zaprojektowana z myślą o erze .NET Framework i platformach mobilnych, które definiowały ten okres. Oferowal dekodowanie i kodowanie kodow kreskowych za pomoca API opartego na instancjach, akceptujac System.Drawing.Bitmap wejscia i zwracajac obiekty wynikowe z wlasciwosciami .Text i .BarcodeFormat. W przypadku aplikacji .NET Framework 4.x działających w systemie Windows w 2012 r. podejście to było praktyczne i powszechnie stosowane.

Jako port ZXing, MessagingToolkit.BarCode korzystał z tego samego silnika dekodującego co ta biblioteka Java, ale nałożył na niego własną warstwę API i punkty rozszerzeń zorientowane na komunikację. Biblioteka nigdy nie wyszła poza swoje korzenie w .NET Framework. Nie opublikowano żadnego celu .NET Standard, nie dodano wsparcia dla.NET Corei nie przeprowadzono żadnych aktualizacji od wydania z kwietnia 2013 roku.

Kluczowe cechy MessagingToolkit.BarCode:

• Ostateczne wydanie: Kwiecień 2013, wersja 1.7.0.2, bez kolejnych aktualizacji
• Dziedzictwo ZXing: Port biblioteki Java ZXing z rozszerzeniami specyficznymi dla .NET
• API oparte na instancjach: Wymaga tworzenia obiektow BarcodeDecoder i BarcodeEncoder dla kazdej operacji
• Zaleznosc od System.Drawing: Akceptuje i zwraca System.Drawing.Bitmap, czyniac go wymiennym tylko na Windows w nowoczesnym .NET
• Pojedynczy wynik na wywołanie dekodowania: Zwraca jeden obiekt wyniku (lub null) zamiast kolekcji
• Brak obsługi plików PDF: dane wejściowe są ograniczone do obiektów bitmapowych; brak natywnego odczytu dokumentów
• Brak automatycznego wykrywania formatu: Format musi być wstępnie skonfigurowany lub wykryty przez bibliotekę wyłącznie na podstawie obrazu
• Wycofane platformy docelowe: zawiera Silverlight 3, 4 i 5; Windows Phone 7.0, 7.5, 7.8 i 8.0 w metadanych NuGet
• Brak nazwy nowoczesnej platformy docelowej .NET: nie skompiluje się w projektach przeznaczonych dla .NET Core, .NET 5 lub dowolnej późniejszej wersji

Platforma i historia konserwacji

Metadane pakietu NuGet dla MessagingToolkit.BARCODE dokumentują jego docelowe przeznaczenie. Każda pozycja w poniższej tabeli odpowiada platformie, która była aktualna lub prawie aktualna w momencie tworzenia biblioteki:

Biblioteka nie posiada kompatybilnego frameworka docelowego dla .NET Core, .NET 5, .NET 6, .NET 7, .NET 8 ani .NET 9. Projekty skierowane do tych środowisk uruchomieniowych napotkają błąd kompilacji, gdy pakiet nie będzie w stanie rozpoznać kompatybilnego monikera frameworka — nie będzie to ostrzeżenie środowiska uruchomieniowego, ale błąd kompilacji.

Zrozumienie IronBarcode

IronBarcode to komercyjna biblioteka do odczytu i generowania kodów kreskowych dla platformy .NET, opracowana i utrzymywana przez firmę Iron Software. Dziala za pomoca modelu API statycznego: BarcodeReader.Read() do dekodowania i BarcodeWriter.CreateBarcode() do kodowania, bez wymagania instancjonowanych obiektow do odczytu lub zapisu. Biblioteka zawiera wlasny potok przetwarzania obrazow i nie zalezy od System.Drawing, dzieki czemu jest kompatybilna w systemach Windows, Linux, macOS i srodowiskach kontenerowych.

IronBarcode akceptuje wiele typow wejsciowych do odczytu: sciezki plikow, obiekty Stream, tablice bajtow oraz sciezki dokumentow PDF. Wyniki są zwracane jako kolekcje, a nie pojedyncze obiekty typu nullable, co umożliwia obsługę obrazów zawierających wiele kodów kreskowych bez konieczności oddzielnej konfiguracji. Wykrywanie formatu odbywa się automatycznie — biblioteka identyfikuje typ BARCODE na podstawie zawartości obrazu, bez konieczności wcześniejszego określania go przez użytkownika.

Do generowania IronBarcode zwraca plynny obiekt wynikowy z BarcodeWriter.CreateBarcode(), ktory obsluguje wiele formatow wyjsciowych, w tym PNG, JPEG, SVG, PDF i ciagi zakodowane base64. Biblioteka jest regularnie aktualizowana, a nowe wersje NuGet są aktywnie publikowane.

Kluczowe cechy IronBarcode:

• Statyczna konstrukcja API: BarcodeReader.Read() i BarcodeWriter.CreateBarcode() nie wymagaja instancjonowanych obiektow
• Wielopłatformowość: Działa na systemach Windows, Linux, macOS, w kontenerach Docker oraz w funkcjach chmurowych
• Brak zależności od System.Drawing: wykorzystuje wewnętrzny potok obrazów kompatybilny ze wszystkimi nowoczesnymi platformami .NET
• Odczyt wielu wyników: zwraca zbiór danych z każdego wywołania dekodowania, obsługując obrazy zawierające wiele BarCode'ów
• Odczytywanie plików PDF: odczytuje BarCodes bezpośrednio z dokumentów PDF bez konieczności stosowania zewnętrznych metod ekstrakcji
• Automatyczne wykrywanie formatu: Rozpoznaje typ BARCODE na podstawie zawartości obrazu bez konieczności konfiguracji przez użytkownika
• Wynik generowania płynnego: Zapisz jako PNG, JPEG, SVG, PDF lub tablicę bajtów z pojedynczego obiektu wynikowego
• Aktywna konserwacja: regularne wydania NuGet z poprawkami bezpieczeństwa i nowymi funkcjami
• Licencja komercyjna: Wymaga klucza licencyjnego do użytku produkcyjnego; działa w trybie testowym bez niego

Porównanie funkcji

Poniższa tabela przedstawia ogólny przegląd podstawowych różnic między MessagingToolkit.BarCode a IronBarcode:

Szczegółowe porównanie funkcji

Obsługa platform i frameworków

Historia tych dwóch bibliotek na platformie jest określona przez 12-letnią przerwę. MessagingToolkit.BarCode został zaprojektowany na konkretny moment w historii .NET;IronBarcode został zaprojektowany z myślą o teraźniejszości.

Podejście MessagingToolkit.BarCode

MessagingToolkit.BarCode jest przeznaczony wyłącznie dla platform .NET Framework 3.5, 4.0 i 4.5. Nie ma monikera .NET Standard, nie jest przeznaczony dla.NET Corei nie ma nakładki kompatybilności dla nowoczesnych środowisk uruchomieniowych. Gdy plik projektu odwołuje się do tego pakietu i jest przeznaczony dla dowolnej nowoczesnej wersji .NET, operacja przywracania NuGet kończy się niepowodzeniem z powodu błędu zgodności frameworka — kompilacja nie jest kontynuowana.

Tabela platform w metadanych NuGet konkretnie to ilustruje. Wymieniono wersje docelowe Silverlight 3, 4 i 5; wszystkie trzy zostały wycofane z rynku w 2021 r. Wymieniono systemy Windows Phone 7.0, 7.5, 7.8 i 8.0; Wszystkie z nich przestały być obsługiwane w latach 2014–2017. Pozostałe wersje — .NET Framework 3.5, 4.0 i 4.5 — nadal działają w systemie Windows, ale Microsoft dostarcza dla nich tylko poprawki bezpieczeństwa, bez wprowadzania nowych funkcji.

Praktycznym konsekwencją jest to, że MessagingToolkit.Barcode blokuje aktualizację frameworku. Plik projektu, ktory celuje w net472 i odnosi sie do tego pakietu, nie moze zostac zmieniony na net8.0 bez uprzedniego usuniecia pakietu. Pakiet ten nie jest tylko przestarzały — jego brak nowoczesnych cech frameworku uniemożliwia zmianę docelowego frameworku, która pozwoliłaby projektowi korzystać z nowoczesnych możliwości .NET.

Zapoznaj się z dokumentacją platformy IronBarcode, aby uzyskać pełną listę obsługiwanych frameworków i środowisk wdrożeniowych.

Podejście IronBarcode

IronBarcode obsługuje platformy od .NET Framework 4.6.2 do .NET 9, obejmując zarówno starsze aplikacje Windows, jak i nowoczesne wdrożenia wielopłatformowe. Pojedynczy pakiet NuGet instaluje się na wszystkich obsługiwanych platformach bez konieczności stosowania oddzielnych bibliotek graficznych lub konfiguracji specyficznej dla danej platformy.

Wspolpraca miedzy platformami jest znacząca w praktyce. Wewnetrzny potok obrazow IronBarcode nie zalezy od System.Drawing, ktory stal sie wymienny tylko na Windows w .NET 6. Aplikacje celujace w Linux lub macOS - w tym te dzialajace w kontenerach Docker, Azure App Service na Linux, czy AWS Lambda - uzywaja tego samego API i zachowania IronBarcode, co wdrozenia na Windows.

Projektowanie API

Powierzchnia API MessagingToolkit.Barcode zostala zaprojektowana wokol obiektow opartych na instancjach i System.Drawing.Bitmap wejsciach. API IronBarcode jest statyczne i akceptuje wiele typów danych wejściowych. Obie biblioteki kodują i dekodują kody kreskowe, ale mechanizm ich wywoływania znacznie się różni.

Podejście MessagingToolkit.BarCode

Odczytanie z MessagingToolkit.Barcode wymaga utworzenia instancji BarcodeDecoder, skonstruowania Bitmap z pliku obrazu, przekazania bitmapy do .Decode() i sprawdzenia wyniku pod katem null przed uzyskaniem dostepu do .Text. Generowanie podazalo tym samym wzorcem opartym na instancjach: utworz BarcodeEncoder, ustaw jego wlasciwosc .Format, wywolaj .Encode(), aby otrzymac Bitmap, nastepnie wywolaj .Save() na tej bitmapie.

// MessagingToolkit.Barcode — .NET Framework target frameworks
using MessagingToolkit.Barcode;
using System.Drawing;

// Reading
var barcodeReader = new BarcodeDecoder();
var bitmap = new Bitmap("barcode.png");
var result = barcodeReader.Decode(bitmap);
string value = result?.Text;
string format = result?.BarcodeFormat.ToString();

// Writing
var barcodeWriter = new BarcodeEncoder();
barcodeWriter.Format = BarcodeFormat.QrCode;
var outputBitmap = barcodeWriter.Encode("Hello World");
outputBitmap.Save("output.png");

// MessagingToolkit.Barcode — .NET Framework target frameworks
using MessagingToolkit.Barcode;
using System.Drawing;

// Reading
var barcodeReader = new BarcodeDecoder();
var bitmap = new Bitmap("barcode.png");
var result = barcodeReader.Decode(bitmap);
string value = result?.Text;
string format = result?.BarcodeFormat.ToString();

// Writing
var barcodeWriter = new BarcodeEncoder();
barcodeWriter.Format = BarcodeFormat.QrCode;
var outputBitmap = barcodeWriter.Encode("Hello World");
outputBitmap.Save("output.png");

Imports MessagingToolkit.Barcode
Imports System.Drawing

' Reading
Dim barcodeReader As New BarcodeDecoder()
Dim bitmap As New Bitmap("barcode.png")
Dim result = barcodeReader.Decode(bitmap)
Dim value As String = result?.Text
Dim format As String = result?.BarcodeFormat.ToString()

' Writing
Dim barcodeWriter As New BarcodeEncoder()
barcodeWriter.Format = BarcodeFormat.QrCode
Dim outputBitmap = barcodeWriter.Encode("Hello World")
outputBitmap.Save("output.png")

Imports MessagingToolkit.Barcode
Imports System.Drawing

' Reading
Dim barcodeReader As New BarcodeDecoder()
Dim bitmap As New Bitmap("barcode.png")
Dim result = barcodeReader.Decode(bitmap)
Dim value As String = result?.Text
Dim format As String = result?.BarcodeFormat.ToString()

' Writing
Dim barcodeWriter As New BarcodeEncoder()
barcodeWriter.Format = BarcodeFormat.QrCode
Dim outputBitmap = barcodeWriter.Encode("Hello World")
outputBitmap.Save("output.png")

Zaleznosc Bitmap nie jest przypadkowa. System.Drawing.Bitmap wymaga GDI+ na Windows. W .NET 6 i pozniejszych probujac uzywac System.Drawing na Linux lub macOS, wywola PlatformNotSupportedException w czasie uruchomienia. Nawet jesli montaz MessagingToolkit.Barcode moglby zostac zaladowany w nowoczesnym projekcie .NET — nie moze, z powodu zaginionego celu frameworka — zaleznosc Bitmap uniemozliwi wdrozenie miedzy platformami niezaleznie.

Podejście IronBarcode

IronBarcode wykorzystuje wyłącznie metody statyczne. BarcodeReader.Read() akceptuje sciezke pliku, Stream, tablice bajtow lub sciezke pliku PDF — nie wymagane Bitmap. Wynikiem jest zbiór, a nie pojedynczy obiekt typu nullable. Generowanie uzywa BarcodeWriter.CreateBarcode() z typem kodowania przekazanym jako parametr, a obiekt wynikowy udostepnia metody zapisu bezposrednio.

//IronBarcode— .NET Framework 4.6.2 through .NET 9
using IronBarCode;

IronBarCode.License.LicenseKey = "YOUR-LICENSE-KEY";

// Reading
var results = BarcodeReader.Read("barcode.png");
string value = results.FirstOrDefault()?.Value;
string format = results.FirstOrDefault()?.Format.ToString();

// Writing
BarcodeWriter.CreateBarcode("Hello World", BarcodeEncoding.QRCode)
    .SaveAsPng("output.png");

//IronBarcode— .NET Framework 4.6.2 through .NET 9
using IronBarCode;

IronBarCode.License.LicenseKey = "YOUR-LICENSE-KEY";

// Reading
var results = BarcodeReader.Read("barcode.png");
string value = results.FirstOrDefault()?.Value;
string format = results.FirstOrDefault()?.Format.ToString();

// Writing
BarcodeWriter.CreateBarcode("Hello World", BarcodeEncoding.QRCode)
    .SaveAsPng("output.png");

Szczegółowe wskazówki dotyczące odczytywania BARCODE-ów z obrazów można znaleźć w artykułe "Jak odczytywać BARCODE-y z obrazów". Aby wygenerować kody kreskowe 1D, w tym formaty Code 128, EAN-13 i UPC, zobacz, jak tworzyć kody kreskowe 1D.

Bezpieczeństwo i konserwacja

Nieadopcyjna biblioteka ma inne podejście do bezpieczeństwa niż aktywnie utrzymywana. Różnica nie polega na tym, czy CVE został zgłoszony — polega na tym, czy CVE mógłby być zaadresowany, jeśli został zgłoszony.

Podejście MessagingToolkit.BarCode

MessagingToolkit.Barcode nie otrzymywała aktualizacji od kwietnia 2013 roku. Każda podatność odkryta po tej dacie — w logice parsowania obrazów, implementacji dekodera wyprowadzonej z ZXing, czy w zależnościach pośrednich biblioteki — pozostaje niezałatana. Nie ma publicznego opiekuna do powiadomienia,nie ma procesu doradztwa bezpieczeństwa do monitorowania i nie ma mechanizmu wydania, za pośrednictwem którego łatka mogłaby trafić do użytkowników nawet jeśli taka zostałaby opracowana.

Narzędzia do skanowania bezpieczeństwa — Snyk, WhiteSource, GitHub Dependabot, audyt NuGet — zwykle oznaczają nieutrzymywane pakiety jako elevensowej uwagi. Zgłoszenie nie jest uzależnione od potwierdzonego CVE; odzwierciedla brak jakiegokolwiek procesu, dzięki któremu można by usunąć potwierdzone luki w zabezpieczeniach. To inny profil ryzyka niż biblioteka z aktywnym opiekunem i udokumentowanym procesem reagowania na zagrożenia.

Dla zespołów działających w ramach ram zgodności — PCI DSS, HIPAA, SOC 2, ISO 27001 — ma to praktyczne konsekwencje audytowe. Te ramy oczekują aktywnego zarządzania poprawkami oprogramowania zewnętrznego, a nieutrzymywany pakiet bez mechanizmu reagowania na zagrożenia zwykle jest oznaczony podczas przeglądu audytu bez względu na to, czy zgłoszono przeciwko niemu konkretną CVE. Odkrycie odnosi się do postawy utrzymania zależności, a nie do obecności znanej eksploatacji.

Podejście IronBarcode

IronBarcode otrzymuje regularne aktualizacje NuGet obejmujące poprawki bezpieczeństwa, aktualizacje zależności i nowe funkcje. Biblioteka została opracowana przez firmę Iron Software, która prowadzi udokumentowany proces wsparcia technicznego i publikuje informacje o aktualizacjach dla każdej wersji. W stosownych przypadkach zalecenia dotyczące bezpieczeństwa są uwzględniane w wydaniach poprawek.

IronBarcode obsługuje ponad 50 formatów kodów kreskowych, w tym wszystkie formaty obsługiwane przez MessagingToolkit.BarCode — QR Code, Code 128, EAN-13, EAN-8, UPC-A i inne — a także formaty, których starsza biblioteka nigdy nie obsługiwała: DataMatrix, Aztec, PDF417 oraz pełen zakres nowoczesnych symboli 2D.

Przewodnik po mapowaniu API

Poniższa tabela przedstawia mapowanie elementów interfejsu API MessagingToolkit.BARCODE na ich odpowiedniki w IronBarcode:

Kiedy zespoły rozważają przejście z MessagingToolkit.BarCode na IronBarcode

Scenariusze, które skłaniają zespoły do oceny tej migracji, mają wspólną strukturę: projektowy wymóg przekroczył to, co porzucona biblioteka z ery wczesnego .NET Framework może pomieścić.

Wymagania dotyczące modernizacji frameworka

Najczęstszym powodem jest planowana lub trwająca aktualizacja platformy .NET. Kiedy zespół decyduje się przenieść projekt z .NET Framework 4.x do .NET 6 lub nowszego, należy sprawdzić wykres zależności pod kątem pakietów, które nie obsługują nowoczesnego frameworka. MessagingToolkit.BARCODE pojawi się w tym audycie jako zależność blokująca — taka, której nie można rozwiązać w odniesieniu do nowoczesnego monikera docelowego frameworka. Migracja do IronBarcode jest zatem warunkiem wstępnym szerszej aktualizacji platformy .NET, a nie odrębną inicjatywą. Zespoły zajmujące się modernizacją aplikacji zazwyczaj odkrywają tę zależność na wczesnym etapie analizy aktualizacji.

Obowiązki w zakresie bezpieczeństwa i zgodności

Drugi scenariusz dotyczy przeglądów bezpieczeństwa i audytów zgodności. Zespoły działające w ramach standardów PCI DSS, HIPAA, SOC 2 lub ISO 27001 przechodzą okresowe audyty, podczas których sprawdzany jest stan zależności od podmiotów zewnętrznych. Nieutrzymywany pakiet bez mechanizmu reakcji na bezpieczeństwo zwykle pojawia się jako odkrycie w ramach przeglądu procesowego, niezależnie od tego, czy została zidentyfikowana konkretna luka. Kiedy zespół ds. bezpieczeństwa oznacza MessagingToolkit.Barcode jako niezgodną z zależnością, rozwiązaniem jest zastąpienie — nie ma łatki do zastosowania, nie ma wersji do aktualizacji i nie ma opiekuna, z którym można skontaktować się z doradcą ds. bezpieczeństwa. Migracja do IronBarcode adresuje odkrycie audytu, zastępując zależność bez ścieżki utrzymania jedną, która otrzymuje regularne aktualizacje związane z bezpieczeństwem.

Rozszerzenie możliwości

Trzeci scenariusz ma miejsce, gdy nowe wymagania wykraczają poza możliwości MessagingToolkit.BarCode. Aplikacje przetwarzające zeskanowane dokumenty lub pliki PDF wymagają odczytu kodów kreskowych z tych formatów — MessagingToolkit.BarCode akceptował jedynie dane wejściowe w formacie bitmapowym, co uniemożliwiało odczyt plików PDF bez oddzielnej warstwy ekstrakcji. Aplikacje generujace kody kreskowe do dostarczania w sieci potrzebuja wyjscia SVG lub base64 — MessagingToolkit.Barcode zwracal Bitmap, wymagajac dodatkowych krokow konwersji oraz System.Drawing.Imaging zaleznosci. Gdy wymagania produktowe rozszerzają się na te obszary, ograniczenia starszej biblioteki stają się ograniczeniami inżynieryjnymi, których nie da się obejść w ramach jej interfejsu API.

Platforma Docelowy wzrost

Czwartym scenariuszem jest dodanie nowych miejsc wdrożenia. Zespoly, ktore poczatkowo budowaly aplikacje tylko dla Windows i rozszerzaja sie na hostowanie w Linux, srodowiska deweloperskie macOS, kontenery Docker lub funkcje chmurowe na runtime Linux, napotykaja zaleznosc System.Drawing jako problem blokujacy. MessagingToolkit.Barcode wymaga System.Drawing.Bitmap dla wszystkich operacji wejscia i wyjscia, a System.Drawing jest wymienny tylko na Windows w .NET 6 i pozniej. Każde środowisko docelowe inne niż Windows sprawia, że ta zależność staje się błędem środowiska uruchomieniowego, a nie tylko problemem kompatybilności. Migracja do IronBarcode usuwa wymaganie System.Drawing calkowicie, umozliwiajac wdrozenie miedzy platformami, ktore zespol probuje osiagnac.

Typowe kwestie związane z migracją

Zespoły przechodzące z MessagingToolkit.BarCode na IronBarcode powinny być świadome kilku różnic technicznych, które mają wpływ na mechanikę migracji.

Zastąpienie przestrzeni nazw

Kazdy plik zawierajacy using MessagingToolkit.Barcode; wymaga aktualizacji do using IronBarCode;. Wyszukiwanie starego ciągu znaków przestrzeni nazw w całym kodzie jest najbardziej wiarygodnym punktem wyjścia do określenia zakresu migracji. Pliki importujace System.Drawing wylacznie dla typu Bitmap uzywanego z MessagingToolkit.Barcode moga zostac calkowicie usuniete, gdy IronBarcode jest na miejscu, poniewaz nie wymaga tego.

Zmiana docelowej platformy

Usunięcie pliku MessagingToolkit.BARCODE z pliku projektu umożliwia aktualizację nazwy docelowej platformy. Zmiana z <TargetFramework>net472</TargetFramework> na <TargetFramework>net8.0</TargetFramework> staje sie mozliwa, gdy zaleznosc blokujaca zostaje usunieta.IronBarcode obsługuje obie strony tej zmiany — jest kompatybilny zarówno z .NET Framework 4.6.2, jak i z .NET 8 — dzięki czemu można go zainstalować przed sfinalizowaniem aktualizacji frameworka, co pozwala na przeprowadzenie migracji etapami, a nie w jednym kroku.

Różnice w przestrzeni nazw BarcodeWriter

MessagingToolkit.Barcode uzywal BarcodeEncoder jako klasy generowania, z formatem ustawianym jako wlasciwosc (barcodeWriter.Format = BarcodeFormat.QrCode) przed wywolaniem .Encode().IronBarcode uzywa BarcodeWriter.CreateBarcode() jako metody statycznej, z typem kodowania przekazanym jako parametr. Nazwy enumow roznia sie: BarcodeFormat.QrCode staje sie BarcodeEncoding.QRCode, a BarcodeFormat.Code128 staje sie BarcodeEncoding.Code128. Wynik CreateBarcode() to plynny obiekt z .SaveAsPng(), .SaveAsJpeg(), .SaveAsSvg() oraz innymi metodami wyjsciowymi - nie zwraca Bitmap.

Dodatkowe możliwości IronBarcode

IronBarcode oferuje możliwości wykraczające poza zestaw funkcji omówionych w powyższych sekcjach:

• Odczyt kodow kreskowych z PDF: BarcodeReader.Read("document.pdf") odczytuje kody kreskowe z kazdej strony dokumentu PDF, zwracajac wyniki, ktore zawieraja metadane dotyczące numeru strony. Nie jest wymagany żaden zewnętrzny etap ekstrakcji plików PDF.
• Przetwarzanie wsadowe: wiele plików — zarówno obrazów, jak i plików PDF — można odczytać w jednym przebiegu. Automatyczne wykrywanie formatu dotyczy typu BARCODE, a nie tylko formatu pliku.
• Dostosowanie kodow QR: Wygenerowane kody QR moga zawierac osadzone loga, niestandardowe kolory oraz regulowane strefy ciche za pomoca API QRCodeWriter.
• Asynchroniczne przyjazne uzycie: BarcodeReader.Read() akceptuje Stream wejscia, integrujac sie czysto z potokami zadaniowymi async wASP.NET Corei innych asynchronicznych aplikacjach .NET.
• Wiele formatów wyjściowych do generowania: Wygenerowane kody kreskowe można zapisać jako pliki PNG, JPEG, SVG, PDF lub pobrać jako ciąg znaków zakodowany w base64 w celu bezpośredniego osadzenia w odpowiedziach HTML lub przechowywania w bazie danych.

Zgodność z platformą .NET i gotowość na przyszłość

IronBarcode obsługuje pełną gamę aktualnych wersji .NET — od .NET Framework 4.6.2 do .NET 9 — i otrzymuje aktualizacje, które śledzą nowe wersje .NET w miarę ich udostępniania. Wewnetrzny potok obrazow biblioteki unika zaleznosci od System.Drawing lub innych specyficznych dla platformy API graficznych, co oznacza, ze ten sam pakiet i API dzialaja identycznie na systemach Windows, Linux, macOS i srodowiskach kontenerowych. Wraz z publikacją .NET 10 i kolejnych wersji, aktywne tempo rozwoju IronBarcode zapewnia utrzymanie kompatybilności bez konieczności odkładania aktualizacji .NET przez zespoły z powodu ograniczeń bibliotek.

Wnioski

MessagingToolkit.BARCODE i IronBarcode reprezentują dwa bardzo różne etapy rozwoju bibliotek .NET. MessagingToolkit.Barcode byl stworzony dla .NET Framework 4.x i platfrom mobilnych poczatku lat 2010.IronBarcode zostal zbudowany dla .NET, który istnieje w 2026 roku — wieloplatformowy, przyjazny kontenerom i aktywnie utrzymywany. Różnice techniczne między nimi nie wynikają z braku równoważności funkcji; jest to kwestia zgodności środowiska uruchomieniowego. MessagingToolkit.BarCode nie skompiluje się w nowoczesnym projekcie .NET, co oznacza, że w większości praktycznych scenariuszy nie ma porównania między dwiema konkurencyjnymi opcjami.

MessagingToolkit.Barcode zajmuje waski uzasadniony przypadek uzycia: projekt, który celuje wylacznie na .NET Framework 4.x, dziala tylko na Windows, nigdy nie zostanie zaktualizowany do nowszego srodowiska uruchomieniowego i funkcjonuje w srodowisku bez rygorystycznych wymagan dotyczacych zarzadzania latami od stron trzecich. W tej konkretnej konfiguracji, biblioteka generuje wyjscie i blokader celujacy w ramy nie ma zastosowania. Luka w utrzymaniu — ponad dekada bez lat — wciaz dotyczy wszystkich konfiguracji.

IronBarcode jest odpowiedni dla zespołów, które potrzebują funkcji kodów kreskowych w dowolnym nowoczesnym środowisku .NET: .NET 6, 7, 8 lub 9; Wdrożenie na systemie Linux lub macOS; Środowiska Docker lub hostowane w chmurze; Aplikacje ASP.NET Core; lub jakikolwiek projekt, ktory przetwarza PDF-y lub wymaga kodow kreskowych w formatach wyjsciowych innych niz bitmapa Windows. Statyczne API zmniejsza obciazenie zwiazane z instancjonowaniem modelu opartego na instancjach, a brak zaleznosci od System.Drawing usuwa znaczącą barierę miedzy platformami.

Podstawowa ocena jest prosta. Dla zespołów korzystających z platformy .NET Framework 4.x, które nie planują zmian, MessagingToolkit.BarCode nadal działa w ramach tych ograniczeń. W każdym innym scenariuszu — modernizacji, zapewnieniu zgodności, wdrożeniu wielopłatformowym lub rozszerzeniu możliwości — MessagingToolkit.BarCode nie jest realną opcją, a IronBarcode stanowi bezpośredni zamiennik z niewielką, dobrze zdefiniowaną ścieżką migracji.