DEV Community

Dave Brock
Dave Brock

Posted on • Originally published at daveabrock.com on

The .NET Stacks #9: Project Coyote, new Razor editor, and more!

Newsletter image

This is the web version of my weekly newsletter, The .NET Stacks, which is published online a week after the newsletter ships. Subscribe today to get this content right away!

So, what do you think? I changed newsletter providers and got a new look (thanks to @comfycoder for the logo help). I hope you like it. It works on my machine, and I hope it works on yours too. šŸ˜Ž

Any suggestions? Hit me up on Twitter or just reply to this e-mail. Iā€™m all ears on what content youā€™d likeā€”I want to make this the best part of your Monday!

This week weā€™re talking about debugging async with Coyote, an exciting new Razor editor in Visual Studio, a fun look at unit testing, and more!

Debug async issues faster with Coyote

Isnā€™t async programming fun? Itā€™s so much fun, you can probably relate to this. (If youā€™ve spent months on a single concurrency issue, it might also make you cry.)

All jokes aside, itā€™s a concurrent world and we just live in it. Our customers demand it. In this microservice-friendly, cloud-first world, we want things fast and efficient at the lowest cost possible. In the cloud, minimizing cost requires high throughput, which requires high concurrency. If you havenā€™t pulled your hair out from a concurrency/threading issue, to that I say: welcome to our field. I hope you had a nice graduation party.

We know this is hard, and thatā€™s why we rely on the .NET framework to handle most of the magic for us. With the Task Parallel Library (TPL) and async/await, we donā€™t have to worry about thread scheduling, state management, or other hard low-level details.

However, we also get flexibility with APIs like Task.Run that give us the power to queue workā€”if we donā€™t know exactly what weā€™re doing, we can get in loads of trouble. Even with high code coverage, powerful integration testing, and stress testing, we still know weā€™re not too far from a concurrency issue that will cost our customers (and our employers) tons of time and money.

Meet Coyote, a set of tools that help you find these seemingly impossible-to-reproduce bugs quicker. (It is an evolution of the P# project, and is moving out of research mode.)

How does this work? After you write code that uses the Coyote programming modelā€”the familiar task-based model in in previewā€”you can run coyote test, where the magic begins. When you run this, Coyote manages task scheduling and explores all the complexities of your code. Coyote runs tests repeatedly with ā€œdifferent scheduling choicesā€ each time. If a bug is found, Coyote reports a reproducible bug trace, which can be replayed until you find the bug.

Coyote has been put through its paces for various Azure services and promises integration with unit testing frameworks and minimal overhead. Is it worth it for internal CRUD apps? Maybe not. But if you are operating at tremendous scale where concurrency issues keep you up at night, it might be a game-changer.

Thereā€™s so much to take in! Check out the resources for more details on Project Coyote.

New Razor editor for Visual Studio in preview

It seems like weā€™re constantly getting news of a new Visual Studio preview feature, and this week is no exception. If you download Visual Studio 2019 16.7 Preview 4 (got all that?) you can use a brand new Razor editor to assist your local development with Blazor, MVC, and Razor Pages.

Most of us know Razor but if you donā€™t: itā€™s a templating language (using HTML and, most frequently, C#) you use to define how you dynamically render content in your ASP.NET app. With Blazor, you can reuse UI components using .razor files. Razor in Visual Studio comes with IntelliSense, completions, and the like. Why a new editor, then?

Today, Visual Studio does a lot of tricks behind the scenes with projection buffers for the different languages it supports. For example, if you have C# and HTML in a Razor file, Visual Studio reads the Razor file from disk, sends the code to a Razor buffer, a C# buffer, and an HTML buffer. Finally, each buffer uses its own independent language service for each language you use. Oof.

Why should you care? If youā€™ve signed a lifetime contract to use Visual Studio and youā€™re a team of one, fineā€”but if you want extensibility with Codespaces or Live Share in VS, youā€™re in trouble. All these dependencies require a lot of work to coordinate and can hinder the speed of future improvements.

To address this, Microsoft has been working on a Razor Language Server that implements the features you know and love through a common protocol. Wherever the extension exists (VS, VS Code, wherever), it coordinates with the Razor Language Server.

This solution is currently used for Razor support in VS Code, and will be used for Codespaces and LiveShare for Visual Studio. And now, you can try the VS implementation today (in preview). It has some rough edges, but I look forward to see how it performs. I do know Razor mostly works well but can exhibit some inconsistent performance. Will this help?

šŸŒŽ Last week in the .NET world

Iā€™m trying a new format this week so you can sift through the links easier.

šŸ”„ The Top 3

šŸ“¢ Announcements

šŸ“… Community and events

šŸ˜Ž Blazor

šŸš€ .NET Core

ā›… The cloud

šŸ“” Languages

šŸ”§ Tools

šŸ“± Xamarin

šŸŽ¤ Podcasts

šŸŽ„ Videos

Top comments (0)