Development with a Dot

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. For actually adding data, we have essentially four options: Explicit insertions Data-only migrations Entity configuration Context configuration (explicit seeding) Let's see them all one by one. Using Explicit Insertions The first case is pretty obvious: we add data explicitly after we forced pending migrations ...

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 ...