.NET Coded Report Design, No IDE Strings Attached

Bringing Visual Studio design-time support for .NET reports has been quite a journey for the Progress Telerik Reporting team. See where we are now, how and why we’ve gone this direction, and where we’re headed.

This blog post tells the story of our efforts to implement the by far most requested feature to Progress Telerik Reporting during the past years—Visual Studio design-time support for .NET reports. It may have taken time, but we wanted to be sure to provide the best possible user experience. We wanted to make sure this feature would be an improvement for our most faithful clients, not a new hurdle.

Now, with a clear path ahead, we are ready to be open with you about both future plans and past missteps. We believe that your feedback and trust will help us turn this into something much more than an implementation of a catch-up feature. We want it to become the better way of handling code reports, with no technological strings attached, great flexibility and parity with all the other moving parts of our offering.

A Look Back

Since the first version of our Visual Studio designer, coded reports have been a first-class feature for Telerik Reporting. Our decision back then to build from the (now legacy) Visual Studio designer API helped us have full integration between our framework and the IDE. That made us a tool of choice for users who seek the flexibility of programmatic reports across the variety of reporting products on the market.

The decision by Microsoft to introduce a new paradigm for the native Visual Studio designer caught us off guard. It introduced the concept of splitting the former workflow into two processes that handle UI (client) and design-time logic (server) separately that run on different runtimes—.NET Framework for client, and .NET for server. Back then, we jumped into adapting to this new paradigm immediately, starting our effort while the new implementation by Microsoft was still in early preview.

Things did not look hopeful at first—the new core designer API changed a lot of the mechanics that we had taken for granted. We were faced with the choice to either rush to a full rewrite of the design-time logic or go on a migration path, trying to adapt our vast designer codebase to operate with the new concepts. We believed that the second approach would provide results more consistent with the existing design-time experience that we provided, so we took that approach.

The team at Microsoft helped us identify a lot of the things that were incompatible with our existing implementation, and we made iterative progress with every new preview version of their designer. Things soured when it turned out that a major hurdle challenged the success of the initiative—the new API did not support custom root designer implementations.

In 2024, Microsoft implemented custom root designer support. But while the former impediment was no longer present, the officially released final API of the Visual Designer changed a lot in comparison to the preview versions that we had based our efforts on. Yet again we were closer to the start than to the end of the endeavor.

A Pivot

But what if the problem had more than one solution? We zoomed out to the bigger picture, and we saw that the landscape had changed a lot:

• .NET is now much more versatile than the .NET Framework had ever been.
• Linux is not the exotic option for the tech stack that it used to be and is now the first-choice environment for an increasing share of the userbase.
• The vast majority of Telerik Reporting users moved to developing web applications.
• Visual Studio’s leading .NET IDE role is challenged by the advance of VS Code and other IDEs by a variety of vendors.
• WinForms, the technology behind VS Designer, is officially in maintenance mode by Microsoft.

All these developments were too large of a factor to ignore, so the new solution needed to address them. To do so, we would need to figure out how to create for our Visual Studio designer:

• A powerful WYSIWYG report component design experience, along with multiple dedicated tools and editors
• A serialization mechanism that turned the designed report into correct C# code stored as partial (.Designer.cs) file
• Complete developer freedom to integrate any custom logic in the report’s so-called code-behind, including event handlers, business logic integration and even report definition modifications

Luckily, we had a solution to the first problem. We already had two separate design surfaces that we actively enhance with new features—the standalone designer and the web report designer.

Writing code, as we noted earlier, is not necessarily done in Visual Studio. It is possible in any editor of choice, as long as we have the report definition represented as C# code. That led us to the single indispensable benefit that Visual Studio provides and we do not—C# report serialization. We decided to turn it into our immediate priority.

Now we were developing our own module to handle code serialization. It would use the CodeDOM serializer API by Microsoft but skip the restrictive dependencies to UI technology and design-time APIs.

Being excited about the results of the new approach, we wanted to share that early progress with you today. The Standalone Report Designer (SRD), being a desktop piece, seemed more of a fit than the Web Report Designer to be the first place where we would integrate it. Thus, with the latest Release of Telerik Reporting, SRD is now able to work with existing .NET 8+ code reports. 

Mentioning .NET 8 might sound a bit too restrictive—what if the majority of your reports are still .NET Framework–based? We have strived to make the Telerik Reporting code API is framework-agnostic, so copying the existing source code files in a fresh new .NET 8 project might only require small changes for a complete migration.

So How to Use My .NET Reports in the Standalone Designer ?

You can access your coded report by opening the code (.cs) file through the standard open report UI. The designer file will be automatically detected and a (.csproj) file will be suggested. In case you are using more than one project for the same codebase, you are free to modify the selection. Once compiled and approved, the assembly is added to the trusted types list, so exercise caution with injected code. Additional dependencies should be trusted separately.

So far, things look similar to importing a report library using the designer. However, this new option is much more dynamic. Any change in the report will be applied in the designer partial file by serializing the change into C# in live sync.

Be advised that our algorithm mimics the VS one only semantically. This means that the initial report modification will introduce significant changes in the serialized code, but the component tree will be preserved. Please use versioning for your reports in order to have clear tracking of the changes. The non-designer partial class files stay intact, so custom code is preserved and ready to work alongside the generated design logic.

These modifications can be immediately incorporated within the assembly logic by the “Rebuild” and “Preview with code-behind” commands.

What’s Next?

With this first iteration, we wanted to cover the toolset that users had with Visual Studio. We are treating the current version as a strong preview rather than a complete solution, so we expect that things will change and improve fast from here. We anticipate SRD to be much more stable in the Q3 release, at which point we expect to have documentation ready as well.

We are aware of some existing issues with the serialization engine, and we are already working on stabilizing it. Our next steps are fixed on developing resource manager for better consistency with existing (.resx) files; reduce the difference between the output of the VS algorithm and ours. We will be also revising the tooling to make the handling of code reports more natural.

We have a vision of our roadmap ahead, but we want to hear your voice. What would help you? Give it a shot and share your thoughts with us. We are here to listen and act upon your feedback.

Remember that Telerik Reporting comes with the Telerik DevCraft bundle, which you can try for free:

Try DevCraft