Blazor Wasm Development Upgrades in JetBrains Rider 2024.1
Blazor was released almost five years ago, on September 23rd, 2019. Since then, the Blazor framework has evolved to introduce variations using web sockets via SignalR, WebAssembly (Wasm), and server-side rendering. Each approach has its benefits. However, developers have gravitated toward the simplicity of the Wasm model, likely due to a clear separation of client and server, an existing architecture of business APIs, and support for partly connected scenarios, amongst other reasons.
As Rider developer Andrii Rublov explained in “How JetBrains Rider Implemented .NET WebAssembly Debugging”, there are a lot of elements to Wasm applications, and getting the debugging experience “right” is a herculean effort. Luckily for Blazor Wasm enthusiasts, JetBrains Rider developers are demigods and have spent the better part of 2023 working to improve and finalize the Blazor Wasm debugging experience.
This post will explore the Blazor Wasm development workflow improvements, including hot reload scenarios, setting breakpoints, and the Multi-Launch run configuration.
Client-Server Solutions
When working on a Blazor Wasm application, you’re likely using a client/server configuration. The Blazor Wasm client communicates with a backend HTTP API in these solutions. These solutions typically have three projects: Client, Server, and Shared. Since you write Blazor Wasm using C#, you can share many models across the client and server boundary.
From a developer perspective, it’s C# all the way, a prime reason Blazor appeals to .NET developers. And what do .NET developers love the most? Tooling, of course! Debugging is the crown jewel of the .NET ecosystem, and it’s a non-negotiable aspect developers expect from all their tools. Whether we place breakpoints on the client or the server, we expect it just to work.
Let’s first look at the typical debugging experience most Blazor Wasm developers will likely use several times during their daily workflow.
Debugging for Blazor Wasm
In the JetBrains Rider 2024.1 release, Blazor practitioners will notice a more reliable debugging experience as they transition between the client and the server. It’s essential to start the host project first, which will be the Server project in the typical hosted scenarios.
The connection between JetBrains Rider and the client, a Chrome-based browser in most cases, will be more resilient than in previous versions. You’ll even notice the updated UI displays a browser app icon, reminding you that your code is executing on a client.
A stable connection affords you a smoother and more reliable development experience, which should make you happier. In other words, move fast and breakpoint things.
Also, people using JetBrains Rider debugging features such as expression evaluation and watches will notice a much-improved experience. Use these features to narrow down areas of interest in complex Blazor components and simplify your workflow.
As a bonus to Blazor developers and longtime Rider users, you can try our new Collections Visualizer to display enumerable implementations within the IDE.
Blazor Wasm Hot Reload Enhancements
Another enhancement to drop in JetBrains Rider 2024.1 is the ability to hot reload in run scenarios. The additional option can help you iterate faster and have a more enjoyable experience. JetBrains Rider will push any component or CSS changes to the connected client when any change is detected when possible. Your application does not need to be in a debug state.
You can also perform a hot reload when scoped CSS files are changed. If I modify Counter.razor.css, JetBrains Rider will push those to the client after a recompilation period.
Overall, it is a significant improvement that we know Blazor Wasm developers will love.
Note that Blazor Wasm supports Hot Reload for many code changes but not all.
Multi-Launch Run Configuration
While not directly related to Blazor Wasm, we’ve also introduced a brand-new run configuration called Multi-Launch. .NET developers are known for building large enterprise applications with the potential for multiple projects acting as a backend. In the following example, we’ll only launch our Blazor Wasm application host after we’ve started our other API project.
You’ll also be able to choose when and how the next step in a multi-launch configuration proceeds. Options include starting immediately, waiting for the previous task to complete, or listening for a specific port to become available.
You can also add additional tasks outside of run configurations, such as “Build Solution”, “Clean Solution”, “Publish Solution”, and “Idle”. If you have ideas for more tasks, please let us know in the comment below.
Template Improvements
Along with the improved coding and debugging workflows, we’ve also spent time updating Rider’s templates to quickly create additional resources, such as JavaScript and stylesheet files that are typically scoped to components. When adding a new Blazor Component, you can check options for “with Code-Behind File”, “with Scoped CSS”, and “with JS File”.
Conclusion
Blazor’s popularity amongst .NET developers is rising, and we at JetBrains want to support your interests and goals to build successful solutions. Rise to the challenge of delivering great user experiences with improvements to the Blazor Wasm experience. The 2024.1 changes include debugging reliability, Blazor Wasm hot reload for running scenarios, and Multi-Launch run configurations. All parts of an amazing developer product.
If you’d like to try these features early and provide feedback, download the current JetBrains Rider 2024.1 Early Access Preview from our site or use the JetBrains Toolbox for a side-by-side install.
Please let us know your thoughts in the comments section below.
Image credit: Wil Stewart
Subscribe to a monthly digest curated from the .NET Tools blog:
