Development with a Dot

Introduction This will be the first post on AI that I write, which is really a shame, as it's such an interesting and vast topic; you should expect more in the future! This time I'm going to talk about code generation from inside .NET using OpenAI  and it's Azure integration , in a structured way. As you know, code generation is one of the typical usages for Large Language Models (LLMs); it is part of what is called generative AI . It essentially works out of the box, but we can tweak it to be more useful. In this post I’ll show how we can get multiple files in response to a prompt. We will use Azure, but all the concepts are really from OpenAI. Let's start from the beginning. Setting Up OpenAI in Azure From the Azure portal , start by creating a new resource of type Microsoft Foundry  (it supports OpenAI  and others): QIf you need more info on this operation, please have a look here . You can now see it in the dashboard page: The end...

Introduction Note: some people complained that what I actually called Dependency Injection is actually Inversion of Control. I won’t get into that fight, to me, Dependency Injection is a form of Inversion of Control. The  Strategy Pattern  (sometimes known as Policy) originated in the seminal book Design Patterns , by the Gang of Four. It is a behavioural design pattern  that allows picking a specific strategy at runtime. The concrete strategy to use can change dramatically how the application behaves. Quoting: instead of implementing a single algorithm directly, code receives runtime instructions as to which in a family of algorithms to use. Dependency Injection (DI), also known as Inversion of Control (IoC) - they’re not quite the same, but, for the purpose of this post, we can think of them as the same, even though this raises heated discussions - is built-in in .NET Core (now, .NET) since the start, and whilst we generally return the same implementation type ...

Introduction We all know  EF Core Migrations . They have been around for quite some time, some people like them, others prefer alternatives (hello, Flyway , DbUp , FluentMigrator !). I'm not going to discuss that, but, instead, how to seed data to a database, either using EF Core migrations or not. This is, of course, for inserting initial/reference data that must always be present, for Microsoft's opinion on this, please see this page . This post assumes that you know about migrations - how to create and apply them, at least, and that you have all it takes for it, including  EF Core Tools  and the  Microsoft.EntityFrameworkCore.Design  NuGet package. Migrations and the creation methods ( EnsureCreated , EnsureCreatedAsync ) are mutually exclusive , so you need to pick one, depending on your strategy. For actually adding data, we have essentially four options: Explicit insertions Data-only migrations Entity configuration Context configuration (explicit seeding)...

Introduction This is the second in a series of posts on .NET synchronisation: In-process synchronisation Out-of-process synchronisation on the same machine (this post) Distributed synchronisation This time I'm going to talk about using the synchronisation APIs I described on the first post , dedicated to in-process synchronisation, but in out-of-process context, meaning, to synchronise different processes, not threads. This can be achieved out of the box with three synchronisation objects: Mutex Semaphore EventWaitHandle  (remember, parent class of AutoResetEvent and ManualResetEvent ) These objects follow the same pattern: open (fails if doesn't exist) or try to open an existing object by its name.  For a synchronisation object to be available system-wide it needs a name and can have fine-grained permissions on Windows systems. I will cover permissions more to the end of this post. I will also be covering an additional technique that can also be used for synchronisation: s h...

Introduction This is the first in a series of posts on .NET synchronisation. I will cover: In-process synchronisation (this post) Out-of-process synchronisation on the same machine Distributed synchronisation In .NET, in-process synchronisation mechanisms are used to restrict access to shared resources and manage concurrency in multi-threaded applications. The mechanisms I'm going to present on this post can be used only for in-proc code, for synchronising threads, meaning, they cannot be used to synchronise multiple processes, on the same or on different machines - I will write more posts on these subjects and link them here. Here I will be using the terms "locking" and "synchronising on" interchangeably, to mean the same thing. I won't go into too much theory, but thread synchronisation exists for preventing: Race conditions: two threads trying to modify the same data simultaneously Data corruption: data shared by two or more threads becomes inconsistent ...