选择合适的 Doconut SDK：.NET Standard 2.1、.NET 6 或 .NET 8
从应用宿主开始
选择 Doconut 包的第一步是确定将运行它的项目。一个新的 .NET 8 Web 应用程序、一个已有的 .NET 6 服务，以及一个兼容库的 ASP.NET Core 宿主都可能需要嵌入式文档查看，但它们的框架约束和升级计划各不相同。
Doconut 提供针对 .NET 8、.NET 6 以及能够使用全新 .NET Standard 2.1 包的兼容宿主的 SDK 路径。正确的选择通常是直接匹配宿主的包，这样可以为维护应用的团队留下最少的框架歧义。
Doconut 查看器 SDK 概览 是了解产品功能的起点。使用针对特定框架的文档来做出包的决定。
理解这三个标签的含义
.NET 8 和 .NET 6 是应用目标。Web 应用程序可以针对这些运行时之一，并选择匹配的 Doconut 包。
.NET Standard 2.1 则不同：它定义了一个库 API 合约，兼容的 .NET 宿主可以使用。Doconut 26.8.0 引入了当前的 Doconut.NETStandard 版本，供面向 .NET Core 3.0 及更高版本（包括 .NET 5 到 .NET 8）的应用使用。它不能被 .NET Framework 使用。
这种区别使决策更有依据。不要因为 .NET Standard 2.1 听起来更通用就随意选择；只有在其合约适合宿主和解决方案结构时才选择它。
实用选择表
| 应用情境 | 待评估的 Doconut 路径 | 原因 |
|---|---|---|
| 针对 .NET 8 的新应用 | Doconut.NET8 | 直接匹配当前 .NET 开发，并拥有完整的 .NET 8 文档路径。 |
| 必须保持在 .NET 6 的现有应用 | Doconut.NET6 | 保持宿主目标，同时提供当前的依赖注入、中间件、异步会话以及可选的分布式模型。 |
| 需要 .NET Standard 合约的兼容 ASP.NET Core 宿主 | Doconut.NETStandard 26.8.0+ | 面向 .NET Standard 2.1，并为受支持的宿主提供当前的 Doconut 集成。 |
| 现有的 Doconut.NETStandard 26.7.0 或更早的集成 | 在选择 26.8.0+ 之前规划迁移 | 包 ID 保持不变，但目标和 API 版本会改变。 |
| 面向 .NET Framework 的应用 | Doconut.NETFramework | .NET Framework 无法使用 .NET Standard 2.1。 |
此表帮助缩小首要决策范围。许可、可选插件、文档格式、部署设计以及升级工作仍需单独验证。
为新 .NET 8 应用选择 Doconut.NET8
对于新 .NET 8 应用，专用包是最清晰的评估选择。.NET 8 查看器页面 描述了基于依赖注入、中间件提供资源、异步文档会话以及可选分布式工作流的当前模型。
直接的运行时匹配也使文档更易于阅读。安装、配置、故障排除、插件和示例都可以在同一框架路径下进行评估。
在采用之前，测试产品实际需要的文档格式和可选功能。包的匹配并不能取代关于身份验证、授权、存储、保留、监控和资源限制等应用层面的决策。
当宿主必须保持在 .NET 6 时选择 Doconut.NET6
一个已有的应用可能有依赖或支持承诺，使其必须停留在 .NET 6。 更新的 .NET 6 查看器 让应用在保持该目标的同时，迁移到 Doconut 当前的集成架构。
当运行时升级和文档查看器迁移不应在同一次发布中同时进行时，这非常有用。团队可以在保持宿主框架稳定的情况下，现代化查看器注册、资源交付、异步打开以及文档会话。
检查现有项目是使用经典的还是更新的 Doconut .NET 6 集成。仅凭包名可能无法判断代数。官方迁移文档会标识出区分它们的 API 签名和托管模式。
当契约符合解决方案时选择 Doconut.NETStandard
全新的 .NET Standard 2.1 安装指南 定义了兼容性边界。它支持 .NET Core 3.0 及更高版本的宿主，包括 .NET 5、6、7、8，并排除 .NET Framework。
当解决方案特别需要 .NET Standard 库契约时，这条路径是合理的。版本选择至关重要：Doconut.NETStandard 26.7.0 及之前的版本面向 .NET Standard 2.0 并使用旧的集成，而 26.8.0 及之后的版本面向 .NET Standard 2.1 并使用当前 API。
如果应用已经使用旧的包代数，请在更新前查阅 .NET Standard 迁移指南。此更改影响的不仅是编译：启动、查看器生命周期、资源路由、文档打开、授权、插件以及分布式发布都可能需要关注。
对比完整的应用影响
一个小的概念验证应回答的不仅是“包是否能安装？”请评估：
- 宿主兼容性： 确认应用的目标以及所有引用查看器包的项目。
- 集成代数： 确认是当前的还是经典的注册、查看器创建以及文档打开模式。
- 文档覆盖率： 测试产品所需的代表性 PDF、Office、CAD、图像、电子邮件或医学文件。
- 插件需求： 当工作流涉及时，分别验证搜索、注释、转换器或 DICOM 功能。
- 运行模型： 测试会话生命周期、缓存、资源交付、清理以及任何单节点或分布式设计。
- 升级工作量： 将框架更改与 Doconut 更改分离，以便更容易诊断故障。
- 应用控制： 验证周边系统中的访问、存储、保留和交付行为。
记录每个结果对应的包版本和框架目标。这样可以防止对某一 SDK 路径的成功测试被误认为是对另一条路径的证据。
明确框架选择
一份好的架构说明可以简短：说明应用目标、所选 Doconut 包及其版本、所需插件、部署模型以及实现过程中使用的文档路径。该决策记录有助于后续升级基于事实而非包名假设进行。
对于新的 .NET 8 开发，请使用专用的 .NET 8 SDK。对于仍停留在 .NET 6 的应用，请评估更新的 .NET 6 包。当 .NET Standard 2.1 契约适合兼容的宿主时，使用 Doconut.NETStandard 26.8.0 及以上版本，并让 .NET Framework 应用保持在其专用的包路径上。
查看 Doconut 文档中心 并 下载试用版 以使用您自己的应用和文档测试所选路径。