Desenvolvimento de Crystal Reports para Visual Studio no .NET 5: Planos para o Futuro Próximo

É uma pena porque o .NET Core só tem suporte para chamar o COM a partir do .NET Core 3.0 em diante.

O desenvolvimento multiplataforma não é estritamente um requisito ao criar uma biblioteca do .NET Core; veja a biblioteca Windows Desktop que a Microsoft desenvolveu para migrar coisas como WPF e WinForms para o .NET Core 3 (funciona apenas no Windows).

Portanto, embora fazer com que o tempo de execução funcione no .NET Core não nos forneça suporte multiplataforma, nos permitiria usar as ferramentas e bibliotecas atuais do .NET, o que seria bastante útil.

Atualmente, você está limitado a usar ferramentas e bibliotecas antigas da Microsoft se estiver desenvolvendo um projeto que requer o Crystal Runtime.

Obrigado pelos detalhes.

Como outros mencionaram, há interoperabilidade COM a partir do .NET Core 3 no Windows.

Será que o suporte do .NET 5 no Windows, utilizando apenas COM (não multiplataforma), é algo que o departamento de pesquisa e desenvolvimento pode reconsiderar no futuro?

Olá a todos,

Crystal Reports é baseado em tecnologias escritas em C++. Sempre foi assim, mesmo antes do meu tempo quando comecei com CR 5 (1997). Naquela época era de 16 ou 32 bits e era distribuído em múltiplos disquetes de 3.5". Ao mesmo tempo, lançamos o CR para VS 6, através de um invólucro COM em torno do núcleo crpe32.dll com vários invólucros OCX e outros invólucros baseados em COM.

Crpe32.dll é escrito em C++...

Nos anos seguintes, expandimos e escrevemos o RDC - Componente de Design de Relatórios, outro invólucro COM baseado em crpe32. Tínhamos um desenvolvedor vivendo na sede da Microsoft trabalhando com seu desenvolvedor para integrar nossos componentes principais no .NET.

A partir do CR 9 começamos a depreciar o RDC, porque a Microsoft lançou o novo Framework .NET.

O R&D começou a expandir os componentes do CR para VS .NET com a ajuda da Microsoft, já que anunciaram que estavam abandonando o COM e queriam que todos migrassem para o .NET. Então, eliminamos o RDC e nos mudamos completamente para o .NET, que é apenas outro invólucro em torno de nosso motor principal.

Naquela época, você tinha que usar o Framework Completo, a versão 1.x Light não funcionaria com o CR devido às limitações que tinha.

Claro, com o feedback da indústria, a Microsoft cedeu e continuou a apoiar o COM, mas nós já estávamos comprometidos, então o Framework se tornou o novo SDK para o CR.

Agora vem o Mobile e o novo framework CORE da Microsoft, ainda baseado no Framework original (mais ou menos), mas em seus primeiros dias era bastante limitado, nada que o CR pudesse usar. O Core 5 está muito mais avançado, mas ainda não é um substituto direto para o 4.8.

Como Mike mencionou:

"No entanto, o Framework .NET continuará sendo mantido com correções mensais de segurança e confiabilidade. Além disso, continuará incluído no Windows, sem planos de eliminá-lo."

Não desaparecerá.....

Se deseja usar o CR, também tem a opção de usar o Java, que é multiplataforma e o SDK RESTful (para BOE).

Existem outras opções para poder mover as aplicações Core 5, processar os relatórios em um servidor e transmitir os resultados para dispositivos móveis, por exemplo. Escrever uma DLL para processar o relatório, etc....

Tive múltiplas discussões com R&D e no momento simplesmente não é possível para eles integrar/usar o Core 5, não digo que em algum momento futuro possa ser possível, mas tudo depende do que a Microsoft fizer.

Seria necessária uma reescrita completa para se livrar do COM e ser mais aberto a plataformas, algo que no momento não pode ser justificado em termos de custos.

Sabemos que todos desejam o suporte do Core 5+, mas devido à natureza de nosso SDK, é algo que não pode ser integrado no momento.

Para mais informações, crpe32 existe desde os tempos em que ainda caminhavam os dinossauros, foi otimizado a ponto de mais de 90% do tempo estar esperando por resultados ou entrada de alguma fonte para realizar o próximo trabalho.

Não há mais o que dizer, para continuar usando o CR .NET você deve usar o framework completo.

É apenas outro framework que a Microsoft está desenvolvendo e que não suporta completamente componentes C++:

https://docs.microsoft.com/en-us/dotnet/core/porting/cpp-cli

Portanto, converter nosso motor principal crpe32.dll de C++ para Core teria grandes limitações, no momento não é uma opção. Possivelmente em alguma versão futura do CORE poderá suportar completamente C++ utilizando algum tipo de invólucro, mas não agora...

Temos um local para adicionar Solicitações de Melhoria, nosso Produto e desenvolvedores monitoram, então publique sua solicitação aqui:

https://www.sap.com/about/customer-involvement/influence-adopt.html

Não digo que alguma vez aconteça, mas pelo menos pode votar a favor.

Don

Atualização:

A Microsoft nos fez isso por volta dos dias do CR 8.5, disseram que não haveria mais suporte para COM, então escrevemos nossos componentes .NET que envolviam nossos dlls de C++ e COM para trabalhar com o framework .NET. Depois, vocês, a indústria, se opuseram e a Microsoft continuou apoiando o COM. Naquela época, era tarde demais para voltar ao COM para nós.

Então passamos por isso antes, precisam pressionar a Microsoft e garantir que continuem apoiando o .NET 4.8 ou tornar o suporte de 5.x+ compatível com aplicativos 4.8. Aliás, como mencionado, não estão encerrando a vida do 4.x, simplesmente não estão fazendo melhorias.