You’ll likely encounter early bound types when developing workflows, plugins or anything else which calls the Dynamics 365 SDK. These are basically generated classes which come from Dynamics. You can generate them using the CrmSvcUtil.exe. If you’ve ever done anything with T4 templates you can think of them as that or a really poor substitute for F# type providers.
MiniKube is a Kubernetes distribution designed to make running a single node Kubernetes cluster easy for local development. However MiniKube relies on docker which relies on you having a Professional version of Windows on your laptop. If you don’t have that then it is really easy to stand up an Azure VM which can run MiniKube.
Dynamics 365 is a low code solution for a variety of different businesses offered by Microsoft. It is a fully hosted solution which means that you don’t really get access to the underlying database. That’s a good thing (less to manage) but also a bad thing (hard to work with for power users).
In this post we’ll look at how to manipulate records in the CRM using some powershell.
When it was announced the Roslyn would become the default compiler for C# in Visual Studio I was super excited. I felt like it would generate all sorts of domain specific languages, custom flavors of C#, tons of custom error providers. So here we are 5 years later and almost none of it has come to pass. Why not?
I’ve been on a bit of an Azure Functions kick over the last little while. I’ve blogged a bunch on Durable Functions and deployed a bunch more. When you’re as old as me then you tend to draw comparisons between new technologies and existing ones. For instance I’m constantly telling people about how web pages are a lot like the cave paintings I use to do in my youth.
The technology that draws the closest comparison I’ve seen to Durable Functions are NServiceBus Sagas. A few weeks ago I tweeted out wondering if any body had done a comparison. The good folks at Particular stepped up and answered.
In a previous article I talked about how to authenticate your function application against Azure Active Directory Business to Consumer (which we’re going to call B2C for the sake of my fingers). Chances are in your function you’re going to want to get some of the information which is available as a claim from the bearer token. Here is how to do it.
I have a durable functions project which orchestrates several thousand function calls the purpose of which is to scrape and load a bunch of data. It is scheduled to run once a day but one of my concerns was that I didn’t want to accidentally run to functions at the same time. They would duplicate a bunch of the data loading and, at least until the function ran again, chaos would reign. I’m not a huge fan of chaos reigning so I set out to find a way around this.
I had a pretty good struggle setting up Azure Functions and Azure B2C to work together. There are a few guides out there but I wanted to put my own together because I had a terrible time finding these posts initially. The scenario here is that we want a single page application written in React to talk to an API hosted entirely in Azure Functions such that the functions are authenticated.
C# AdventThis post is one among many which is part of 2018’s C# Advent. There are a ton of really great posts this year and some new bloggers to discover. I’d strongly encourage you to check it out.
One of the things you’ll learn a lot about if you pursue any sort of formal education in computing science is data structures. However, once I hit the real world then it seemed like for most problems the speed differential between a linked list and a System.Collections.Generic.List wasn’t meaningful. List quickly became my go-to and it was very unusual that any other data structure would even cross my mind. This sort of lazy thinking can have a serious effect as the size of input grows. So harkening back to my school days I wanted to talk about the rudimentary data structure that is a linked list.
Storage Queues are one of the original pieces of Azure dating back about a decade now. They are great for deferring work to later or spreading it out over a bunch of consumers. If you’re following best practices for DevOps you’ll know that the creation of your queues should be done in code. In some cases you can create the queues on application startup but in serverless scenarios there often is no startup code so the responsibility of creating queues falls to your deployment process. Let’s look at how to do that on Azure DevOps