Poprzednia integracja

Dokumentacja wcześniejszej biblioteki netstandard2.0 Doconut

Użyj tej sekcji, gdy istniejąca aplikacja .NET Standard nadal tworzy Viewer ręcznie, przekazuje opcje do warstwy pośredniej, koordynuje farmę webową za pomocą współdzielonego folderu lub kopiuje skrypty przeglądarki do aplikacji. Ta architektura pozostaje udokumentowana dla klientów, którzy nie przeszli migracji.

Wersja pakietu identyfikuje generację

Identyfikator pakietu sam w sobie nie wystarczy. Obie generacje są publikowane jako Doconut.NETStandard:

WersjaDocelowaGeneracja
26.7.0 i niżejnetstandard2.0Poprzednia — udokumentowana tutaj
26.8.0 i wyżejnetstandard2.1Bieżąca — udokumentowana w dalszej części tej sekcji

Sprawdź wersję w pliku projektu, pliku blokady lub w pamięci podręcznej .nupkg przed wybraniem instrukcji. Odniesienie do pakietu, które jedynie podaje Doconut.NETStandard, nie informuje, przeciwko któremu API jest napisany kod.

Zidentyfikuj poprzednią integrację

Aplikacja używa poprzedniej integracji, gdy zawiera jedną lub więcej z następujących sygnatur:

csharp
var viewer = new Viewer(_cache, _accessor);
var viewer = new Viewer(_cache, _accessor, licenseFilePath);

var token = viewer.OpenDocument(path, config, documentOptions);
viewer.InitCache();

appBranch.UseDoconut(new DoconutOptions { UnSafeMode = false, ShowDoconutInfo = false });

appBranch.UseDoconutWebFarm(new WebFarmOptions { Path = sharedFolder });

Viewer.DoconutLicense(licenseStream);
Viewer.SetLicensePlugin(pluginLicenseStream);

var converter = viewer.Converter.GetConverter();

Blok using jest kolejnym wiarygodnym sygnałem — typy konfiguracji były rozproszone w kilku przestrzeniach nazw:

csharp
using Doconut.Configs;
using Doconut.Configs.View;
using Doconut.Configs.Cloud;
using Doconut.Models;

Poprzednie strony również często ładowały zarządzane przez aplikację kopie:

text
docViewer.js
documentLinks.js
docViewer.UI.js

oraz deklarowały wywołania zwrotne przeglądarki jako globalne, nazwane po identyfikatorze kontenera, np. ctlDoc_OnViewerReady().

Bieżąca integracja jest natomiast identyfikowana przez AddDoconut(), UseDoconutResources(), UseDoconut() bez argumentów, wstrzyknięty Viewer, OpenDocumentAsync() oraz spłaszczoną przestrzeń nazw Doconut.

Otwórz zachowaną instrukcję

Przetłumaczona historyczna instrukcja znajduje się pod adresem Legacy .NET Standard setup. Jej URL nie został przekierowany ani zastąpiony, ponieważ opisuje rzeczywistą generację integracji, której istniejące aplikacje nadal używają.

Nie łącz fragmentów z tej instrukcji z bieżącą dokumentacją AddDoconut(). Konstrukcja Viewer, routowanie warstwy pośredniej, licencje, zasoby, konwersja, koordynacja farmy webowej i własność sesji są wszystkie różne.

Zaplanuj migrację

Użyj Migrate to .NET Standard 2.1 aby uzyskać zweryfikowane mapowanie od ręcznej konstrukcji i synchronicznego otwierania dokumentów do DI, bieżącej warstwy pośredniej, asynchronicznych sesji, generowanych zasobów, rozproszonego publikowania i wtyczek z kontrolą możliwości.

Przed rozpoczęciem warto zwrócić uwagę na dwie kwestie:

  • Framework hosta. netstandard2.1 wymaga .NET Core 3.0 lub nowszego. Host .NET Framework nie może w ogóle korzystać z bieżącego pakietu.
  • Zmiany po stronie klienta. Dwie z nich zawodzą cicho — serwer działa dalej, a konsola przeglądarki pozostaje pusta. Są opisane w przewodniku migracji.

Utrzymuj poprzednie wdrożenie w niezmienionej formie, aż bieżąca aplikacja przejdzie testy dokumentu, licencji, wyszukiwania, adnotacji, konwertera, DICOM, bezpieczeństwa i przywracania.

Czy ta strona była pomocna?