Tag: Azure

If you’re building workloads on Azure Functions, there’s a good chance you’ve looked at building custom bindings. Custom bindings can greatly reduce the boilerplate code you have to write in an Azure Function, so you can focus on the logic in your function instead. There are various examples of custom bindings out there, including several that I wrote while working on Indexing and searching NuGet.org with Azure Functions and Search. And then .NET 5 came, along with the new Azure Functions .NET Isolated Worker. Not a lot of documentation out there, and custom bindings don’t seem to work anymore…

In this blog post, we’ll see how we can use Azurite, an open source Azure Storage API compatible server (emulator), in Docker, and how to run it from JetBrains Rider. We can use Azurite in Docker to keep Azure Storage data local to a solution, and, for example, have different blobs and queues for different Azure Functions projects. Ever since I started playing with Azure back in 2008, I’ve been using the Azure Storage Emulator to have a local storage emulator to develop with. It provides a local environment for testing applications that use Azure blob and/or queues.

In the .NET team at JetBrains, we try to be as responsive as possible on Twitter when there are mentions of ReSharper, Rider, or any of the profiling tools. Many of our developer advocates, as well as the development team, QA and marketing, are active on Twitter and keep an eye on what’s being talked about, to try and help out wherever and whenever they can.

This week, I was presenting at IglooConf (Indexing and searching NuGet org with Azure Functions and Search). During one of the demos, I casually used a feature we shipped with the latest Azure Toolkit for JetBrains Rider: when the Azure Functions host is running on a development machine, Rider lets us trigger functions from the gutter by generating an HTTP request for it.

I know, I know. That title is probably a bit too harsh and opinionated. But it got your attention, right? A friend of mine this week asked me whether they could use middleware in their HTTP-triggered Azure Functions, ideally even the same ones they use in ASP.NET Core applications. After all, the SDK comes with HTTP triggers that seem to use the same infrastructure, right? My immediate response was “whyyyyyy?!?”. And in this blog post, I’ll try to explain. via GIPHY

In an application I’m writing, I need to deserialize some JSON. I know the class to use is JsonConvert, but which NuGet package was that type in again? Granted, that’s an obvious one. Yet, there are many uses for a “NuGet reverse package search” that helps finding the correct NuGet package based on a public type.

At Microsoft Build 2018, a number of Azure App Service on Linux enhancements were announced. One that I was interested in was this one: Remote debugging, in public preview: You can now choose to remote debug your Node.JS applications running on App Service on Linux. Sweet! But… how? The blog post did not mention a lot of details on the debugging part, so let’s walk through it, shall we? Remote debugging of Node.js apps on Azure App Service from WebStorm! First of all, we will need a number of things on our machine: The latest version of the Azure CLI 2.0

I have decided to retire from the Microsoft MVP program. In the first week of April, an e-mail from Microsoft landed in my mailbox. I was given the choice to either remain an active MVP (but without access to NDA content) until my next renewal period, or retire from the program.

A while back, the Azure folks announced support for Java on Azure Functions. My immediate thought was: “Do they mean Java or JVM? And if they mean JVM, will it work with Kotlin?” In this blog post, we’ll find out! (and if you’re a .NET developer, you’ll learn a bit about that other platform: the JVM) Azure Functions are Microsoft Azure’s event-driven, serverless compute experience. That’s all the buzzwords, probably, but it boils down to not having to worry about virtual machines, sites, …

Two weeks ago I had a wonderful experience speaking at a small conference in Finland. The talk was titled What is going on - Application diagnostics on Azure (slides) and focused on the importance of semantic logging and how Azure Application Insights (AppInsights) can help make sense of that data and correlate it with other telemetry coming from the application server. What I did not cover in that talk was AppInsights telemetry processors - essentially a pipeline through which your server-side AppInsights data passes before it is sent off to the giant data store that is the AppInsights service.