System.Text.Json focuses primarily on performance, security, and standards compliance. It has some key differences in default behavior and doesn’t aim to have feature parity with Newtonsoft.Json. For some scenarios, System.Text.Json has no built-in functionality, but there are recommended workarounds. For other scenarios, workarounds are impractical. If your application depends on a missing feature, consider filing an issue to find out if support for your scenario can be added.
Nothing can be more frustrating than going into a situation “thinking” you know how a framework works, only to spend the next several hours pulling your hair out and stewing in a pot of unhealthy feelings. I like to consider myself an ASP.NET routing expert with my experience dating back to MVC 1.0. Recently, I’ve started using ASP.NET Core Razor Pages mixed in with MVC and API approaches. I find the combination of all this technology to be a winning one, but it can also add complexity when building views. In this post, I’ll show you a simple one page Razor Page that can help diagnose route resolution issues quickly. Quickly see what your ASP.NET Core application sees and what it requires to resolve routes.
MessagePack for C# Version 2 was released in 2019–12–16. The main implementation was done by Andrew Arnott who is a software engineer at Microsoft, Visual Studio Team. I checked the API design and performance and took care of the Unity compatibility. This collaboration took almost a year, and I think we did a great job.
When we maintain a library that’s used by others, we want to shield them from breaking changes and use SemVer as a way of indicating breaking changes when they do occur. If our public API changes in a way that is considered a breaking change, wouldn’t it be great if we were notified so that we can bump that major version number?
One of the great aspects of ASP.NET Core is that logging is built-in to the framework. That means you can (if you want to) get access to all the deep infrastructural logs from your own standard logging infrastructure. The down side to this is that sometimes you can get too many logs.
As customers move .NET workloads to the cloud, many start to consider containerizing their applications because of the agility and cost savings that containers provide. Combine those compelling drivers with the multi-OS capabilities that come with .NET Core, and customers have an exciting reason to migrate their applications. A primary question is how they can safely store secrets and sensitive configuration values in containerized workloads. In this video, learn how to safely containerize an ASP.NET Core application while leveraging services like AWS Secrets Manager and AWS Fargate.
.NET added async/await to the languages and libraries over seven years ago. In that time, it’s caught on like wildfire, not only across the .NET ecosystem, but also being replicated in a myriad of other languages and frameworks. It’s also seen a ton of improvements in .NET, in terms of additional language constructs that utilize asynchrony, APIs offering async support, and fundamental improvements in the infrastructure that makes async/await tick (in particular performance and diagnostic-enabling improvements in .NET Core).
However, one aspect of async/await that continues to draw questions is ConfigureAwait. In this post, I hope to answer many of them. I intend for this post to be both readable from start to finish as well as being a list of Frequently Asked Questions (FAQ) that can be used as future reference.
To really understand ConfigureAwait, we need to start a bit earlier…
“Producer/consumer” problems are everywhere, in all facets of our lives. A line cook at a fast food restaurant, slicing tomatoes that are handed off to another cook to assemble a burger, which is handed off to a register worker to fulfill your order, which you happily gobble down. Postal drivers delivering mail all along their routes, and you either seeing a truck arrive and going out to the mailbox to retrieve your deliveries or just checking later in the day when you get home from work. An airline employee offloading suitcases from a cargo hold of a jetliner, placing them onto a conveyer belt, where they’re shuttled down to another employee who transfers bags to a van and drives them to yet another conveyer that will take them to you. And a happy engaged couple preparing to send out invites to their wedding, with one partner addressing an envelope and handing it off to the other who stuffs and licks it.
I started as .NET Foundation Executive Director in February 2017, and a lot has happened over the past nearly three years. We’ve added dozens of high quality projects and added a lot of services to support them, like automated code signing and releases. We launched a worldwide Meetup program that includes over a quarter of a million members, and supported them with hundreds of local events in our .NET Conf Local series. We’ve also ushered in substantial changes, literally years in the making, to open up membership, run an election for the board’s first elected directors, introduce a corporate sponsorship program, and lay the groundwork for the .NET Foundation to grow into its next stage.
When we move from a monolith to microservices we abandon integrating via a shared database, as each service must own its own data to allow them it to be autonomous. But now we have a new problem, our data is distributed. What happens if I need one service needs to talk to another about a shared concept such as a product, a hotel room, or an order? Does every service need to have a list of all our users? Who knows what users have permissions to the entities within the micro service? What happens if my REST endpoint needs to include data from a graph that includes other services to make it responsive? And I am not breaking the boundary of my service when all of this data leaves my service boundary in response to a request?
Naive request-based solutions result in chatty calls as each service engages with multiple other services to fulfil a request, or in large message payloads as services add all the data required to process a message to each message. Neither scale well.
In 2005, Pat Helland wrote a paper ‘Data on the Inside vs. Data on the Outside’ which answers the question by distinguishing between data a service owns and reference data that it can use. Martin Fowler named the resulting architectural style; Event Driven Collaboration. This style is significant because it shifts the pattern from request to receiver-driven flow control.
In this presentation we will explain how events help us integrate our service architectures. We’ll provide examples in C#, Python and Go as well as using RMQ and Kafka.
eff is a software developer, an entrepreneur, and an attorney. As a consultant at WWT Asynchrony Labs, with unique experiences that combine technology and law, he maintains a passion for solving problems with inspired solutions, improving life through technology. A dedicated member of the developer community, Jeff travels internationally to speak on both technical and business-oriented topics. He is a Microsoft MVP and enjoys serving on the board of directors for the Kansas City Developer Conference.