Scegliere il giusto Doconut SDK: .NET Standard 2.1, .NET 6 o .NET 8
Inizia con l'host dell'applicazione
Scegliere un pacchetto Doconut inizia con il progetto che lo eseguirà. Una nuova applicazione web .NET 8, un servizio .NET 6 consolidato e un host ASP.NET Core compatibile con le librerie possono tutti richiedere la visualizzazione di documenti incorporata, ma i loro vincoli di framework e i piani di aggiornamento differiscono.
Doconut offre percorsi SDK attuali per .NET 8, .NET 6 e host compatibili che consumano il nuovo pacchetto .NET Standard 2.1. La scelta giusta è solitamente il pacchetto che corrisponde direttamente all'host e riduce al minimo l'ambiguità del framework per il team che mantiene l'applicazione.
La panoramica del Doconut Viewer SDK è il punto di partenza per le capacità del prodotto. Usa la documentazione specifica per framework per prendere la decisione sul pacchetto.
Comprendere il significato delle tre etichette
.NET 8 e .NET 6 sono obiettivi applicativi. Un'applicazione web può mirare a uno di questi runtime e selezionare il pacchetto Doconut corrispondente.
.NET Standard 2.1 è diverso: definisce un contratto API di libreria che gli host .NET compatibili possono consumare. Doconut 26.8.0 introduce la generazione corrente Doconut.NETStandard per le applicazioni che mirano a .NET Core 3.0 o versioni successive, inclusi .NET 5 fino a .NET 8. Non può essere consumato da .NET Framework.
Questa distinzione mantiene la decisione radicata. Non scegliere .NET Standard 2.1 solo perché sembra più generico; sceglielo quando il suo contratto è la soluzione appropriata per l'host e la struttura della soluzione.
Una tabella pratica di selezione
| Situazione dell'applicazione | Percorso Doconut da valutare | Perché |
|---|---|---|
| Nuova applicazione che mira a .NET 8 | Doconut.NET8 | Corrispondenza diretta per lo sviluppo .NET attuale e il percorso di documentazione completo per .NET 8. |
| Applicazione esistente che deve rimanere su .NET 6 | Doconut.NET6 | Mantiene il target dell'host fornendo l'iniezione delle dipendenze, middleware, sessione asincrona e modello distribuito opzionale attuali. |
| Host ASP.NET Core compatibile dove è richiesto il contratto .NET Standard | Doconut.NETStandard 26.8.0+ | Mira a .NET Standard 2.1 ed espone l'integrazione Doconut corrente per gli host supportati. |
| Integrazione Doconut.NETStandard 26.7.0 o precedente esistente | Pianificare una migrazione prima di selezionare 26.8.0+ | L'ID del pacchetto rimane lo stesso, ma il target e la generazione dell'API cambiano. |
| Applicazione che mira a .NET Framework | Doconut.NETFramework | .NET Framework non può consumare .NET Standard 2.1. |
Questa tabella restringe la prima decisione. Licenze, plugin opzionali, formati di documento, design di distribuzione e sforzo di aggiornamento richiedono ancora una validazione separata.
Scegli Doconut.NET8 per le nuove applicazioni .NET 8
Per una nuova applicazione .NET 8, il pacchetto dedicato è la scelta più chiara da valutare. La pagina del Visualizzatore .NET 8 descrive il modello attuale basato su iniezione delle dipendenze, risorse servite da middleware, sessioni di documento asincrone e flussi di lavoro distribuiti opzionali.
Una corrispondenza diretta del runtime rende anche più semplice seguire la documentazione. Installazione, configurazione, risoluzione dei problemi, plugin e esempi possono tutti essere valutati all'interno di un unico percorso specifico per il framework.
Prima dell'adozione, testa i formati di documento e le funzionalità opzionali di cui il prodotto ha realmente bisogno. Una corrispondenza di pacchetto non sostituisce le decisioni a livello di applicazione su autenticazione, autorizzazione, archiviazione, conservazione, monitoraggio e limiti delle risorse.
Scegli Doconut.NET6 quando l'host deve rimanere su .NET 6
Un'applicazione consolidata può avere dipendenze o impegni di supporto che la mantengono su .NET 6. Il visualizzatore .NET 6 aggiornato consente all'applicazione di mantenere quel target passando all'attuale architettura di integrazione di Doconut.
Questo è utile quando un aggiornamento del runtime e una migrazione del visualizzatore di documenti non dovrebbero avvenire nella stessa release. Il team può modernizzare la registrazione del visualizzatore, la consegna delle risorse, l'apertura asincrona e le sessioni dei documenti mantenendo stabile il framework host.
Verifica se il progetto esistente utilizza l'integrazione classica o quella aggiornata di Doconut .NET 6. I nomi dei pacchetti da soli potrebbero non rivelare la generazione. La documentazione ufficiale di migrazione identifica le firme API e i pattern di hosting che li distinguono.
Scegli Doconut.NETStandard quando il contratto si adatta alla soluzione
La nuova guida all'installazione di .NET Standard 2.1 definisce il confine di compatibilità. Supporta host .NET Core 3.0 e versioni successive, inclusi .NET 5, 6, 7 e 8, ed esclude .NET Framework.
Questo percorso può avere senso quando la soluzione richiede specificamente il contratto della libreria .NET Standard. La selezione della versione è critica: Doconut.NETStandard 26.7.0 e precedenti mirano a .NET Standard 2.0 e usano l'integrazione precedente, mentre 26.8.0 e successive mirano a .NET Standard 2.1 con l'API corrente.
Se l'applicazione utilizza già la generazione di pacchetti più vecchia, consulta la guida alla migrazione di .NET Standard prima di aggiornare. La modifica influisce su più che la compilazione: avvio, durata del visualizzatore, routing delle risorse, apertura dei documenti, licenze, plugin e pubblicazione distribuita potrebbero richiedere attenzione.
Confronta l'impatto completo sull'applicazione
Una piccola prova di concetto dovrebbe rispondere a più di “il pacchetto si installa?”. Valuta:
- Compatibilità dell'host: Conferma il target dell'applicazione e ogni progetto che fa riferimento al pacchetto del visualizzatore.
- Generazione dell'integrazione: Identifica la registrazione corrente o classica, la creazione del visualizzatore e i pattern di apertura dei documenti.
- Copertura dei documenti: Testa PDF, Office, CAD, immagini, email o file medici rappresentativi richiesti dal prodotto.
- Necessità di plugin: Convalida singolarmente le capacità di Ricerca, Annotazione, Convertitore o DICOM quando fanno parte del flusso di lavoro.
- Modello operativo: Prova la durata della sessione, la cache, la consegna delle risorse, la pulizia e qualsiasi design a nodo singolo o distribuito.
- Sforzo di aggiornamento: Separa le modifiche al framework da quelle a Doconut in modo che i fallimenti siano più facili da diagnosticare.
- Controlli dell'applicazione: Verifica accesso, archiviazione, conservazione e comportamento di consegna nel sistema circostante.
Registra la versione del pacchetto e il target del framework accanto a ciascun risultato. Questo evita che un test riuscito su un percorso SDK venga interpretato erroneamente come prova per un altro.
Rendi esplicita la scelta del framework
Una buona nota architetturale può essere breve: indica il target dell'applicazione, il pacchetto Doconut selezionato e la sua versione, i plugin richiesti, il modello di distribuzione e il percorso della documentazione usato durante l'implementazione. Tale registro decisionale aiuta gli aggiornamenti futuri a partire da fatti piuttosto che da supposizioni basate sul nome del pacchetto.
Per lo sviluppo su .NET 8, inizia con il SDK dedicato a .NET 8. Per un'applicazione che rimane su .NET 6, valuta il pacchetto .NET 6 aggiornato. Usa Doconut.NETStandard 26.8.0+ quando il contratto .NET Standard 2.1 è la scelta giusta per un host compatibile, e mantieni le applicazioni .NET Framework sul loro percorso di pacchetto dedicato.
Consulta il hub di documentazione di Doconut e scarica una versione di prova per testare il percorso selezionato con la tua applicazione e i tuoi documenti.