In order to centrally manage package versions, you can now leverage the Directory.Build.targets feature. Without going into too much detail (the linked document explains it well), Directory.Build.targets can be used to provide customizations to project files located under a certain directory (within a directory tree).
I remember seeing this from David Kean several months back on Twitter. This is incredibly useful for keeping versions of packages consistent across projects.
Here is the idea: If you have never heard about the REST architectural style constraints and their implication on the properties of the resulting distributed system and you do not want to (or can’t) educate yourself, use GraphQL.
With all the buzz on Twitter about REST and GraphQL, I figured I’d toss this post in the mix. Worth reading the comments as well to get a bigger picture. Seems like people either sit in the REST (not CRUD but with Hypermedia) or the GraphQL camp, and nowhere in between.
Four years ago we open sourced the C# and Visual Basic compilers and exposed their functionality through APIs as the Roslyn project. The Roslyn analyzer API empowers the developer community to be more productive by lighting up their own features in the editor in real-time–meaning anyone can write a refactoring, code fix, code style rule, or code diagnostic.
Come learn more about the Roslyn project, new APIs we’re adding, and what these live analyzers mean for you and your productivity.
I’ve always been interested in writing an Roslyn Analyzer but just wasn’t really sure where or how to get started. If you feel the same, I recommend checking out this talk.
Blazor 0.5.0 is now available! This release explores scenarios where Blazor is run in a separate process from the rendering process. Specifically, Blazor 0.5.0 enables the option to run Blazor on the server and then handle all UI interactions over a SignalR connection. This release also adds some very early support for debugging your Blazor .NET code in the browser!