Utilisation de Telerik Reporting dans les applications .NET Core

Dans la R1 2019, nous avons introduit le support dans les applications Telerik Reporting pour .NET Core fonctionnant sous Windows, Linux et macOS. Essayez et laissez vos commentaires!

Au cours des dernières années, .NET Core est passé d’une plate-forme modulaire du .NET Framework à une plate-forme entièrement fonctionnelle qui vous permet de créer et d’exécuter les mêmes applications sous Windows, Linux Et macOS. À chaque nouvelle version, .NET Core fournit de nouvelles API et ajoute de nombreuses optimisations, se positionnant finalement comme un cadre de choix pour de plus en plus de développeurs .NET. Il n'est donc pas surprenant que la fonctionnalité la plus demandée dans le Feedback Portal pour Telerik Reporting était de fournir un support pour les applications .NET Core.

Naturellement curieux, nous, membres de l'équipe de création de rapports Nous surveillons depuis longtemps l'évolution de .NET Core et nous avons récemment décidé que le cadre était suffisamment mature pour répondre à la plupart de nos besoins. Et voici que dans R1 2019 nous avons introduit le support .NET Core pour l'exécution de Telerik Reporting.

Conforme aux normes

Les assemblys de Telerik Reporting peuvent être référencés via les packages NuGet à partir de notre flux privé Telerik NuGet ou via des références d'assemblages aux fichiers .dll locaux. Si vous vérifiez le répertoire d'installation de notre produit, vous remarquerez que la dernière version a été complétée par un nouvel ajout: un sous-dossier netstandard2.0. Il contient les assemblys auxquels vous feriez référence lors de la construction d'une application .NET Core, mais ces derniers ciblent eux-mêmes .NET Standard 2.0. .NET Standard est un ensemble d’API fondamentales disponibles dans toutes les implémentations .NET . Conçu comme une spécification formelle, il détermine un ensemble de fonctionnalités de base pour l'écosystème .NET

Le principal avantage du ciblage de .NET Standard est que nos assemblys fonctionnent dans toutes les applications .NET sur tous les systèmes d'exploitation pris en charge. 19659007] dotnet-frameworks-diagram "title =" dotnet-frameworks-diagram "/>

image obtenue à partir de blogs.msdn.microsoft.com

Une fonctionnalité intéressante de l'unification de cross- Le développement de la plate-forme signifie que les assemblys .NET Standard peuvent être référencés même dans votre application .NET Framework actuelle. Mais pourquoi ?, demandez-vous. Eh bien, ce n'est pas obligatoire, car nous fournissons déjà des assemblys Telerik Reporting ciblant l'ensemble du projet .NET Cette approche présente toutefois au moins deux avantages majeurs: elle offre les avantages liés à l'optimisation dans .NET Standard et facilite le processus de migration éventuel de votre application vers .NET Core.

• Toutes les extensions de rendu, à l'exception de MHTML et XPS, sont prises en charge sous Windows.
• Les rendus HTML, PDF et OpenXML sont pris en charge sous Linux / macOS.
• Tous les éléments de rapport, à l'exception de les éléments de graphique obsolètes sont pris en charge.
• Les types de définition de rapport pris en charge sont TRDX, TRDP et les classes de rapport, créés dans Visual studio sans code spécifique au concepteur VS.
• Une nouvelle configuration de génération de rapports basée sur JSON est introduite pour les interfaces de ligne de commande et des applications Web. Pour les projets CLI, la configuration JSON est prioritaire sur la configuration de génération de rapports actuelle basée sur XML. Cliquez ici pour plus de détails

Ce qui n’est pas inclus

Pour concevoir des rapports pour un projet .NET Core, nous vous recommandons d’utiliser Standalone Report Designer. Ses définitions de rapport sont stockées dans un format .trdx / .trdp portable et peuvent être utilisées avec UriReportSource si nécessaire.

Le concepteur de rapports Visual Studio est disponible uniquement pour les bibliothèques de classes qui ciblent l'intégralité de la structure .NET. Nous ne pouvons pas fournir de support au moment de la conception pour les rapports dans les bibliothèques .NET Core ou .NET Standard, car nous sommes limités par l'état actuel du framework et du jeu d'outils Visual Studio. Par exemple, la classe ComponentDesigner, utilisée comme classe de base pour nos composants, n'est pas encore disponible dans .NET Core. En ce qui concerne la migration des bibliothèques de rapports existantes, cet article de la base de connaissances vous aidera à choisir la bonne stratégie.

Comment l'exécuter sous Linux?

Lors du déploiement sur une machine Linux, assurez-vous qu'il a installé la bibliothèque libgdiplus qui est une implémentation Mono de l'API GDI + pour les systèmes d'exploitation non Windows. L'extrait suivant effectue une mise à jour et installe les bibliothèques nécessaires sur Ubuntu / Debian :

 sudo apt-get update 
 sudo apt-get install libc6-dev 
 sudo apt-get install libgdiplus 

Etant donné que libgdiplus n'est pas un remplaçant exact de la bibliothèque graphique Windows, les rapports rendus pourraient ne pas avoir le même positionnement, le même habillage et le même alignement du texte, par rapport aux rapports rendus sous Windows. Nous avons apporté de nombreuses améliorations au moteur de rendu du texte et des graphiques, mais de légères différences sont à prévoir.

Et comment puis-je l'exécuter sur macOS?

De la même manière que sur Linux, la différence réside uniquement dans le script qui installe la bibliothèque libgdiplus :

 brasser installer mono-libgdiplus 

Wow. Qu'en est-il des conteneurs?

Aucun problème, tant que l'image du conteneur répond aux exigences de GDI +. Les images microsoft / windowsservercore distribuées par Microsoft contiennent la bibliothèque graphique, mais leur taille est nettement plus grande que celle de l'exécution dotnet dans un conteneur Linux. Ce conteneur nécessite uniquement l'installation de libgdiplus et des bibliothèques qui l'accompagnent, ce qui peut être effectué à l'aide de l'extrait de dockerfile suivant:

 FROM microsoft / dotnet: base AS 2.1-runtime 
 RUN apt-get update  
 && apt-get install -y --allow-unauthenticated  
 libc6-dev  
 libgdiplus  
 libx11-dev  
 && rm -rf / var / lib / apt / lists / * 

L'installation de ces trois bibliothèques garantit que Telerik Reporting sera exécuté sur l'image Docker produite.

Incroyable, mais comment je commence?

Telerik Reporting est fourni avec un exemple ASP.NET Core prêt à l'emploi qui montre comment afficher nos exemples de rapports dans une application ASP.NET Core. L'exemple montre également comment injecter un contrôleur dans le fichier de configuration appsettings.json et comment initialiser un WebHostBuilder afin qu'il s'exécute sous Windows Linux et macOS . Le projet se trouve dans le répertoire % programfiles (x86)% Progress Telerik Reporting R1 2019 Examples CSharp Asp.NetCoreDemo .

Conclusion

Construire Telerik Reporting pour .NET Core a été un exploit pour notre équipe. Cela nous permettra de toucher un public plus large de développeurs souhaitant créer des applications multiplateformes modernes. L'ajout de la plate-forme de développement qui évolue le plus rapidement est une nouvelle étape dans la fourniture d'un produit de qualité supérieure à nos utilisateurs.

Essayez-le et partagez vos commentaires

Si vous êtes un nouvel utilisateur de nos outils ou n'avez fait que l'essayer, faites-le. Assurez-vous de télécharger la version d’essai et de l’essayer. Vous pouvez télécharger uniquement les outils Reporting et Report Server ou télécharger une version d'essai de l'ensemble de nos outils .NET et JavaScript avec le kit DevCraft . [19659018] Nous sommes impatients d'entendre ce que vous pensez. N'oubliez donc pas de partager également vos commentaires et aidez-nous à améliorer encore les rapports Telerik.