Choisir le bon SDK Doconut : .NET Standard 2.1, .NET 6 ou .NET 8

Commencer par l’hôte de l’application

Choisir un package Doconut commence par le projet qui l’exécutera. Une nouvelle application web .NET 8, un service .NET 6 établi et un hôte ASP.NET Core compatible avec les bibliothèques peuvent tous nécessiter une visualisation de documents intégrée, mais leurs contraintes de framework et leurs plans de mise à jour diffèrent.

Doconut propose des chemins SDK actuels pour .NET 8, .NET 6 et les hôtes compatibles qui consomment le nouveau package .NET Standard 2.1. Le bon choix est généralement le package qui correspond directement à l’hôte et qui laisse le moins d’ambiguïté de framework pour l’équipe qui maintient l’application.

La Vue d’ensemble du SDK Doconut Viewer est le point de départ pour les capacités du produit. Utilisez la documentation spécifique au framework pour prendre la décision du package.

Comprendre ce que signifient les trois étiquettes

.NET 8 et .NET 6 sont des cibles d’application. Une application web peut cibler l’un de ces runtimes et sélectionner le package Doconut correspondant.

.NET Standard 2.1 est différent : il définit un contrat d’API de bibliothèque que les hôtes .NET compatibles peuvent consommer. Doconut 26.8.0 introduit la génération actuelle Doconut.NETStandard pour les applications ciblant .NET Core 3.0 ou supérieur, y compris .NET 5 à .NET 8. Il ne peut pas être consommé par .NET Framework.

Cette distinction ancre la décision. Ne choisissez pas .NET Standard 2.1 simplement parce que cela semble plus général ; choisissez‑le lorsque son contrat correspond adéquatement à l’hôte et à la structure de la solution.

Un tableau de sélection pratique

Situation d’application	Chemin Doconut à évaluer	Pourquoi
Nouvelle application ciblant .NET 8	Doconut.NET8	Correspondance directe pour le développement .NET actuel et le chemin complet de documentation .NET 8.
Application existante qui doit rester sur .NET 6	Doconut.NET6	Conserve la cible de l’hôte tout en fournissant l’injection de dépendances, le middleware, la session asynchrone et le modèle distribué optionnel actuels.
Hôte ASP.NET Core compatible où le contrat .NET Standard est requis	Doconut.NETStandard 26.8.0+	Cible .NET Standard 2.1 et expose l’intégration Doconut actuelle pour les hôtes pris en charge.
Intégration existante de Doconut.NETStandard 26.7.0 ou antérieure	Planifiez une migration avant de sélectionner 26.8.0+	L’identifiant du package reste le même, mais la cible et la génération de l’API changent.
Application ciblant .NET Framework	Doconut.NETFramework	.NET Framework ne peut pas consommer .NET Standard 2.1.

Ce tableau affine la première décision. Les licences, les plugins optionnels, les formats de documents, la conception du déploiement et l’effort de mise à jour nécessitent encore une validation séparée.

Choisir Doconut.NET8 pour les nouvelles applications .NET 8

Pour une nouvelle application .NET 8, le package dédié est le choix le plus clair à évaluer. La Page du visualiseur .NET 8 décrit le modèle actuel basé sur l’injection de dépendances, les ressources servies par le middleware, les sessions de documents asynchrones et les flux de travail distribués optionnels.

Une correspondance directe avec le runtime facilite également la compréhension de la documentation. L’installation, la configuration, le dépannage, les plugins et les exemples peuvent tous être évalués au sein d’un seul chemin spécifique au framework.

Avant l’adoption, testez les formats de documents et les fonctionnalités optionnelles dont le produit a réellement besoin. Une correspondance de package ne remplace pas les décisions au niveau de l’application concernant l’authentification, l’autorisation, le stockage, la conservation, la surveillance et les limites de ressources.

Choisissez Doconut.NET6 lorsque l'hôte doit rester sur .NET 6

Une application établie peut avoir des dépendances ou des engagements de support qui la maintiennent sur .NET 6. Le Visionneur .NET 6 mis à jour permet à l'application de conserver cette cible tout en passant à l'architecture d'intégration actuelle de Doconut.

Ceci est utile lorsqu'une mise à niveau du runtime et une migration du visionneur de documents ne doivent pas se produire dans la même version. L'équipe peut moderniser l'enregistrement du visionneur, la livraison des ressources, l'ouverture asynchrone et les sessions de documents tout en maintenant le cadre d'hébergement stable.

Vérifiez si le projet existant utilise l'intégration classique ou mise à jour de Doconut .NET 6. Les noms de paquets seuls peuvent ne pas révéler la génération. La documentation officielle de migration identifie les signatures d'API et les modèles d'hébergement qui les distinguent.

Choisissez Doconut.NETStandard lorsque le contrat correspond à la solution

Le nouveau guide d'installation .NET Standard 2.1 définit la limite de compatibilité. Il prend en charge les hôtes .NET Core 3.0 et ultérieurs, y compris .NET 5, 6, 7 et 8, et exclut .NET Framework.

Cette voie peut avoir du sens lorsque la solution nécessite spécifiquement le contrat de bibliothèque .NET Standard. Le choix de version est crucial : Doconut.NETStandard 26.7.0 et antérieur cible .NET Standard 2.0 et utilise l'intégration précédente, tandis que 26.8.0 et ultérieur cible .NET Standard 2.1 avec l'API actuelle.

Si l'application utilise déjà la génération de paquet plus ancienne, consultez le guide de migration .NET Standard avant de mettre à jour. Le changement affecte plus que la compilation : le démarrage, la durée de vie du visionneur, le routage des ressources, l'ouverture de documents, la licence, les plugins et la publication distribuée peuvent nécessiter une attention.

Comparez l'impact complet sur l'application

Une petite preuve de concept devrait répondre à plus que « le paquet s'installe-t-il ? ». Évaluez :

1. Compatibilité de l'hôte : Confirmez la cible de l'application et chaque projet qui référence le paquet du visionneur.
2. Génération d'intégration : Identifiez l'enregistrement actuel ou classique, la création du visionneur et les modèles d'ouverture de documents.
3. Couverture documentaire : Testez des fichiers PDF, Office, CAD, image, courriel ou médicaux représentatifs requis par le produit.
4. Besoins en plugins : Validez individuellement les capacités de Recherche, Annotation, Convertisseur ou DICOM lorsqu'elles font partie du flux de travail.
5. Modèle opérationnel : Testez la durée de vie des sessions, la mise en cache, la livraison des ressources, le nettoyage et tout design mononœud ou distribué.
6. Effort de mise à niveau : Séparez les changements de framework des changements Doconut afin que les échecs soient plus faciles à diagnostiquer.
7. Contrôles de l'application : Vérifiez l'accès, le stockage, la rétention et le comportement de livraison dans le système environnant.

Enregistrez la version du paquet et la cible du framework à côté de chaque résultat. Cela empêche qu'un test réussi contre un chemin SDK soit confondu avec une preuve concernant un autre.

Rendre explicite le choix du framework

Une bonne note d'architecture peut être brève : indiquez la cible de l'application, le paquet Doconut sélectionné et sa version, les plugins requis, le modèle de déploiement et le chemin de documentation utilisé lors de l'implémentation. Cet enregistrement de décision aide les futures mises à jour à partir de faits plutôt que d'hypothèses basées sur le nom du paquet.

Pour un nouveau développement .NET 8, commencez avec le SDK .NET 8 dédié. Pour une application restant sur .NET 6, évaluez le paquet .NET 6 mis à jour. Utilisez Doconut.NETStandard 26.8.0+ lorsque le contrat .NET Standard 2.1 convient à un hôte compatible, et conservez les applications .NET Framework sur leur chemin de paquet dédié.

Consultez le hub de documentation Doconut et téléchargez un essai pour tester le chemin sélectionné avec votre propre application et vos documents.