DEV Community: Michael Brennan

How Two Markdown Files Completely Changed My Visual Studio + Copilot Workflow

Michael Brennan — Mon, 02 Mar 2026 19:12:32 +0000

TL;DR — I added copilot-instructions.md and copilot-prompts.md to my solution root, configured Visual Studio to use them as persistent workspace context, and Copilot went from 'sometimes helpful' to 'consistently reliable teammate.'

The Problem: Copilot Without Guardrails

In real-world enterprise codebases, you often have a mix of legacy and modern applications, backend APIs, frontend SPAs, background services, strict conventions, and CI/CD constraints.
Without persistent context, Copilot can guess API shapes, place interfaces in the wrong files, mix architectural patterns, remove code unintentionally, or ignore naming conventions.
In large, long-lived systems, that creates friction and architectural drift.

The Fix: Persistent Workspace Context

Instead of rewriting instructions in every chat session, I created two files at the solution root:
• copilot-instructions.md
• copilot-prompts.md
These files act as architectural guardrails, a style guide, a repeatable workflow engine, and a living AI contract — all version-controlled with the repository.

File #1 — copilot-instructions.md
This file defines standing directives and architectural rules. It serves as onboarding documentation for your AI teammate.
Example directives:
• Ask questions before writing code if anything is unclear
• Do not remove existing code unless explicitly asked
• Do not guess API shapes or endpoints
• Place TypeScript interfaces one per file in /models
• Put all HTTP logic in service files
• Follow feature-based folder organization
• Use consistent styling conventions
You can also include high-level project structure, technology constraints, naming conventions, build pipeline rules, and legacy vs modern boundaries

Visual Studio will look for this file as configured under Tools>Options>Github

I added this directive as well:

look for a file copilot-prompts.md in the same folder as the solution for additional context. A prompt in the chat window of "Go" means look at the context files and do the actions described there

File #2 — copilot-prompts.md
This file stores repeatable workflow prompts for common development tasks.
Examples:
• Add new feature module (create models, services, components properly)
• Compare legacy page to modern SPA implementation
• Refactor safely without removing existing code
• Scaffold dialogs following existing patterns
Instead of rewriting long prompts in chat, you can trigger workflows with a simple keyword like 'Go' while referencing workspace context.

This file is not in source control, individual users can edit it on the fly during sessions.

How to Configure Visual Studio

Place both Markdown files at the solution root.
Enable workspace context for Copilot.
Use workspace references when prompting.
Standardize trigger words for repeatable flows. Because copilot-instructions.md lives in the repository, it applies across machines and developers, evolve with the codebase, and reduce architectural entropy.

Real Improvements

• Fewer hallucinated APIs
• Cleaner frontend structure
• Safer legacy modifications
• Less prompt rewriting
• Architecture enforced as code

The Bigger Insight

AI productivity does not come from clever prompts alone. It comes from persistent context, explicit constraints, clear boundaries, and repeatable workflows.
Treat Copilot like a junior developer: give it structure and guardrails, and it becomes dramatically more effective.

If You Want to Try This

Create:
• copilot-instructions.md
• copilot-prompts.md
Define your architecture rules, naming conventions, workflow patterns, and non-negotiables. Keep it high-level, clear, and safe.
Your AI pair programmer — and your future self — will thank you.

Implementing Distributed Caching with Redis in Azure Functions

Michael Brennan — Fri, 01 Nov 2024 15:54:30 +0000

In modern applications, distributed caching is an essential tool for improving performance and scalability. One popular option for distributed caching is Redis, an in-memory key-value store that can handle large amounts of data with low latency.

In this guide, we'll implement distributed caching using Redis in an Azure Function App, following clean architecture principles. We'll also follow best practices by injecting services using interfaces, which makes the code more flexible and easier to test.

Project Structure

The project follows the clean architecture pattern, splitting the code into distinct layers:

FunctionApp: Contains the Azure Function entry point.
Application: Handles business logic and service classes.
Domain: Defines the core entities.
Infrastructure: Implements external dependencies like Redis caching and repositories.

Solution Folder Structure

AzureFunctionRedisCleanArchitecture/
├── AzureFunctionRedisCleanArchitecture.sln
├── FunctionApp/
│   ├── FunctionApp.csproj
│   ├── Startup.cs
│   └── Functions/
│       └── ProductFunction.cs
├── Application/
│   ├── Application.csproj
│   ├── Extensions/
│   │   └── ApplicationServicesExtensions.cs
│   ├── Interfaces/
│   │   └── IProductService.cs
│   ├── Services/
│       └── ProductService.cs
├── Domain/
│   ├── Domain.csproj
│   └── Entities/
│       └── Product.cs
└── Infrastructure/
    ├── Infrastructure.csproj
    ├── Extensions/
    │   └── InfrastructureServicesExtensions.cs
    └── Repositories/
        └── CachedProductRepository.cs

1. Azure Function App

The FunctionApp is the entry point for our Azure Function. It will handle HTTP requests and use the services defined in the Application layer. Here, we inject IProductService instead of the concrete ProductService, following the Dependency Inversion Principle.

FunctionApp/Startup.cs

This file configures the dependency injection for the Function App, pulling in both the Application and Infrastructure services.

using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyInjection;
using Application.Extensions;
using Infrastructure.Extensions;

[assembly: FunctionsStartup(typeof(FunctionApp.Startup))]

namespace FunctionApp
{
    public class Startup : FunctionsStartup
    {
        public override void Configure(IFunctionsHostBuilder builder)
        {
            string redisConnectionString = Environment.GetEnvironmentVariable("RedisConnectionString");

            builder.Services
                .AddApplicationServices()      // Add business services
                .AddInfrastructureServices(redisConnectionString);  // Add Redis caching and repositories
        }
    }
}

FunctionApp/Functions/ProductFunction.cs

This function handles HTTP requests to fetch a product. It uses the IProductService interface from the Application layer, which interacts with the repository layer to fetch the product from the cache or database.

using Application.Interfaces;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using System.Threading.Tasks;

namespace FunctionApp.Functions
{
    public class ProductFunction
    {
        private readonly IProductService _productService;

        public ProductFunction(IProductService productService)
        {
            _productService = productService;
        }

        [FunctionName("GetProduct")]
        public async Task<IActionResult> GetProduct(
            [HttpTrigger(AuthorizationLevel.Function, "get", Route = "product/{id:int}")] HttpRequest req, int id)
        {
            var product = await _productService.GetProductByIdAsync(id);
            return new OkObjectResult(product);
        }
    }
}

2. Application Layer

The Application layer contains business logic. We have added the IProductService interface to abstract the business logic provided by ProductService. This interface allows us to inject the service easily and makes testing easier.

Application/Interfaces/IProductService.cs

using Domain.Entities;
using System.Threading.Tasks;

namespace Application.Interfaces
{
    public interface IProductService
    {
        Task<Product> GetProductByIdAsync(int id);
    }
}

Application/Services/ProductService.cs

The ProductService implements the IProductService interface. It uses the repository to fetch data from Redis or the simulated database.

using Application.Interfaces;
using System.Threading.Tasks;
using Domain.Entities;

namespace Application.Services
{
    public class ProductService : IProductService
    {
        private readonly IProductRepository _productRepository;

        public ProductService(IProductRepository productRepository)
        {
            _productRepository = productRepository;
        }

        public async Task<Product> GetProductByIdAsync(int id)
        {
            return await _productRepository.GetProductByIdAsync(id);
        }
    }
}

3. Cache Invalidation on Update

When updating the product, we need to ensure the cache is invalidated (or refreshed) to avoid stale data. The CachedProductRepository class has an UpdateProductAsync method that removes the old product from the cache after updating it in the database.

Infrastructure/Repositories/CachedProductRepository.cs

This repository interacts with Redis to cache and fetch the product, and it invalidates the cache after the product is updated.

using Application.Interfaces;
using Domain.Entities;
using Microsoft.Extensions.Caching.Distributed;
using Newtonsoft.Json;
using System.Threading.Tasks;

namespace Infrastructure.Repositories
{
    public class CachedProductRepository : IProductRepository
    {
        private readonly IDistributedCache _cache;

        public CachedProductRepository(IDistributedCache cache)
        {
            _cache = cache;
        }

        public async Task<Product> GetProductByIdAsync(int id)
        {
            var cacheKey = $"Product_{id}";
            var cachedProduct = await _cache.GetStringAsync(cacheKey);

            if (!string.IsNullOrEmpty(cachedProduct))
            {
                return JsonConvert.DeserializeObject<Product>(cachedProduct);
            }

            // Simulate fetching from database (placeholder for actual DB logic)
            var product = new Product { Id = id, Name = $"Product {id}", Price = 100 + id };

            var productJson = JsonConvert.SerializeObject(product);
            await _cache.SetStringAsync(cacheKey, productJson, new DistributedCacheEntryOptions
            {
                AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(10)
            });

            return product;
        }

        public async Task UpdateProductAsync(Product product)
        {
            // Simulate updating the product in the database

            // Invalidate cache for the updated product
            var cacheKey = $"Product_{product.Id}";
            await _cache.RemoveAsync(cacheKey);

            // Optionally, re-add the updated product to the cache
            var productJson = JsonConvert.SerializeObject(product);
            await _cache.SetStringAsync(cacheKey, productJson, new DistributedCacheEntryOptions
            {
                AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(10)
            });
        }
    }
}

Dependency Injection for Infrastructure

We use Redis for caching in this repository, and it is registered in the DI container through an extension method.

In our implementation, we use the IDistributedCache interface provided by .NET. It abstracts the distributed caching system, allowing us to use different caching providers like Redis. You can read more about IDistributedCache in the official Microsoft documentation.

Infrastructure/Extensions/InfrastructureServicesExtensions.cs

using Microsoft.Extensions.DependencyInjection;
using StackExchange.Redis;
using Application.Interfaces;
using Infrastructure.Repositories;
using Microsoft.Extensions.Caching.StackExchangeRedis;

namespace Infrastructure.Extensions
{
    public static class InfrastructureServicesExtensions
    {
        public static IServiceCollection AddInfrastructureServices(this IServiceCollection services, string redisConnectionString)
        {
            // Set up Redis distributed caching
            services.AddStackExchangeRedisCache(options =>
            {
                options.Configuration = redisConnectionString;
            });

            // Register Redis connection
            services.AddSingleton<IConnectionMultiplexer>(sp =>
                ConnectionMultiplexer.Connect(redisConnectionString));

            // Register repository with caching
            services.AddScoped<IProductRepository, CachedProductRepository>();

            return services;
        }
    }
}

Conclusion

In this example, we’ve used Redis as a distributed caching solution in an Azure Function App. The ProductFunction fetches products using a service, which interacts with the caching layer. When a product is updated, the cache is invalidated to ensure that the next request fetches the fresh data.

This setup improves performance by reducing database load while ensuring cache consistency after updates.

Harnessing Extension Methods for DI in Clean Architecture with .NET

Michael Brennan — Fri, 01 Nov 2024 15:51:33 +0000

In the world of .NET development, maintaining clean, readable, and maintainable code is crucial—especially when working with a clean architecture approach. One powerful technique to achieve this is by leveraging extension methods for initializing the Dependency Injection (DI) container.

Here's why using extension methods to set up your DI container is so effective:

1. Keeps `Program.cs` Clean and Simple

When setting up DI in your .NET applications, the Program.cs file can quickly become cluttered with various service registrations. By moving these registrations into extension methods, you can significantly reduce the noise in Program.cs, making it easier to read and manage. This approach aligns with the principles of clean architecture by ensuring that each part of your application has a single responsibility.

2. Encapsulates DI Setup Code

Extension methods allow you to encapsulate your DI setup code, keeping it close to the actual code it relates to. For example, if you have a service layer, you can create an extension method that registers all the services within that layer. This keeps your DI configurations organized and ensures that the registration logic is easy to locate and update.

3. Enhances Reusability and Modularity

With extension methods, you can create reusable DI configurations that can be shared across multiple projects or applications. This modular approach is particularly beneficial in microservice architectures, where services often share common configurations like logging, caching, or database setups.

Example in Action:

Here’s how you might organize your Program.cs file using extension methods:

var builder = WebApplication.CreateBuilder(args);

// Clean and modular DI setup
builder.Services
    .AddDatabaseServices(builder.Configuration)
    .AddApplicationServices()
    .AddRepositoryServices()
    .AddThirdPartyServices();

var app = builder.Build();
// Remaining middleware configuration...

And here’s how the extension methods might look:

public static class ServiceCollectionExtensions
{
    public static IServiceCollection AddDatabaseServices(this IServiceCollection services, IConfiguration configuration)
    {
        services.AddDbContext<AppDbContext>(options =>
            options.UseSqlServer(configuration.GetConnectionString("DefaultConnection")));

        return services;
    }

    public static IServiceCollection AddApplicationServices(this IServiceCollection services)
    {
        services.AddTransient<IUserService, UserService>();
        services.AddTransient<IOrderService, OrderService>();

        return services;
    }

    public static IServiceCollection AddRepositoryServices(this IServiceCollection services)
    {
        services.AddScoped<IUserRepository, UserRepository>();
        services.AddScoped<IOrderRepository, OrderRepository>();

        return services;
    }

    public static IServiceCollection AddThirdPartyServices(this IServiceCollection services)
    {
        services.AddHttpClient("GitHub", client =>
        {
            client.BaseAddress = new Uri(configuration["GitHubApi:BaseAddress"]);
            client.DefaultRequestHeaders.UserAgent.ParseAdd(configuration["GitHubApi:UserAgent"]);
        });

        return services;
    }
}

Conclusion

Using extension methods for DI setup not only keeps your Program.cs clean and focused but also promotes better code organization, modularity, and reusability. By encapsulating your DI logic into extension methods, you ensure that your application’s architecture remains scalable and maintainable.

dotnet #cleanarchitecture #dependencyinjection #softwareengineering #csharp #codingtips #programming

DEV Community: Michael Brennan

How Two Markdown Files Completely Changed My Visual Studio + Copilot Workflow

The Problem: Copilot Without Guardrails

The Fix: Persistent Workspace Context

How to Configure Visual Studio

Real Improvements

The Bigger Insight

If You Want to Try This

Implementing Distributed Caching with Redis in Azure Functions

Project Structure

Solution Folder Structure

1. Azure Function App

FunctionApp/Startup.cs

FunctionApp/Functions/ProductFunction.cs

2. Application Layer

Application/Interfaces/IProductService.cs

Application/Services/ProductService.cs

3. Cache Invalidation on Update

Infrastructure/Repositories/CachedProductRepository.cs

Dependency Injection for Infrastructure

Infrastructure/Extensions/InfrastructureServicesExtensions.cs

Conclusion

Harnessing Extension Methods for DI in Clean Architecture with .NET

Here's why using extension methods to set up your DI container is so effective:

1. Keeps Program.cs Clean and Simple

2. Encapsulates DI Setup Code

3. Enhances Reusability and Modularity

Example in Action:

Conclusion

dotnet #cleanarchitecture #dependencyinjection #softwareengineering #csharp #codingtips #programming

1. Keeps `Program.cs` Clean and Simple