Anyone that knows me knows that I love what I call "code that writes code". T4, Velocity, even CodeDom - these are all things I just get giddy to use.

Occasionally, you can use RegEx to the same effect. Take, for instance, a recent feature request I was implementing to allow users to select margins in pixels or percents. Going to the browser and editing the HTML directly therein, I was able to make the changes necessary in a way that would look good to the user.

The above image shows both the original (Margin Right) and the changes I wished to make (Margin Left).

If that was all I needed to do - change those two inputs to each have an additional dropdown, I'd have been done quickly. But it wasn't. The page has default values and then values for 10 more rules. So 22 controls in total.

I could have gone in and changed each of the 22 manually, but that would have been tedious, mind-numbing work, so .....

RegEx to the rescue...

The original code is PHP Volt, and one control looks like this:

<input type="hidden" name="ecm[floatDefaultMarginLeft][configurationID]"
       value="{{ configurations['floatDefaultMarginLeft']['configurationID'] }}"/>
<input type="number" id="floatDefaultMarginLeft" class="form-control"
       name="ecm[floatDefaultMarginLeft][ciValue]"
       value="{{ configurations['floatDefaultMarginLeft']['ciValue'] }}"/>

I needed to change it to look like this:

<input type="hidden" name="ecm[floatDefaultMarginLeft][configurationID]"
       value="{{ configurations['floatDefaultMarginLeft']['configurationID'] }}"/>
<input type="hidden" name="ecm[floatDefaultMarginLeftType][configurationID]"
       value="{{ configurations['floatDefaultMarginLeftType']['configurationID'] }}"/>
<div class="row">
    <div class="col-xs-10 col-md-8 col-lg-9" style="padding-right:0">
        <input type="number" id="floatDefaultMarginLeft" class="form-control"
               name="ecm[floatDefaultMarginLeft][ciValue]"
               value="{{ configurations['floatDefaultMarginLeft']['ciValue'] }}"/>
    </div>
    <div class="col-xs-2 col-md-4 col-lg-3" style="padding-left: 0">
        <select class="form-control" name="ecm[floatDefaultMarginLeftType][ciValue]">
            <option value="%" {% if configurations['floatDefaultMarginLeftType']['ciValue'] == '%' or configurations['floatDefaultMarginLeftType']['ciValue'] is empty %} selected {% endif %}>%</option>
            <option value="px" {% if configurations['floatDefaultMarginLeftType']['ciValue'] == 'px' %} selected {% endif %}>px</option>
        </select>
    </div>
</div>

Of course, all those "MarginLeft"s are "MarginRight" for the right side. And the rules based settings are all "float1MarginLeft" or "float2MarginLeft", etc.

But RegEx has capturing groups, and even named capturing groups. So I ended up with this multiline RegEx:

(?<linespace>\s*)<input type="number" id="float(?<num>\w+)Margin(?<direction>\w+)" class="form-control"
(?<linespace2>\s*)name="ecm\[float(\w+)Margin(\w+)\]\[ciValue\]"
(?<linespace3>\s*)value="{{ configurations\['float(\w+)Margin(\w+)'\]\['ciValue\'\] }}"\/>

And this replacement 'text':

${linespace}<input type="hidden" name="ecm[float${num}Margin${direction}Type][configurationID]"
${linespace2}value="{{ configurations['float${num}Margin${direction}Type']['configurationID'] }}"/>
${linespace}<div class="row">
${linespace}    <div class="col-xs-10 col-md-8 col-lg-9" style="padding-right:0">
${linespace}        <input type="number" id="float${num}Margin${direction}" class="form-control"
${linespace2}        name="ecm[float${num}Margin${direction}][ciValue]"
${linespace3}        value="{{ configurations['float${num}Margin${direction}']['ciValue'] }}"/>
${linespace}    </div>
${linespace}    <div class="col-xs-2 col-md-4 col-lg-3" style="padding-left: 0">
${linespace}        <select class="form-control" name="ecm[float${num}Margin${direction}Type][ciValue]">
${linespace}            <option value="%" {% if configurations['float${num}Margin${direction}Type']['ciValue'] == '%' or configurations['float${num}Margin${direction}Type']['ciValue'] is empty %} selected {% endif %}>%</option>
${linespace}            <option value="px" {% if configurations['float${num}Margin${direction}Type']['ciValue'] == 'px' %} selected {% endif %}>px</option>
${linespace}        </select>
${linespace}    </div>
${linespace}</div>

And voila, 22 changes complete!

So ... use the tools you have at your disposal. Work smart, not hard. And get a good RegEx tool. On Windows 10/11, I recommend Regex Hero, with SkyD Regex a close second.

First, it is important to note the following things about ASP.NET:

1. It is heavily dependent upon Dependency Injection

2. Middleware is daunting, but it is powerful

3. Folder structures are well-defined and mandatory (mostly)

Dependency Injection

First, let's talk about DI. Are you writing a controller and need resources outside your controller, like the application's configuration, a database context instance, and a logging instance? No problem, just put them in your constructor and DI will supply them when your controller is instantiated.

private readonly MyContext _db;
private readonly string _someSetting;
private readonly ILogger<MyController> _logger;

public MyController(MyContext db, IConfiguration config, ILogger<MyController> logger)
{
    _db = db;
    _logger = logger;
    _someSetting = config["App:SomeSetting"];
}

Building a class to provide common functionality Application wide? Then you should consider building a service so that it can be injected via DI.

public interface IClock
{
    DateTime GetTime();
    DateTime GetTimeUtc();
}

public class OffsetClock: IClock
{
    private readonly ILogger<OffsetClock> _logger;
    private readonly TimeSpan _offset;

    public class OffsetClock(ILogger<OffsetClock> logger, IConfiguration config)
    {
        _logger = logger;
        _offset = TimeSpan.Parse(config["Clock:Offset"]);
        _logger.LogDebug("Offset clock instantiated with offset: {Offset}", _offset);
    }

    public DateTime GetTime()
    {
        _logger.LogDebug("Getting time");
        return DateTime.Now.Add(_offset);
    }

    public DateTime GetTimeUtc()
    {
        _logger.LogDebug("Getting time in UTC");
        return DateTime.UtcNow.Add(_offset);
    }
}

Notice that the above example contained both an implementation class (OffsetClock) and interface (IClock). The implementation class uses other classes which themselves are supplied to the constructor via DI.

Now that you have a service, you need to tell DI about your service. But before you do, you should consider the lifetime of your shiny new service. Is each method call independent of each other? Then perhaps you want your new service to be a Singleton service. Should a single instance of your service be used by everything which needs it when all working for the same HTTP request, or other unit of work? Then you might consider a Scoped service. And finally if a new instance should be created every single time it is needed, then you need a Transient service.

Setting up your service is done when building the ASP.NET WebApplication, typically in Program.cs. WebApplicationBuilder.Services is the service collection where you can add services. There are a lot of different ways to do so, but let's look at just three for now:

• AddTransient<T,U>() - Adds a transient service

• AddScoped<T,U>() - Adds a scoped service

• AddSingleton<T,U>() - Adds a singleton service

Looking back at our OffsetClock, it could easily be a singleton service since it doesn't maintain any pertinent information between calls.

builder.AddSingleton<IClock, OffsetClock>();

Now, the first time a component needs an IClock instance, an OffsetClock instance will be created. Every time after that when a component needs an IClock instance, this same instance of OffsetClock will be provided.

Middeware

The ASP.NET Middleware pipeline is amazing. It truly is. But it is dangerous, too. I wish I had understood it like I understand it now when I first started writing ASP.NET Core applications back in the ASP.NET Core 2.1 days. You wouldn't believe the spaghetti I wrote because I just couldn't make the middleware do what I wanted it to do.

Everything under the sun will show you the diagram of Middleware #1 passing the request to Middleware #2 which passes the request to Middleware #3, which completes the request. Then Middleware #3 passes the response to Middleware #2 which passes the response to Middleware #1 before returning the response back to the client.

But here's the important thing, and it is simple, but IMPORTANT. Honestly, I don't know why everywhere you see that middleware diagram you don't also see this statement. The ORDER of adding middleware to the pipeline when building the WebApplication defines the ORDER of the execution of the middleware.

So if you have an application which already had Authentication via app.UseAuthentication() and now want to add roles for users and thus add Authorization functionality via app.UseAuthorization(), then it is very important that you place the call to app.UserAuthorization() AFTER the call to app.UseAuthentication(). After all, if you try to authorize something before you know who the user is via authentications, well that won't work, will it?

Anyway, middleware is important. It is powerful. Want to add logging of raw POST data and raw responses? Middleware could do that for you. Want to make use of more functionality provided by ASP.NET, such as adding MVC controllers to Razor Pages? It can do that too. But be mindful of the ordering - it is critically important.

Folder Structures

Many folders are mandated by ASP.NET out of the box, such as:

• /wwwroot contains static files which are served directly

• /Controllers contains controllers

• /Views contains MVC views

• /Pages contains Razor Pages (which I highly recommend using whenever able)

• /Areas contains trees of Razor Pages and MVC Views located under a subfolder which equates to an HTTP path folder

I strongly suggest adopting these other root folders as well:

• /Model contains model classes, possibly in a tree when there are multiple model sets (e.g. One for a database, one for API DTOs, etc.)

• /Middleware contains middleware classes, or classes used by generic middleware

• /Services contains DI services