Escolhendo o SDK Doconut Certo: .NET Standard 2.1, .NET 6 ou .NET 8
← Back to Blog••6 min read

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.

Três caminhos de tempo de execução distintos convergindo em um único espaço de trabalho consistente de visualização de documentos
Três caminhos de tempo de execução distintos convergindo em um único espaço de trabalho consistente de visualização de documentos

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çãoCaminho Doconut a avaliarPor quê
Nova aplicação direcionada ao .NET 8Doconut.NET8Correspondê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 6Doconut.NET6Manté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árioDoconut.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 existentePlaneje 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 FrameworkDoconut.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:

  1. Compatibilidade do host: Confirme o alvo da aplicação e cada projeto que referencia o pacote do visualizador.
  2. 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.
  3. Cobertura de documentos: Teste arquivos representativos de PDF, Office, CAD, imagem, e‑mail ou médicos exigidos pelo produto.
  4. Necessidades de plugins: Valide individualmente as capacidades de Busca, Anotação, Conversor ou DICOM quando fizerem parte do fluxo de trabalho.
  5. Modelo operacional: Teste o tempo de vida da sessão, cache, entrega de recursos, limpeza e qualquer design de nó único ou distribuído.
  6. 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.
  7. 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.

#Doconut SDK#.NET Standard 2.1#.NET 6#.NET 8#Document Viewer#Visualizador de Documentos