
Escolhendo o SDK Doconut Certo: .NET Standard 2.1, .NET 6 ou .NET 8
Comece com o host da aplicação
Escolher um pacote Doconut começa com o projeto que o executará. Uma nova aplicação web .NET 8, um serviço .NET 6 já estabelecido e um host ASP.NET Core compatível com biblioteca podem todos precisar de visualização de documentos incorporada, mas suas restrições de framework e planos de atualização diferem.

Doconut oferece caminhos de SDK atuais para .NET 8, .NET 6 e hosts compatíveis que consomem o novo pacote .NET Standard 2.1. A escolha correta costuma ser o pacote que corresponde diretamente ao host e deixa a menor ambiguidade de framework para a equipe que mantém a aplicação.
A Visão geral do SDK Doconut Viewer é o ponto de partida para as capacidades do produto. Use a documentação específica do framework para tomar a decisão do pacote.
Entenda o que os três rótulos significam
.NET 8 e .NET 6 são alvos de aplicação. Uma aplicação web pode direcionar-se a um desses runtimes e selecionar o pacote Doconut correspondente.
.NET Standard 2.1 é diferente: ele define um contrato de API de biblioteca que hosts .NET compatíveis podem consumir. Doconut 26.8.0 introduz a geração atual Doconut.NETStandard para aplicações que visam .NET Core 3.0 ou posterior, incluindo .NET 5 até .NET 8. Não pode ser consumido por .NET Framework.
Essa distinção mantém a decisão fundamentada. Não escolha .NET Standard 2.1 apenas porque parece mais geral; escolha-o quando seu contrato for adequado ao host e à estrutura da solução.
Uma tabela prática de seleção
| Situação da aplicação | Caminho Doconut a avaliar | Por quê |
|---|---|---|
| Nova aplicação direcionada ao .NET 8 | Doconut.NET8 | Correspondência direta para o desenvolvimento .NET atual e o caminho completo de documentação do .NET 8. |
| Aplicação existente que deve permanecer no .NET 6 | Doconut.NET6 | Mantém o alvo do host enquanto fornece a injeção de dependência, middleware, sessão assíncrona e modelo distribuído opcional atuais. |
| Host ASP.NET Core compatível onde o contrato .NET Standard é necessário | Doconut.NETStandard 26.8.0+ | Alvo .NET Standard 2.1 e expõe a integração Doconut atual para hosts suportados. |
| Integração Doconut.NETStandard 26.7.0 ou anterior existente | Planeje uma migração antes de selecionar 26.8.0+ | O ID do pacote permanece o mesmo, mas o alvo e a geração da API mudam. |
| Aplicação direcionada ao .NET Framework | Doconut.NETFramework | .NET Framework não pode consumir .NET Standard 2.1. |
Esta tabela restringe a primeira decisão. Licenciamento, plugins opcionais, formatos de documento, design de implantação e esforço de atualização ainda precisam de validação separada.
Escolha Doconut.NET8 para novas aplicações .NET 8
Para uma nova aplicação .NET 8, o pacote dedicado é a escolha mais clara a ser avaliada. A Página do Visualizador .NET 8 descreve o modelo atual baseado em injeção de dependência, recursos servidos por middleware, sessões assíncronas de documentos e fluxos de trabalho distribuídos opcionais.
Uma correspondência direta de runtime também facilita o acompanhamento da documentação. Instalação, configuração, solução de problemas, plugins e exemplos podem ser avaliados dentro de um único caminho específico de framework.
Antes da adoção, teste os formatos de documento e os recursos opcionais que o produto realmente necessita. Uma correspondência de pacote não substitui decisões ao nível da aplicação sobre autenticação, autorização, armazenamento, retenção, monitoramento e limites de recursos.
Escolha Doconut.NET6 quando o host deve permanecer no .NET 6
Um aplicativo estabelecido pode ter dependências ou compromissos de suporte que o mantêm no .NET 6. O Visualizador .NET 6 atualizado permite que o aplicativo mantenha esse alvo enquanto migra para a arquitetura de integração atual da Doconut.
Isso é útil quando uma atualização de runtime e uma migração do visualizador de documentos não devem acontecer na mesma versão. A equipe pode modernizar o registro do visualizador, a entrega de recursos, a abertura assíncrona e as sessões de documentos, mantendo o framework do host estável.
Verifique se o projeto existente usa a integração clássica ou atualizada do Doconut .NET 6. Apenas os nomes dos pacotes podem não revelar a geração. A documentação oficial de migração identifica as assinaturas de API e os padrões de hospedagem que os distinguem.
Escolha Doconut.NETStandard quando o contrato se adequa à solução
O novo guia de instalação do .NET Standard 2.1 define o limite de compatibilidade. Ele suporta hosts .NET Core 3.0 e posteriores, incluindo .NET 5, 6, 7 e 8, e exclui o .NET Framework.
Este caminho pode fazer sentido quando a solução requer especificamente o contrato da biblioteca .NET Standard. A seleção da versão é crítica: Doconut.NETStandard 26.7.0 e anteriores visam .NET Standard 2.0 e usam a integração anterior, enquanto 26.8.0 e posteriores visam .NET Standard 2.1 com a API atual.
Se o aplicativo já usa a geração de pacote mais antiga, consulte o guia de migração do .NET Standard antes de atualizar. A mudança afeta mais do que a compilação: inicialização, tempo de vida do visualizador, roteamento de recursos, abertura de documentos, licenciamento, plugins e publicação distribuída podem precisar de atenção.
Compare o impacto completo na aplicação
Uma pequena prova de conceito deve responder mais do que “o pacote instala?”. Avalie:
- Compatibilidade do host: Confirme o alvo da aplicação e cada projeto que referencia o pacote do visualizador.
- Geração da integração: Identifique o registro atual ou clássico, a criação do visualizador e os padrões de abertura de documentos.
- Cobertura de documentos: Teste arquivos representativos de PDF, Office, CAD, imagem, e‑mail ou médicos exigidos pelo produto.
- Necessidades de plugins: Valide individualmente as capacidades de Busca, Anotação, Conversor ou DICOM quando fizerem parte do fluxo de trabalho.
- Modelo operacional: Teste o tempo de vida da sessão, cache, entrega de recursos, limpeza e qualquer design de nó único ou distribuído.
- Esforço de atualização: Separe as mudanças de framework das mudanças da Doconut para que as falhas sejam mais fáceis de diagnosticar.
- Controles da aplicação: Verifique o acesso, armazenamento, retenção e comportamento de entrega no sistema circundante.
Registre a versão do pacote e o alvo do framework ao lado de cada resultado. Isso impede que um teste bem‑sucedido em um caminho de SDK seja interpretado erroneamente como evidência sobre outro.
Torne a escolha do framework explícita
Uma boa nota de arquitetura pode ser breve: indique o alvo da aplicação, o pacote Doconut selecionado e sua versão, os plugins necessários, o modelo de implantação e o caminho da documentação usado durante a implementação. Esse registro de decisão ajuda as atualizações posteriores a partir de fatos, em vez de suposições baseadas no nome do pacote.
Para desenvolvimento novo em .NET 8, comece com o SDK dedicado ao .NET 8. Para uma aplicação que permanece no .NET 6, avalie o pacote .NET 6 atualizado. Use Doconut.NETStandard 26.8.0+ quando o contrato .NET Standard 2.1 for a escolha correta para um host compatível, e mantenha as aplicações .NET Framework em seu caminho de pacote dedicado.
Revise o hub de documentação da Doconut e baixe uma avaliação para testar o caminho selecionado com sua própria aplicação e documentos.