Conception de rapport codé .NET, aucune chaîne IDE attachée

Apporter la prise en charge du temps de conception de Visual Studio pour les rapports .NET a été un voyage pour l’équipe de reportage Progress Telerik. Voyez où nous sommes maintenant, comment et pourquoi nous avons fait cette direction et où nous nous dirigeons.

Ce billet de blog raconte l’histoire de nos efforts pour mettre en œuvre la fonctionnalité de loin la plus demandée pour progresser Reporting Telerik Au cours des dernières années, la prise en charge visuelle de conception de studio pour les rapports .NET. Cela a peut-être pris du temps, mais nous voulions être sûrs de fournir la meilleure expérience utilisateur possible. Nous voulions nous assurer que cette fonctionnalité serait une amélioration pour nos clients les plus fidèles, pas un nouvel obstacle.

Maintenant, avec un chemin clair à venir, nous sommes prêts à être ouverts avec vous à la fois sur les plans futurs et les faux pas. Nous pensons que vos commentaires et votre confiance nous aideront à transformer cela en quelque chose de bien plus qu’une implémentation d’une fonction de rattrapage. Nous voulons que cela devienne le meilleur moyen de gérer les rapports de code, sans aucune chaîne technologique attachée, une grande flexibilité et une grande parité avec toutes les autres parties mobiles de notre offre.

Un regard en arrière

Depuis la première version de notre Designer Visual Studioles rapports codés ont été une fonctionnalité de première classe pour Telerik Reporting. Notre décision à l’époque de construire à partir de l’API (maintenant héritage) Visual Studio Designer nous a aidés à avoir une intégration complète entre notre cadre et l’IDE. Cela a fait de nous un outil de choix pour les utilisateurs qui recherchent la flexibilité des rapports programmatiques à travers la variété des produits de rapport sur le marché.

La décision de Microsoft d’introduire un nouveau paradigme pour le concepteur de Visual Studio native nous a pris au dépourvu. Il a introduit le concept de division de l’ancien flux de travail en deux processus qui gèrent séparément l’interface utilisateur (client) et la logique de conception (serveur) qui s’exécutent sur différents frameworks d’exécution –.net pour le client et .NET pour le serveur. À l’époque, nous nous sommes immédiatement adaptés à ce nouveau paradigme, commençant nos efforts tandis que la nouvelle implémentation de Microsoft était encore en avant-première.

Les choses ne semblaient pas espéreres au début – la nouvelle API de concepteur de base a changé une grande partie des mécanismes que nous avions tenus pour acquis. Nous avons été confrontés au choix de nous précipiter vers une réécriture complète de la logique de conception-temps ou de suivre un chemin de migration, essayant d’adapter notre vaste base de code de concepteur pour fonctionner avec les nouveaux concepts. Nous pensions que la deuxième approche fournirait des résultats plus cohérents avec l’expérience de conception existante que nous avons fournie, nous avons donc adopté cette approche.

L’équipe de Microsoft nous a aidés à identifier de nombreuses choses incompatibles avec notre implémentation existante, et nous avons fait des progrès itératifs avec chaque nouvelle version d’aperçu de leur concepteur. Les choses se sont germées lorsqu’il s’est avéré qu’un obstacle majeur a contesté le succès de l’initiative – la nouvelle API n’a pas pris en charge les implémentations de concepteurs racines personnalisées.

En 2024, Microsoft a implémenté la prise en charge personnalisée des concepteurs de racines personnalisées. Mais alors que l’ancien obstacle n’était plus présent, l’API finale officiellement publiée du concepteur visuel a beaucoup changé par rapport aux versions de prévisualisation sur lesquelles nous avions basé nos efforts. Encore une fois, nous étions plus proches du début que de la fin de l’effort.

Un pivot

Mais que se passe-t-il si le problème avait plus d’une solution? Nous avons zoom sur la situation dans son ensemble, et nous avons vu que le paysage avait beaucoup changé:

• .NET est désormais beaucoup plus polyvalent que le framework .NET.
• Linux n’est pas l’option exotique pour la pile technologique qu’elle était et est maintenant l’environnement de premier choix pour une part croissante de la base d’utilisateurs.
• La grande majorité des utilisateurs de Telerik signalent les applications Web en développement.
• Le principal rôle d’IDE .NET de Visual Studio est contesté par l’avance du code vs et d’autres IDE par une variété de fournisseurs.
• WinForms, la technologie derrière VS Designer, est officiellement en mode de maintenance par Microsoft.

Tous ces développements étaient trop importants à ignorer, donc la nouvelle solution devait les résoudre. Pour ce faire, nous devons comprendre comment créer pour notre concepteur Visual Studio:

• Une puissante expérience de conception de composants de rapport WYSIWYG, ainsi que plusieurs outils et éditeurs dédiés
• Un mécanisme de sérialisation qui a transformé le rapport conçu en code C # correct stocké comme fichier partiel (.design.cs)
• La liberté complète du développeur d’intégrer toute logique personnalisée dans le soi-disant code du rapport, y compris les gestionnaires d’événements, l’intégration de la logique métier et même les modifications de définition du rapport

Heureusement, nous avions une solution au premier problème. Nous avions déjà deux surfaces de conception distinctes que nous améliorons activement avec de nouvelles fonctionnalités: le concepteur autonome et le concepteur de rapport Web.

L’écriture de code, comme nous l’avons noté plus tôt, n’est pas nécessairement fait dans Visual Studio. Il est possible dans n’importe quel éditeur de choix, tant que la définition du rapport est représentée par le code C #. Cela nous a conduits à l’avantage indispensable unique que Visual Studio fournit et nous ne faisons pas – C # Rapport la sérialisation. Nous avons décidé de le transformer en notre priorité immédiate.

Maintenant, nous développions notre propre module pour gérer la sérialisation du code. Il utiliserait l’API de sérialiseur de codés par Microsoft mais sauterait les dépendances restrictives à la technologie de l’interface utilisateur et aux API de conception-temps.

Étant enthousiasmé par les résultats de la nouvelle approche, nous voulions partager ces progrès précoces avec vous aujourd’hui. Le Concepteur de rapports autonomes (SRD), étant une pièce de bureau, semblait plus une ajustement que le concepteur de rapport Web comme le premier endroit où nous l’intégrerions. Ainsi, avec la dernière version de Telerik Reporting, SRD est désormais en mesure de travailler avec des rapports de code .NET 8+ existants. Nous prévoyons que SRD soit beaucoup plus stable dans la version Q3, à quel point nous nous attendons à avoir des documents prêts également

Mentionner .NET 8 peut sembler un peu trop restrictif – que si la majorité de vos rapports sont toujours basés sur .NET? Nous nous sommes efforcés de faire de l’API du code de rapport Telerik est agnostique, donc la copie des fichiers de code source existant dans un nouveau projet .NET 8 peut ne nécessiter que de petites modifications pour une migration complète.

Alors, comment utiliser mes rapports .NET dans le concepteur autonome?

Vous pouvez accéder à votre rapport codé en ouvrant le fichier de code (.cs) via l’interface utilisateur standard du rapport ouvert. Le fichier concepteur sera automatiquement détecté et un fichier (.csproj) sera suggéré. Dans le cas où vous utilisez plus d’un projet pour la même base de code, vous êtes libre de modifier la sélection. Une fois compilé et approuvé, l’assemblage est ajouté à la liste des types de confiance, alors faites preuve de prudence avec du code injecté. Les dépendances supplémentaires devraient être Confiance séparément.

Jusqu’à présent, les choses ressemblent à l’importation d’une bibliothèque de rapports à l’aide du concepteur. Cependant, cette nouvelle option est beaucoup plus dynamique. Tout changement dans le rapport sera appliqué dans le designer Fichier partiel en sérialisant la modification en C # en live Sync.

Soyez avisé que notre algorithme imite le VS One uniquement sémantiquement. Cela signifie que la modification initiale du rapport introduira des changements importants dans le code sérialisé, mais l’arborescence des composants sera conservée. Veuillez utiliser le versioning pour vos rapports afin d’avoir un suivi clair des modifications. Le non-concepteur Les fichiers de classe partiels restent intacts, donc le code personnalisé est conservé et prêt à fonctionner aux côtés de la logique de conception générée.

Ces modifications peuvent être immédiatement incorporées dans la logique d’assembly par les commandes «Rebuild» et «Aperçu avec code-Behind».

Quelle est la prochaine étape?

Avec cette première itération, nous voulions couvrir l’ensemble d’outils que les utilisateurs avaient avec Visual Studio. Nous traitons la version actuelle comme un aperçu fort plutôt que comme une solution complète, nous nous attendons donc à ce que les choses changent et s’améliorent rapidement à partir d’ici.

Nous sommes conscients de certains problèmes existants avec le moteur de sérialisation, et nous travaillons déjà à le stabiliser. Nos prochaines étapes sont fixées sur le développement de Resource Manager pour une meilleure cohérence avec les fichiers (.resx) existants; Réduisez la différence entre la sortie de l’algorithme VS et le nôtre. Nous réviserons également l’outillage pour rendre la gestion des rapports de code plus naturels.

Nous avons une vision de notre feuille de route à venir, mais nous voulons entendre votre voix. Qu’est-ce qui vous aiderait? Donnez-lui une chance et partagez vos pensées avec nous. Nous sommes ici pour écouter et agir sur vos commentaires.

N’oubliez pas que Telerik Reporting est livré avec le pack Telerik Devcraft, que vous pouvez essayer gratuitement:

Essayez Devcraft