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.