Desarrollo de Crystal Reports para Visual Studio en .NET 5: Planes para el Futuro Cercano

Es una lástima porque .NET Core SÍ tiene soporte para llamar a COM desde .NET Core 3.0 en adelante.

El desarrollo multiplataforma no es estrictamente un requisito al crear una biblioteca de .NET Core; mira la biblioteca de Windows Desktop que Microsoft ha desarrollado para trasladar cosas como WPF y WinForms a .NET Core 3 (funciona solo en Windows).

Por lo tanto, aunque hacer que el tiempo de ejecución funcione en .NET Core no nos proporcionaría soporte multiplataforma, nos permitiría utilizar las herramientas y bibliotecas actuales de .NET, lo cual sería bastante útil.

Actualmente estás limitado a utilizar herramientas y bibliotecas antiguas de Microsoft si estás desarrollando un proyecto que requiere el Crystal Runtime.

Gracias por los detalles.

Como han comentado otros, hay interoperabilidad COM a partir de .NET Core 3 en Windows.

¿Es el soporte de .NET 5 en Windows solo usando COM (no multiplataforma) algo en lo que el departamento de investigación y desarrollo pueda volver a analizar en el futuro?

Hola a todos,

Crystal Reports está basado en tecnologías escritas en C++. Siempre ha sido así, incluso antes de mi tiempo cuando empecé con CR 5 (1997). En aquel entonces era de 16 o 32 bits y se distribuía en múltiples disquetes de 3.5". Al mismo tiempo lanzamos CR para VS 6, a través de un envoltorio COM alrededor del núcleo crpe32.dll con varios envoltorios OCX y otros envoltorios basados en COM.

Crpe32.dll está escrito en C++...

En los siguientes años expandimos y escribimos el RDC - Componente de Diseño de Informes, otro envoltorio COM basado en crpe32. Teníamos un desarrollador viviendo en la sede de Microsoft trabajando con su desarrollador para integrar nuestros componentes principales en .NET.

A partir de CR 9 comenzamos a deprecar el RDC, porque Microsoft lanzó el nuevo Marco .NET.

R&D comenzó a expandir los componentes de CR para VS .NET con la ayuda de Microsoft, ya que anunciaron que estaban abandonando COM y querían que todos pasaran a .NET. Así que eliminamos el RDC y nos movimos completamente a .NET, que es simplemente otro envoltorio alrededor de nuestro motor principal.

En aquel entonces tenías que usar el Marco Completo, la versión 1.x Light no funcionaría con CR debido a las limitaciones que tenía.

Por supuesto, con la retroalimentación de la industria, Microsoft cedió y continuó apoyando COM, pero nosotros ya nos habíamos comprometido, por lo que el Marco se convirtió en el nuevo SDK para CR.

Ahora viene Mobile y el nuevo marco CORE de Microsoft, aún basado en el Marco original (más o menos), pero en sus primeros días era bastante limitado, nada que CR pudiera utilizar. El Core 5 está mucho más avanzado, pero aún no es un reemplazo directo para 4.8.

Como mencionó Mike:

"Sin embargo, el Marco .NET seguirá siendo atendido con correcciones mensuales de seguridad y fiabilidad. Además, seguirá incluido en Windows, sin planes de eliminarlo."

No desaparecerá.....

Si deseas usar CR, también tienes la opción de usar Java, que es multiplataforma y el SDK RESTful (para BOE).

Hay otras opciones para poder mover las aplicaciones Core 5, procesar los informes en un servidor y transmitir los resultados a dispositivos móviles, por ejemplo. Escribir una DLL para procesar el informe, etc....

He tenido múltiples discusiones con R&D y en este momento simplemente no es posible para ellos integrar/usar Core 5, no digo que en algún momento futuro pueda ser posible, pero todo depende de lo que haga Microsoft.

Se requeriría una reescritura completa para deshacerse de COM y ser más abierto a plataformas, algo que en este momento no puede justificarse en términos de costos.

Sabemos que todos desean el soporte de Core 5+, pero debido a la naturaleza de nuestro SDK, es algo que no se puede integrar en este momento.

Para más información, crpe32 ha existido desde la época en que aún caminaban los dinosaurios, se ha optimizado hasta el punto en que más del 90% del tiempo está esperando resultados o entrada de alguna fuente para realizar el siguiente trabajo.

No hay más que decir, para seguir utilizando CR .NET debes usar el marco completo.

Es simplemente otro marco que Microsoft está desarrollando y que no admite completamente componentes C++:

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

Por lo tanto, convertir nuestro motor principal crpe32.dll de C++ a Core tendría grandes limitaciones, en este momento no es una opción. Posiblemente alguna versión futura de CORE pueda admitir completamente C++ utilizando algún tipo de envoltorio, pero no ahora...

Tenemos un lugar para agregar Solicitudes de Mejora, nuestro Producto y desarrolladores lo monitorean, así que publica tu solicitud aquí:

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

No digo que alguna vez suceda, pero al menos puedes votar a favor.

Don

Actualización:

Microsoft nos hizo esto alrededor de los días de CR 8.5, dijeron que ya no habría soporte para COM, así que escribimos nuestros componentes .NET que envolvían nuestros dll's de C++ y COM para trabajar con el marco .NET. Luego, ustedes, la industria, se opusieron y Microsoft continuó apoyando COM. Para ese entonces era demasiado tarde para volver a COM para nosotros.

Así que hemos pasado por esto antes, necesitan presionar a Microsoft y lograr que continúen apoyando .NET 4.8 o hacer que el soporte de 5.x+ sea compatible con aplicaciones 4.8. Por cierto, como se mencionó, no están poniendo fin a la vida de 4.x, simplemente no están haciendo mejoras.