Development with a Dot

Introduction You may not know, but Visual Studio (or more accurately,  MSBuild and other tools used implicitly) can make use of local files to configure some aspects of its working. In this post I will introduce and explain why we should use (at least) some of them. These files apply regardless of the solution format in use, are not related to a specific format. Here is the list with a brief summary of what each file is for. Of course, other files may be used for other purposes and different technologies somewhat outside the control of Visual Studio/MSBuild (e.g., NPM , Less , etc). File Purpose Directory.Build.props Defines shared MSBuild properties for projects under that directory tree. Imported early in the build. Commonly used for target frameworks, nullable settings, analysers, company metadata, ...

Introduction This is part two of my series on the agent orchestration framework I'm building in .NET. You really should read the first part, Introduction , before this one, so if you haven't already, take the time to do so now! In this post I'm going to talk about the orchestrator, the central piece of the framework. I'm going to describe its contract and how we should use it. Some related parts will be covered in other posts. The IOrchestrator Interface The orchestrator is main part of the framework, as I said before. It is the one that coordinates - with some assistance - the different agents, distributes the work to be done, enforces reviews and revision processes, then gathers all responses and summarises them. The interface that describes the orchestrator is IOrchestrator  (surprise, surprise), and this is what it looks like: public interface IOrchestrator : IDisposable { event EventHandler<OrchestrationEventArgs>? OrchestrationStarting; event E...