John Smith

Overview ☀

I was doing some housekeeping on seedfolder, a small .NET global tool I maintain that creates a project folder and fills it with sensible dotfiles. It targets net8.0, net9.0 and net10.0.

.NET 8 and .NET 9 both reach end of support on 10 November 2026, so the plan was simple. Wait for November, drop both, ship a .NET 10 only version.

Then I asked myself a question I could not answer with any confidence, and the answer turned out to be the opposite of what I assumed.

The Question 🔍

Here is the scenario. A user installs the tool today while it targets .NET 10. Some months later .NET 11 lands. Homebrew upgrades them, or Windows Update does, and the .NET 10 runtime is no longer on their machine.

Does the tool still run?

My instinct said “add a global.json with roll-forward and it will be fine”. That instinct was wrong twice over. Wrong about global.json, and wrong about which half of the problem it applies to.

Why global.json Is The Wrong Tool ⚙️

global.json selects the SDK used when building a repository. It has nothing to do with people who installed your tool from NuGet.

Worse, adding one cannot help even for the build. From the matching rules:

If no global.json file is found, or global.json doesn’t specify an SDK version and doesn’t specify an allowPrerelease value, the highest installed SDK version is used (equivalent to setting rollForward to latestMajor).

Having no global.json is already the most permissive setting available. Adding one can only narrow SDK selection, never widen it.

And there is a trap. If you add a global.json with a version and forget rollForward, the default policy is patch. That file will break your build the moment the pinned SDK disappears, which is exactly the failure people add a global.json hoping to prevent.

So global.json earns its place when you want a reproducible floor for CI. It is not a roll-forward mechanism.

The Half That Actually Matters 🎯

.NET tools are framework-dependent applications. When you run one, the host looks for the runtime the tool was built against. From the troubleshooting docs:

Roll-forward won’t occur by default in two common scenarios: … Only higher major versions of the runtime are available. Roll-forward doesn’t cross major version boundaries.

That is the whole problem in one sentence. Patch and minor roll-forward happen automatically. Major does not.

Reproducing It Today 🧪

I did not want to take the docs on faith, and I did not want to wait until .NET 11 ships to find out. So I built a proxy.

A tool targeting net8.0, running on a machine that has only the .NET 10 runtime, is structurally identical to a net10.0 tool on a future .NET 11 box. Missing major, higher major available. Both exist today, so it is testable now.

Docker made this easy. The official SDK 10 image carries only the .NET 10 runtime:

docker run --rm mcr.microsoft.com/dotnet/sdk:10.0 dotnet --list-runtimes

Microsoft.AspNetCore.App 10.0.10 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 10.0.10 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

No .NET 8 anywhere. Exactly the machine I needed.

The Test Script 📜

I copied the repo with git archive so the working tree was never touched, then ran three cases in the container. Single-target net8.0, pack, install as a global tool from a local folder, run it.

#!/bin/bash
set -u
cd /work
export PATH="$PATH:/root/.dotnet/tools"
CSPROJ=src/solrevdev.seedfolder.csproj

dotnet --list-runtimes

# Target the missing major. Use a version that cannot exist on nuget.org so the
# package can only resolve from the local folder.
sed -i 's|net8.0;net9.0;net10.0|net8.0|' "$CSPROJ"
sed -i 's|1.6.0|99.0.0|' "$CSPROJ"

run_case() {
    echo "---------- $1 ----------"
    rm -rf src/nupkg src/bin src/obj
    dotnet pack "$CSPROJ" -c Release -o /work/nupkg >/dev/null 2>&1

    grep -i "rollForward" src/bin/Release/net8.0/*.runtimeconfig.json \
        || echo "  (no rollForward key present)"

    dotnet tool uninstall -g solrevdev.seedfolder >/dev/null 2>&1
    dotnet tool install -g solrevdev.seedfolder --version 99.0.0 \
        --add-source /work/nupkg ${EXTRA_INSTALL_FLAGS:-} >/dev/null 2>&1

    if out=$(seedfolder --version 2>&1); then
        echo "  SUCCESS -> $out"
    else
        echo "  FAILED"
        echo "$out" | sed 's/^/    | /'
    fi
}

EXTRA_INSTALL_FLAGS=""
run_case "A: no RollForward"

EXTRA_INSTALL_FLAGS="--allow-roll-forward"
run_case "C: same tool, user opts in at install time"

EXTRA_INSTALL_FLAGS=""
sed -i 's|latest|latest\n    Major|' "$CSPROJ"
run_case "B: RollForward=Major baked in"

Run it against a checkout:

docker run --rm -v "$PWD:/work" -w /work mcr.microsoft.com/dotnet/sdk:10.0 bash /work/run-test.sh

The Results 📊

Case A is the one that matters. This is what a user sees:

You must install or update .NET to run this application.

App: /root/.dotnet/tools/seedfolder
Architecture: arm64
Framework: 'Microsoft.NETCore.App', version '8.0.0' (arm64)
.NET location: /usr/share/dotnet

The following frameworks were found:
  10.0.10 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Learn more:
https://aka.ms/dotnet/app-launch-failed

A perfectly good runtime is sitting right there, listed in the error message, and the host refuses to use it. Not because it would not work, but because nobody told it that it was allowed to.

The Fix Is One Property 🔧

  Major

That writes the policy into the tool’s runtimeconfig.json at pack time:

{
  "runtimeOptions": {
    "tfm": "net8.0",
    "rollForward": "Major",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "8.0.0"
    }
  }
}

With that in place the same tool started immediately on the .NET 10 only box.

I did not stop at --version, because printing a version string proves very little. I ran the tool properly and had it seed a real project:

seedfolder --quiet -t node my-app

Files created:
  .editorconfig
  .gitattributes
  .gitignore
  .prettierignore
  .prettierrc
  index.js
  package.json

Every file written, on a runtime two major versions newer than the one the tool was built for. Worth noting that it crossed two majors, 8 to 10, without complaint.

The Escape Hatch Users Have 🪜

Case C is the interesting one for anyone stuck with a tool whose author has not done this. Since the .NET 9 SDK there is an install-time flag:

dotnet tool install -g some.tool --allow-roll-forward

It sets roll-forward mode to Major for that tool without the author changing anything. It works, and I confirmed it works. But it depends on the user knowing the flag exists, at the exact moment their tool has stopped working and they are already annoyed. That is not a plan, it is a rescue.

What I Am Changing 🛠

Two things, and only one of them is urgent.

The RollForward property goes in now. It is one line, it is backwards compatible, and it helps immediately. Even while the tool multi-targets .NET 8, 9 and 10, a user on .NET 11 with none of those runtimes installed hits Case A today.

The framework drop waits for November. When .NET 8 and 9 go out of support the tool becomes .NET 10 only, and at that point RollForward stops being a nice safety net and becomes the thing keeping the tool alive between LTS releases.

There is a real tension here that took me a moment to see. Dropping old target frameworks is normally framed as a maintenance win. For a global tool it is also a compatibility cliff, in both directions. Drop .NET 8 too early and you lock out users who have not upgraded. Ship .NET 10 only without roll-forward and you lock out the users who have.

What I Took Away 💡

Three things worth keeping.

Check which layer a setting applies to. I nearly reached for global.json for a runtime problem. It is a build-time SDK selector. The names being similar, rollForward in both places, made the confusion easy.

The permissive default is often the absence of the file. No global.json already behaves like latestMajor. Adding configuration to get a behaviour you already have is a good way to lose it.

Build the proxy rather than waiting for the real thing. I could not test .NET 11 because it does not exist yet. Testing .NET 8 against .NET 10 answered exactly the same question, today, in about twenty minutes and one container.

What Is Next 🔮

The property goes in with the next release. In November the target frameworks collapse to net10.0 and the tool gets a version bump to match.

If you maintain a .NET global tool, this is worth thirty seconds of your time. Open your csproj and look for RollForward. If it is not there, your tool will stop working for somebody the day their machine moves on without you.

Success! 🎉

Overview ☀

I wanted to know what time of day people read this blog. It seemed like a question analytics should answer in about thirty seconds.

It took considerably longer, because the answer I got back covered 28 days and refused to go any further. Meanwhile a report two clicks away was cheerfully showing me numbers from June 2023.

The cause turned out to be a single dropdown I had never looked at in three years of owning the property. GA4 sets event data retention to 2 months by default, which is the shortest option Google offers. It is free to change, it takes about thirty seconds, and it is not retroactive, which is the part that actually matters.

This post is what the symptom looks like, why the two halves of GA4 disagree with each other, where the setting hides, and what it cost me to find out late.

The Symptom 🔍

Here is the contradiction that sent me looking.

Open Reports then Engagement then Landing page, set the date range to something absurd like 1 January 2020 to today, and GA4 hands over the lot. My oldest data is 8 June 2023 and it is all there, every month of it.

Now open Explore, build a free-form table, and ask the same property for anything more than a couple of months old. Empty. No error, no warning, no banner explaining why. The table just stops.

Same property, same account, same date picker. Two completely different answers about what data exists.

Why The Two Reports Disagree ⚙️

The two halves of GA4 read from different places.

Standard reports are aggregated. Views, sessions, users per page per day are rolled up and stored as summaries. Those summaries are not governed by the retention setting at all, which is why my 2023 numbers survive.

Explorations read raw event data. Every page_view, every parameter, every user identifier. That is the expensive stuff to store, and that is what the retention setting governs.

So the setting does not break your reports. It quietly removes your ability to ask new questions of old data. Google’s own wording on the settings page says as much, in a sentence that is easy to skim past:

These controls don’t affect most standard reporting, which is based on aggregated data.

Read that as a reassurance and you move on. Read it as a warning and you go looking for what it does affect.

Where The Setting Lives 🧭

Admin (the cog, bottom of the left rail), then Property settings, then Data collection and modification, then Data retention.

Or skip the clicking, because the URL is addressable:

https://analytics.google.com/analytics/web/?authuser=1#/ap/admin/datapolicies/dataretention

Swap in your account and property IDs. Both are in the property selector, and the property ID is also on Admin then Property details. Mind the authuser= value if you have more than one Google account signed in; a fresh tab defaults to authuser=0 and you may not be in the slot you think you are.

This is what mine looked like:

Note that User data was already on 14 months. Only Event data ships on the short setting, which makes the panel look half-reasonable at a glance and is probably why I had scrolled past it before.

The Fix 🔧

Open the Event data dropdown. On the free tier there are exactly two options: 2 months and 14 months. Pick 14, then Save.

Three things worth knowing while you are in there:

1. Confirm with a page reload, not the button. The panel will happily display a value you have not saved. The Save button greys out when it takes, but reloading the page is what actually proves it.
2. You need Editor or Administrator on the property. A greyed-out dropdown means you are a Viewer or Analyst.
3. It is per property. There is no account-level switch, so a multi-property account means repeating this by hand for every one.

14 months is the ceiling on the free tier. The longer options, 26, 38 and 50 months, are Google Analytics 360 only.

Leave User data alone, and leave Reset on new user activity switched on.

The Part That Stings 🩹

The change is not retroactive.

You are buying future detail. Everything already aged out is gone, permanently, and no support ticket or API call brings it back. Google also notes that changes take up to 24 hours to take effect.

So the real cost of this default is not “I have to change a setting”. It is however many months passed between creating the property and finding out. For me that was three years of event-level data I can never analyse, on a blog whose whole value is that its old posts keep working.

That asymmetry is why this is worth doing on a property you are not even actively looking at yet. The setting costs nothing to change today and cannot be changed backwards tomorrow.

What It Actually Cost Me 📉

Back to the original question: what time of day do people read this?

Here is what I could get, and 28 days is all of it:

Two patterns sit on top of each other in that table, and the mobile column is what separates them.

The human one. A solid block through the UK working day, roughly 11:00 to 17:00, with an evening tail. Mobile peaks at 22:00, then 15:00 and 21:00. That is a developer reading something on the sofa.

The other one. 23:00 is the single busiest hour of the day at 39 users. 05:00 is third at 33. Both are near enough zero mobile. Nobody reads a .NET blog at five in the morning in those numbers, and bots do not browse on phones.

That second pattern turned out to be a much bigger story than I expected once I looked at geography, but it is a different post.

The useful conclusion was small and practical: publish in the UK morning so a post is live for the 11:00 to 17:00 block. Fine. But I reached it from 28 days of a mixed population, when I should have been able to reach it from a year of data and strip the noise out first.

One more limitation worth flagging while you are in Explore, because it cost me another ten minutes of hunting: GA4 has no day-of-week dimension. Not in reports, not in Explorations. You get Hour, Nth hour, Date + hour, Week and Nth week, and nothing that gives you Monday to Sunday. If you want to know whether Tuesday beats Friday, the BigQuery export is the only route.

Why The Default Is Two Months 🤔

Google does not say, so this is inference rather than fact.

Raw event data is the expensive thing to keep. Two months is cheap, and the overwhelming majority of properties never open Explore, so the majority never notice. The people who do notice are doing the kind of analysis that shades towards the paid tier, where the longer windows live.

Whatever the reason, the practical read is the same: the default is set for Google’s storage costs, not for your analysis. It is worth assuming the same of every other default in the product, which is roughly the frame of mind I went back in with.

Check Yours 📋

If you have a GA4 property, this takes less time than reading this far.

1. Admin, Data collection and modification, Data retention.
2. If Event data says 2 months, change it to 14 months and Save.
3. Reload to confirm.
4. Repeat for every property you own.

Then do it again for any property you create from here on, because new ones still arrive on the default.

What I Took Away 💡

1. Two reports disagreeing about what data exists is a signal, not a bug. It meant two different storage layers with two different rules, and it was worth chasing rather than shrugging at.
2. “Does not affect standard reporting” is doing a lot of work in that sentence. Reassurance and warning are the same words depending on which half of the product you use.
3. Settings that cannot be reversed deserve a look before you need them. Not after.

What Is Next 🔮

• Revisit the hour-of-day question in a year, once 14 months of event data has actually accumulated.
• Work out how much of my traffic is automated, because the 23:00 and 05:00 spikes were the loose thread on something considerably larger.
• Look at the BigQuery export, which is free at this volume, keeps raw events indefinitely, and would have made this entire post unnecessary.

If you have had a GA4 property sitting quietly for a few years, go and look at that dropdown. It is thirty seconds, and the clock has been running the whole time.

Success! 🎉

Overview ☀

OpenRouter emailed me to say my credits were about to expire. I had bought $10 in March 2024, spent seven pence of it, and forgotten the account existed. Credits older than twelve months expire if the account sees no activity, and running any inference resets the clock.

Easy enough. Send a request, keep the money. Except I could not prove it worked. The dashboard rounds every figure to two decimal places, and a request big enough to keep an account alive costs about $0.0002. Every screen I looked at said $0.00, both before and after.

So I wrote a client. It ended up being more interesting than the problem that prompted it, because two things landed at once: .NET 10 lets you run a .cs file with no project around it, and OpenRouter puts every model worth trying behind one API and one key. Put those together and a usable chat client with model browsing and cost reporting is about 300 lines in a single file you can email to someone.

It is called orchat and the whole thing is on GitHub at solrevdev/solrevdev.orchat.

This post is about that file. I have written about .NET global tools and .NET 10 before. This is the other end of the scale: the smallest thing that is still a real application.

A Single File, No Project 📄

.NET 10 runs a loose .cs file:

dotnet run orchat.cs

No .csproj. No obj folder in sight. No dotnet new. The SDK compiles the file to a cache directory and runs it. Check you are on 10 or later first, because this does not exist before then:

dotnet --version

Top-level statements do the heavy lifting. The file opens with using directives and then just starts doing things:

const string Base = "https://openrouter.ai/api/v1";

var key = Environment.GetEnvironmentVariable("OPENROUTER_API_KEY");
if (string.IsNullOrWhiteSpace(key))
{
    Console.Error.WriteLine("Set OPENROUTER_API_KEY first.");
    return 1;
}

Local functions can follow the statements, and type declarations go at the end. So the whole program reads top to bottom: setup, the main loop, then the functions it calls, then a record at the bottom.

Three things surprised me about how far this scales.

You can add NuGet packages. A directive at the top of the file pulls a package, no project required:

#:package Humanizer@2.14.1
using Humanizer;
Console.WriteLine(TimeSpan.FromMinutes(90).Humanize());   // "1 hour"

I did not use it. Everything orchat needs is in the shared framework, and I wanted the file to stay copy-and-paste portable. But the ceiling is a lot higher than “toy script”.

It can be its own command. Put a shebang on line one, mark it executable, and the source file becomes the program:

#!/usr/bin/env dotnet

chmod +x orchat.cs
./orchat.cs

The compiler ignores that line, so dotnet run, dotnet build and dotnet publish all carry on working.

There is a way out. If it outgrows one file, you are not stuck rewriting the scaffolding by hand:

dotnet project convert orchat.cs --dry-run
dotnet project convert orchat.cs

That last one matters more than it sounds. The usual objection to scripts is that they become load-bearing and then you are trapped. Here the exit is one command and it keeps your code.

What orchat Does 🎯

It is a chat client that keeps the whole thread in memory, and a model browser.

This early run used anthropic/claude-sonnet-4.5, so the cost below reflects that model’s pricing at the time:

> what is the difference between a record and a class in C#?
Records are reference types with value-based equality...
[26 in / 180 out, $0.002784, 2.1s, session $0.0028]

> now show me when that equality actually bites

The second question sees the first exchange. Every turn sends the system prompt plus the entire conversation, so follow-ups work the way you would want. Nothing is trimmed or summarised, which keeps the context honest at the cost of a bill that grows with the thread. The in count on the stats line is that growth, in public.

The commands are deliberately few:

/model               switch model
/models [filter|free]    browse the catalogue
/models use 12           switch to row 12
/key                     usage for this key
/cost                    what this session has spent
/system            replace the system prompt
/reset                   clear the thread, keep the model
/save [file]             write the thread to markdown
/exit

If /save cannot write the file, it reports the error and keeps the session open. A bad path should not end the process and lose the thread you were trying to save.

try
{
    File.WriteAllText(path, sb.ToString());
    Console.WriteLine($"Saved {path}");
}
catch (Exception ex)
{
    Console.Error.WriteLine($"Could not save thread: {ex.Message}");
}

Talking to OpenRouter 🔌

OpenRouter’s API is the OpenAI chat completions shape, so there is nothing exotic to learn. One base URL, one bearer token, and the model as a string in the body:

var model = Environment.GetEnvironmentVariable("OPENROUTER_MODEL")
            ?? "openai/gpt-5.6-luna";

var http = new HttpClient { Timeout = TimeSpan.FromMinutes(10) };
http.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", key);
http.DefaultRequestHeaders.Add("HTTP-Referer", "https://solrevdev.com");
http.DefaultRequestHeaders.Add("X-Title", "orchat");

Those last two headers are OpenRouter specific and optional. They attribute the traffic to your app on their rankings page. Worth setting.

The value here is that openai/gpt-5.6-luna, openai/gpt-oss-20b:free and hundreds of others are the same call with a different string. No SDK per vendor, no separate key per vendor, no separate billing relationship per vendor. For trying things out, that is the whole pitch.

Streaming, and Getting the Bill 💸

Two flags in the request body do the interesting work:

var body = new JsonObject
{
    ["model"] = model,
    ["messages"] = messages,
    ["stream"] = true,
    ["usage"] = new JsonObject { ["include"] = true }
};

stream gives you server-sent events. usage.include makes OpenRouter append a usage block to the final event, with the actual cost of that request. Not an estimate from a price card. What you were charged.

Reading it back is a loop over lines. Anything that is not a data: line is noise, and [DONE] ends it:

using var res = await http.SendAsync(req, HttpCompletionOption.ResponseHeadersRead);
using var stream = await res.Content.ReadAsStreamAsync();
using var reader = new StreamReader(stream);

while (await reader.ReadLineAsync() is { } chunk)
{
    if (!chunk.StartsWith("data: ")) continue;
    var data = chunk[6..];
    if (data == "[DONE]") break;

    JsonNode? node;
    try { node = JsonNode.Parse(data); }
    catch { continue; }
    if (node is null) continue;

    // Errors after streaming starts arrive as a final SSE event. The HTTP
    // status stays 200 because OpenRouter has already sent the headers.
    if (node["error"] is JsonNode error)
    {
        var code = error["code"]?.ToString();
        var message = error["message"]?.GetValue<string>() ?? "The stream failed.";
        throw new Exception(string.IsNullOrEmpty(code) ? message : $"{code}: {message}");
    }

    var delta = node["choices"]?[0]?["delta"]?["content"]?.GetValue<string>();
    if (!string.IsNullOrEmpty(delta))
    {
        Console.Write(delta);
        sb.Append(delta);
    }

    var usage = node["usage"];
    if (usage is not null)
        cost = usage["cost"]?.GetValue<double>() ?? 0;
}

HttpCompletionOption.ResponseHeadersRead is the line that makes it stream rather than buffer. Without it you wait for the whole response and then print it all at once, which defeats the point.

The first check skips OpenRouter’s comment lines and keep-alives. The parse guard skips a malformed data event. The explicit error check matters because a provider can fail after streaming starts. At that point the HTTP status is already 200, so OpenRouter reports the failure inside the final SSE event instead.

That cost figure is what makes the tool worth keeping. After every turn:

[26 in / 180 out, $0.002784, 2.1s, session $0.0028]

Six decimal places, because two is useless at these amounts. When you are comparing a frontier model against something a tenth of the price, seeing the real number after each answer changes which one you reach for.

Browsing the Catalogue 🔍

GET /api/v1/models is public and needs no key. It returns everything OpenRouter can route to, with pricing, context length and a description. The count changes as models arrive and leave, so orchat reads the live catalogue rather than keeping a fixed list.

/models sorts by output price, cheapest first, and numbers the rows so you can act on them:

  1. cohere/north-mini-code:free                    256k  free
  2. google/gemma-4-26b-a4b-it:free                 262k  free
 ...
 14. openai/gpt-oss-20b:free                        131k  free

Then /models use 14 switches to it. /models claude filters by substring, /models free shows only the zero-priced ones, and /models 14 prints the full detail for one row. The catalogue is fetched once and cached for the session, so browsing costs nothing after the first call.

One trap worth knowing if you write something similar. Pricing comes back as strings, mostly:

"pricing": { "prompt": "0.000003", "completion": "0.000015" }

Mostly. Some entries omit pricing, and some quote it as a number. GetValue() throws on a number rather than converting, so a naive parser takes the whole listing down over one odd row. Check the kind first:

static double Price(JsonNode? n) => n?.GetValueKind() switch
{
    JsonValueKind.String => double.TryParse(
        n.GetValue<string>(),
        NumberStyles.Float,
        CultureInfo.InvariantCulture,
        out var v) ? v : 0,
    JsonValueKind.Number => n.GetValue<double>(),
    _ => 0
};

OpenRouter uses a dot as the decimal separator, so string prices must use the invariant culture. Without it, 0.000003 becomes 3 under de-DE and fails to 0 under fr-FR. The source imports System.Globalization for NumberStyles and CultureInfo. The same kind check applies to context_length, which is missing on a few entries. This is the sort of thing that never shows up against a mock and always shows up against the real catalogue.

Free Models, and Why They Did Not Help 🆓

OpenRouter carries a genuine free tier. Models with a :free suffix cost nothing. They are rate limited, but real. For a chat client that is a gift.

For my actual problem it was useless. A free call spends nothing, so there is no charge, so it may not count as the billable activity that resets credit expiry. If you are keeping an account alive, use a paid model. A request costing a fraction of a penny is the entire point.

The free list also churns hard. Endpoints get delisted and added constantly, so never hard-code a :free id into anything scheduled. Ask the catalogue what is free today.

Where the Usage Actually Lives 🔎

This is the part that cost me the most time, and it is the reason the post exists.

The obvious endpoint is GET /api/v1/key. It returns your usage, and orchat prints it:

Key 'unnamed': $0.023808 used all time, $9.976192 left on this key.
  today $0.023808   this week $0.023808   this month $0.023808
  free tier: false

usage_daily, usage_weekly and usage_monthly are all in that one response, at full precision, which is exactly what the dashboard hides.

The catch: it reports usage for that one key, not for the account. I had generated a fresh key for the tool. It read zero all-time while my account had spent $0.069 since 2024. Nothing I had done in the web chat room appeared, because that was a different key. Those zeros meant nothing at all about whether the account was alive, and I spent a while believing they did.

The account-level answer is a different endpoint:

curl -s -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  https://openrouter.ai/api/v1/credits

{ "data": { "total_credits": 10, "total_usage": 0.069429591 } }

Nine decimal places. That is the number the dashboard rounds to $9.93 and refuses to elaborate on.

The method that finally settled it was a before-and-after delta. Snapshot total_usage, send one small paid request, wait a minute or two for OpenRouter to aggregate, snapshot again:

before   total_usage  0.069429591
after    total_usage  0.092981691

The rise matched the cost the API had reported for the requests, to the sixth decimal. Timer reset, proven, for about two pence.

The aggregation lag is worth flagging. A reading taken immediately after a request still shows zero. It took between one and two minutes to appear. I nearly concluded the whole thing had failed on the strength of a reading taken five seconds too early.

Keeping the Key Out of the Repo 🔐

The app reads OPENROUTER_API_KEY from the environment and nowhere else. No config file, no .env, nothing to accidentally commit.

That leaves the question of where the key lives. On macOS the answer is already installed:

security add-generic-password -a "$USER" -s OPENROUTER_API_KEY -w

Leave the value off the end and it prompts, twice, echoing nothing. The key never touches your shell history or your scrollback. Read it back for exactly one command:

OPENROUTER_API_KEY=$(security find-generic-password -s OPENROUTER_API_KEY -w) dotnet run orchat.cs

Encrypted at rest, no dependency, works from cron and launchd. I now use this for every local tool secret.

I did consider dotnet user-secrets and rejected it. It needs a package and a UserSecretsId, it ties a secret to one project, and Microsoft’s own documentation says it does not encrypt anything and should not be treated as a trusted store. It is a .env file with more steps.

Because the store differs by platform, orchat ships two small launchers rather than making that command a thing you retype. orchat.sh tries the environment, then security, then secret-tool on Linux. orchat.ps1 tries the environment, then PowerShell SecretManagement, then the native stores. Both check the SDK version and say something useful when it is too old.

Publishing a Native Binary 📦

The last trick. A file-based app publishes:

dotnet publish orchat.cs -o ./dist
./dist/orchat

That compiles ahead of time to native code. On my arm64 Mac the result is a 5.4 MB self-contained executable with no runtime to install, and it starts in 117 ms against 685 ms for dotnet run orchat.cs. Same work, including a network call, so that gap is build-and-launch overhead the binary does not carry.

Native compilation is also the reason I care about two warnings that looked cosmetic. The first draft built the request like this:

var messages = new JsonArray { new JsonObject { ["role"] = "system", ["content"] = system } };

That binds to JsonArray.Add, which raises IL2026 and IL3050: not trim safe, not AOT safe. It runs fine under dotnet run. Published as a native binary it would have compiled cleanly and then failed at runtime the first time it sent a message, because the reflection path it needs is not there any more.

The fix is a cast, so it binds to the JsonNode overload instead:

var messages = new JsonArray { (JsonNode)new JsonObject { ["role"] = "system", ["content"] = system } };

If you take one thing from this section: trimming warnings in a file-based app are not noise. They are the difference between a binary that works and one that fails on its first real request.

Try It 🚀

# get it
git clone https://github.com/solrevdev/solrevdev.orchat.git
cd solrevdev.orchat

# store the key once
security add-generic-password -a "$USER" -s OPENROUTER_API_KEY -w

# run it
./orchat.sh

Then:

> /models free
> /models use 14
> explain server-sent events in two sentences
> /model openai/gpt-5.6-luna
> the answer above came from a much smaller model. what did it miss?
> /cost

The model is read fresh on every request, so /model switches mid-thread and the new model inherits the whole conversation. Handing one model another model’s answer and asking what is wrong with it is the most useful thing this tool does, and it took no code at all. It falls out of keeping the thread in a list.

What I Took Away 💡

1. File-based apps are past the toy stage. Packages, shebangs, native publish, and a one-command exit to a real project. The reasons not to start something as a single file are getting thin.
2. Ask the API what it charged you. usage.include returns the real cost per request. Printing it after every turn changed which models I reach for more than any benchmark has.
3. Check which scope an endpoint reports on. /key and /credits both return something called usage. One is per key, one is per account, and reading the wrong one had me convinced a working thing was broken.
4. Rounding hides the truth in both directions. A dashboard showing $0.00 was not telling me nothing happened. It was telling me it could not be bothered to show four more digits.
5. Parse the response you get, not the one in the docs. Prices as strings except when they are numbers, missing context lengths, keep-alive lines in the event stream. None of it is documented and none of it survives a mock.
6. Free models are not free activity. Zero cost means zero charge means no billable event. If something downstream depends on you spending money, spend money.
7. The keychain was there all along. Two commands, encrypted, no dependency. I had been putting keys in dotfiles for years for no reason.

What Is Next 🔮

• A /compare command that sends one prompt to several models and prints the answers with their costs side by side.
• Token counts per model in /cost, so the session summary shows where the money went.
• Nothing scheduled. OpenRouter emails before credits expire, so the email is the reminder and a cron job would be one more thing to maintain.

The whole thing is one file, no project, no packages, and it fits in a screenful of scrolling. If you have an OpenRouter key and .NET 10, you can have it running in about a minute.

The source is at solrevdev/solrevdev.orchat, MIT licensed. orchat.cs is the entire application, so you can read it in one sitting.

Success! 🎉

Overview ☀

GitHub has gh. Bitbucket has nothing. Atlassian never shipped a first-party command line tool for Bitbucket Cloud, so anything you want to automate ends up as a pile of curl calls with a hand-rolled Authorization header and a jq filter to make sense of the answer.

I built bbx to close that gap. It is a .NET global tool that wraps the Bitbucket Cloud API v2, prints JSON on stdout, keeps human messages on stderr, and exits non-zero when something fails. That last part sounds obvious. It was the single worst bug in the project, and I will come back to it.

This post covers the whole build: what the tool does, how it is put together, the four bugs that only appear when you point the thing at a live API, and the release pipeline that puts it on NuGet. I have written about .NET global tools and .NET 10 upgrades before, so I have skipped the ground those posts already cover and spent the space on what was new here.

The source is on GitHub at solrevdev/solrevdev.bbx, and the package is on NuGet as solrevdev.bbx.

What bbx Is 🎯

bbx is gh for Bitbucket Cloud. One command per thing you would otherwise open a browser tab for:

bbx repo list -w myworkspace --limit 10
bbx pr list -w myworkspace -r myrepo --state OPEN
bbx pr view 42 -w myworkspace -r myrepo
bbx pipeline list -w myworkspace -r myrepo --limit 5

Coverage runs to twelve command groups: repositories, pull requests, branches, tags, commits, source files, downloads, pipelines, snippets, workspaces, projects and users. Underneath that there are 150 feature handlers, one per verb.

Set a default workspace once and you can drop -w from everything after it:

bbx auth set-workspace myworkspace
bbx pr list -r myrepo --state OPEN

What It Is Useful For 🔧

Three things, in the order I actually use them.

Answering a question without leaving the terminal. “Did the last pipeline pass?” is a browser tab, two clicks and a wait. Or:

bbx pipeline list -r myrepo --limit 1 \
  | jq -r '.pipelines[0].state | "\(.name) \(.result // "")"'

Scripting against Bitbucket in CI. Every command answers with JSON and reports failure through its exit code, so set -e and if ! do what you expect:

if ! prs=$(bbx pr list -r myrepo --state OPEN); then
  echo "lookup failed" >&2
  exit 1
fi

Giving an LLM agent a way to read Bitbucket. This is the one that shaped the design. An agent calling a CLI needs a stable contract, not human prose it has to scrape. bbx promises three things and the whole tool is built to keep them:

1. JSON on stdout, everything else on stderr, so a pipe stays clean.
2. Exit 0 on success and 1 on any failure, so the agent knows without parsing.
3. Pretty-printed by default, single-line on request via --json-compact or BBX_JSON_COMPACT=1, because an agent paying per token wants the compact form.

There is a fourth flag for the same audience. BBX_NO_INTERACTIVE=1 guarantees the tool never stops to prompt, and fails with a clear message instead:

BBX_NO_INTERACTIVE=1 bbx repo list -w myworkspace

The repository ships a separate guide written for agents rather than people, which turned out to be a more useful artefact than I expected. Point an agent at that file and it stops guessing at argument shapes.

How It Was Built, Start to Finish 🏗️

The first commit landed on 31 December 2025. Version 1.0.0 went to NuGet on 2 August 2026. That is a long calendar gap and a short amount of actual work: 57 commits, most of them in two bursts.

The first burst produced something that worked and was badly organised. Argument parsing, HTTP calls and output formatting all lived in the same files. Adding a command meant touching four places and hoping.

The second burst, in May 2026, was a rewrite that kept the command surface and replaced everything behind it. That is where the shape below comes from.

Project Layout 📁

src/Bbx/
  Program.cs        entry point; builds DI once, owns the exit-code contract
  Api/              BitbucketClient, JsonElementExtensions
  Auth/             ICredentialStore, CredentialManager, IAuthProvider, AuthGate
  Commands/         System.CommandLine wiring only, no business logic
  Features///   Request record + Handler, co-located
  Composition/      ServiceRegistration (DI), JsonOptions
tests/Bbx.Tests/    fake HTTP handler, in-memory credential store, no network

One rule holds the whole thing together: files in Commands/ parse arguments and nothing else. They describe the CLI, then hand off. All the logic lives in a handler under Features/.

A handler is small and boring on purpose. Here is the one behind bbx repo list, in full:

public sealed class ListReposHandler(BitbucketClient client, CredentialManager credentials)
{
    public async Task<object> HandleAsync(ListReposRequest request, CancellationToken ct)
    {
        var workspace = Resolve.Workspace(credentials, request.Workspace,
            "Error: Workspace required. Use --workspace or run: bbx auth set-workspace ");

        var endpoint = $"/repositories/{workspace}";
        if (!string.IsNullOrEmpty(request.Query))
            endpoint += $"?q={Uri.EscapeDataString(request.Query)}";

        var repos = new List<object>();
        var count = 0;
        await foreach (var repo in client.GetPaginatedAsync<JsonElement>(endpoint, ct))
        {
            repos.Add(new
            {
                name = repo.TryGetProperty("name", out var n) ? n.GetString() : null,
                slug = repo.TryGetProperty("slug", out var s) ? s.GetString() : null,
                full_name = repo.TryGetProperty("full_name", out var fn) ? fn.GetString() : null,
                is_private = repo.TryGetProperty("is_private", out var ip) && ip.GetBoolean(),
                scm = repo.TryGetProperty("scm", out var scm) ? scm.GetString() : null,
                description = repo.TryGetProperty("description", out var d) ? d.GetString() : null,
                updated_on = repo.TryGetProperty("updated_on", out var u) ? u.GetString() : null,
                size = repo.TryGetProperty("size", out var sz) ? sz.GetInt64() : 0
            });
            if (++count >= request.Limit) break;
        }

        return new
        {
            workspace,
            count = repos.Count,
            repositories = repos,
        };
    }
}

It resolves the workspace, walks a paginated endpoint, reshapes each item, and returns an anonymous object. It never serializes anything and never writes to the console. CommandRunner does that, in one place, so the output contract cannot drift between commands.

Adding a command is now five steps with no thinking involved: write the request record, write the handler, register it in ServiceRegistration, wire it in the matching Commands/ file, and test it against the fake HTTP handler.

Not Multi-Targeting This Time 🎚️

My .NET 10 upgrade post was all about multi-targeting: keep net8.0 and net9.0 alongside net10.0 so nobody gets locked out. bbx targets net10.0 and nothing else, which is the opposite call, so it is worth saying why.

SeedFolder had users on older SDKs already. bbx had none, because it had never shipped. And the calendar was against the old frameworks: .NET 8 and .NET 9 both reach end of support on 10 November 2026. Multi-targeting a brand new package would have meant shipping build assets for runtimes that expire within months of release, for the benefit of zero existing users.

The compatibility problem multi-targeting solves is handled by one property instead:

net10.0


Major

RollForward covers the direction that actually matters for a global tool. Someone who upgrades to .NET 11 keeps a working bbx without me shipping anything.

The rest of the packaging is the familiar global tool block, with a few additions worth calling out:

true
bbx
solrevdev.bbx
bbx

PACKAGE.md
icon.png

true
snupkg
true
true

AssemblyName is set to bbx deliberately. System.CommandLine 2.0 derives the program name in help and usage text from the assembly and no longer lets you set RootCommand.Name, so if the assembly is called Bbx then every usage line reads Bbx pr list. Naming the assembly after the command fixes it.

PackageReadmeFile points at a PACKAGE.md rather than the repository README.md. NuGet.org strips raw HTML, and the GitHub readme leans on

command.SetAction((parseResult, cancellationToken) =>
{
    var workspace = parseResult.GetValue(workspaceOption);
    var repo = parseResult.GetValue(repoOption);
    var state = parseResult.GetValue(stateOption);
    var limit = parseResult.GetValue(limitOption);
    return handler(workspace, repo, state, limit);
});

internal readonly struct Bound<T>
{
    private readonly Func<ParseResult, T> _read;

    private Bound(Func<ParseResult, T> read) => _read = read;

    public T From(ParseResult parseResult) => _read(parseResult);

    public static implicit operator Bound<T>(Option<T> option) => new(pr => pr.GetValue(option)!);

    public static implicit operator Bound<T>(Argument<T> argument) => new(pr => pr.GetValue(argument)!);
}

internal static class CommandBinding
{
    public static void SetHandler<T1, T2, T3, T4>(
        this Command command, Func<T1, T2, T3, T4, Task> handler,
        Bound<T1> b1, Bound<T2> b2, Bound<T3> b3, Bound<T4> b4)
        => command.SetAction((pr, _) => handler(
            b1.From(pr), b2.From(pr), b3.From(pr), b4.From(pr)));
}

var parseResult = rootCommand.Parse(args);

int exitCode;
try
{
    exitCode = await parseResult.InvokeAsync();
}
catch (Exception ex)
{
    // System.CommandLine 2.0 dropped the built-in exception handler, so
    // report the message here rather than printing a stack trace.
    Console.Error.WriteLine($"Error: {ex.Message}");
    return 1;
}

// A value returned from Main overrides Environment.ExitCode, and the
// invocation reports 0 whenever a handler returned normally. Handlers catch
// their own errors and set Environment.ExitCode, so returning the invocation
// result alone made every failed command exit 0.
return exitCode != 0 ? exitCode : Environment.ExitCode;

var hops = 0;
while (IsRedirect(response) && method == HttpMethod.Get && hops++ < MaxRedirects)
{
    var location = response.Headers.Location;
    if (location is null) break;

    var target = location.IsAbsoluteUri ? location : new Uri(current, location);
    response.Dispose();

    // Re-apply credentials only when staying on the same origin, so a
    // redirect out to storage cannot leak them.
    var sameOrigin = Uri.Compare(target, current, UriComponents.SchemeAndServer,
        UriFormat.UriEscaped, StringComparison.OrdinalIgnoreCase) == 0;

    current = target;
    response = await SendOnceAsync(HttpMethod.Get, target.AbsoluteUri, null, ct, accept,
        applyAuth: sameOrigin);
}

public static bool TryGetObject(this JsonElement element, string name, out JsonElement value)
{
    if (element.ValueKind == JsonValueKind.Object
        && element.TryGetProperty(name, out var candidate)
        && candidate.ValueKind == JsonValueKind.Object)
    {
        value = candidate;
        return true;
    }

    value = default;
    return false;
}

$ bbx repo deploy-keys list -w myworkspace -r myrepo
Error: Your credentials lack one or more required privilege scopes. (HTTP 403 Forbidden)
Missing token scopes: admin:repository:bitbucket. Re-issue your token with those
scopes at https://id.atlassian.com/manage-profile/security/api-tokens

public class BitbucketErrorDetail
{
    public string? Message { get; set; }

    /// 

    /// Free-form. A string for most errors, but an object carrying
    /// required and granted arrays for scope failures.
    /// 
    public JsonElement? Detail { get; set; }

    public string? Id { get; set; }
    public BitbucketErrorData? Data { get; set; }
}

bbx auth login

- name: Configure bbx
  run: |
    mkdir -p ~/.config/bbx
    cat > ~/.config/bbx/config.json <<'JSON'
    { "AuthMethod": "api-token",
      "Username": "${{ secrets.BITBUCKET_EMAIL }}",
      "ApiToken": "${{ secrets.BITBUCKET_API_TOKEN }}",
      "DefaultWorkspace": "myworkspace" }
    JSON
    chmod 600 ~/.config/bbx/config.json

jobs:
  validate:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-dotnet@v5
        with:
          global-json-file: global.json
      - run: dotnet restore "$PROJECT_DIR" && dotnet restore "$TEST_PROJECT"
      - run: dotnet build "$PROJECT_DIR" --configuration Release --no-restore
      - run: dotnet test "$TEST_PROJECT" --configuration Release --no-restore
      - run: dotnet pack "$PROJECT_DIR" --configuration Release --no-build

  publish:
    if: github.event_name != 'pull_request'
    permissions:
      contents: write
    runs-on: ubuntu-latest

- uses: actions/setup-dotnet@v5
  with:
    global-json-file: global.json

# The very first release ships the version already in the csproj. Every run
# after that bumps, so a later run can never try to push a version NuGet
# already has.
if git ls-remote --exit-code --tags origin 'refs/tags/v*' >/dev/null 2>&1; then
  case "$BUMP" in
    major) MAJOR=$((MAJOR + 1)); MINOR=0; PATCH=0 ;;
    minor) MINOR=$((MINOR + 1)); PATCH=0 ;;
    patch) PATCH=$((PATCH + 1)) ;;
  esac
  VERSION="$MAJOR.$MINOR.$PATCH"
else
  VERSION="$CURRENT"
  echo "No release tags yet; publishing the initial version as-is."
fi

REMOTE_MASTER=$(git ls-remote origin refs/heads/master | cut -f1)
if git ls-remote --exit-code --tags origin "refs/tags/$TAG" >/dev/null 2>&1; then
  echo "Tag $TAG already exists; this is a safe retry."
  echo "tag_exists=true" >> "$GITHUB_OUTPUT"
else
  if [[ "$REMOTE_MASTER" != "$GITHUB_SHA" ]]; then
    echo "origin/master moved from $GITHUB_SHA to $REMOTE_MASTER; refusing to publish." >&2
    exit 1
  fi
  echo "tag_exists=false" >> "$GITHUB_OUTPUT"
fi

git push --atomic origin HEAD:refs/heads/master "refs/tags/$TAG"

PACKAGE="$NUPKG_DIR/solrevdev.bbx.$VERSION.nupkg"
if [[ ! -f "$PACKAGE" ]]; then
  echo "Expected package was not created: $PACKAGE" >&2
  exit 1
fi

dotnet tool install -g solrevdev.bbx
bbx auth login
bbx auth set-workspace myworkspace
bbx repo list --limit 10

bbx pr list -r myrepo --state OPEN --limit 5
bbx branch list -r myrepo --limit 10
bbx commit list -r myrepo --limit 5
bbx src ls --ref main -r myrepo
bbx src cat --ref main README.md -r myrepo

git clone https://github.com/solrevdev/solrevdev.bbx.git
cd solrevdev.bbx

dotnet build src/Bbx/Bbx.csproj
dotnet test tests/Bbx.Tests/Bbx.Tests.csproj

# run without installing
dotnet run --project src/Bbx/Bbx.csproj -f net10.0 -- repo list -w myworkspace

Overview ☀

With .NET 10 now released as the latest Long-Term Support (LTS) version, it was time to upgrade SeedFolder to support the newest framework.

This comprehensive .NET 10 upgrade guide walks you through migrating a .NET global tool from .NET 8 and 9 to .NET 10 while maintaining full backward compatibility.

Whether you’re upgrading a .NET global tool, console application, or library, this migration tutorial covers everything you need: multi-target framework configuration, dependency management, CI/CD pipeline updates, and thorough testing strategies for a smooth .NET 10 migration.

Why Upgrade to .NET 10? 🎯

Migrating to .NET 10 LTS provides significant benefits for .NET developers. As the latest Long-Term Support release (supported until November 2028), upgrading to .NET 10 ensures your applications stay current with the latest framework improvements.

Benefits of upgrading to .NET 10:

• Latest LTS: Long-term support until November 2028
• Performance improvements: Built-in performance enhancements from .NET 10
• Forward compatibility: Automatic use of the highest installed SDK
• Backward compatibility: Continued support for .NET 8 (LTS) and .NET 9 (STS)

The beauty of multi-targeting during your .NET 10 migration is that users with any of these SDK versions can install and run the tool.

When multiple SDKs are installed, the .NET CLI automatically selects the highest compatible version, making your upgrade path seamless.

The Upgrade Process 🚀

The upgrade was surprisingly straightforward, thanks to .NET’s excellent multi-targeting support. Here’s the step-by-step process I followed:

1. Research and Planning 📚

Before making any changes, I researched the .NET 10 requirements:

• Target Framework Moniker (TFM): net10.0
• SDK Version: 10.0.100 or later
• Breaking Changes: Reviewed Microsoft docs for any breaking changes (none affecting SeedFolder)

I also reviewed the git history to understand how previous SDK upgrades were handled:

git log --all --grep=".NET" --oneline | head -20

This showed that the last major upgrade (PR #259c452) added .NET 8 and 9 support, following a similar pattern I could replicate.

2. Update Project File 🔧

The key change was adding net10.0 to the TargetFrameworks property in the .csproj file:

  
    Exe
-   net8.0;net9.0
+   net8.0;net9.0;net10.0
    latest
    enable
    true
    seedfolder
    ./nupkg
    true
-   1.3.3
+   1.4.0
    
  

Important considerations:

• Use semicolon-separated list for multiple targets
• Bump the version number for NuGet release (1.3.3 → 1.4.0)
• Maintain existing targets for backward compatibility

3. Update CI/CD Pipeline ⚙️

The GitHub Actions workflow needed to install the .NET 10 SDK alongside existing versions:

- name: setup .net core sdk
  uses: actions/setup-dotnet@v4
  with:
      dotnet-version: |
        8.0.x
        9.0.x
+       10.0.x

This ensures the CI pipeline can build all three target frameworks.

4. Dependency Management 📦

I ran dotnet outdated to check for package updates:

dotnet tool install -g dotnet-outdated-tool
dotnet outdated

This revealed that Figgle (the ASCII art library) had a newer version (0.6.5). However, upon investigation, version 0.6.x introduced breaking changes by splitting fonts into a separate package. Since the upgrade goal was .NET 10 support, not dependency updates, I kept Figgle at 0.5.1 to avoid unnecessary complexity.

5. Build and Test ✅

Building for multiple frameworks is straightforward with multi-targeting:

dotnet build solrevdev.seedfolder.sln --configuration Release

Output showed successful builds for all three targets:

solrevdev.seedfolder -> src/bin/Release/net8.0/solrevdev.seedfolder.dll
solrevdev.seedfolder -> src/bin/Release/net9.0/solrevdev.seedfolder.dll
solrevdev.seedfolder -> src/bin/Release/net10.0/solrevdev.seedfolder.dll

Testing the Tool Locally 🧪

Before publishing, I packaged and tested the tool locally:

# Package the tool
dotnet pack -c Release -o /tmp/seedfolder-test

# Install from local package
dotnet tool uninstall -g solrevdev.seedfolder
dotnet tool install -g --add-source /tmp/seedfolder-test solrevdev.seedfolder

# Verify installation
seedfolder --version
# Output: seedfolder version 1.4.0

Then I tested various commands in /tmp to ensure functionality:

# Test dry-run mode
seedfolder --dry-run -t node test-node-app

# Create Python project
seedfolder -t python test-python-app

# Create .NET project
seedfolder --template dotnet test-dotnet-app

# Verify help and template listing
seedfolder --help
seedfolder --list-templates

All tests passed successfully! 🎉

6. Update Documentation 📝

Documentation updates included:

README.md - Updated requirements section:

## Requirements

- This tool requires **.NET 8.0 or .NET 9.0 SDK** to be installed
+ This tool requires **.NET 8.0, .NET 9.0, or .NET 10.0 SDK** to be installed

- **Runtime**: .NET 8.0 or later

CLAUDE.md - Updated framework information:

## Multi-Target Framework Support
- The project targets .NET 8.0 (LTS) and 9.0 (STS)
+ The project targets .NET 8.0 (LTS), 9.0 (STS), and 10.0 (LTS)
+ .NET 10 is the latest LTS release providing long-term support until November 2028.

Multi-Targeting Best Practices 💡

From this experience, here are some best practices for multi-targeting .NET global tools:

1. Use Multi-Targeting, Not Multiple Projects

net8.0;net9.0;net10.0

2. Maintain LTS Versions

Keep the previous LTS version (net8.0) alongside the new one. This gives users flexibility and ensures broad compatibility.

3. Test All Targets

The NuGet package includes all target frameworks:

tools/net8.0/any/solrevdev.seedfolder.dll
tools/net9.0/any/solrevdev.seedfolder.dll
tools/net10.0/any/solrevdev.seedfolder.dll

Verify each target builds correctly and the tool runs on all supported SDKs.

4. Handle Dependencies Carefully

When upgrading, check if dependencies support all your target frameworks. If a dependency doesn’t support your newest target, you have options:

• Keep the dependency at a compatible version
• Use conditional package references for different targets
• Find an alternative package

5. Update CI/CD First

Install all SDK versions in your CI pipeline before merging. This catches incompatibilities early:

- name: setup .net core sdk
  uses: actions/setup-dotnet@v4
  with:
      dotnet-version: |
        8.0.x
        9.0.x
        10.0.x

The Results 📊

After merging PR #17, the CI/CD pipeline automatically:

1. Built all three target frameworks
2. Ran integration tests
3. Packaged the NuGet package
4. Published version 1.4.0 to NuGet

Users can now install the updated version:

dotnet tool update --global solrevdev.seedfolder
seedfolder --version
# Output: seedfolder version 1.4.0

The tool automatically uses the highest installed SDK when run, so users with .NET 10 get the latest performance improvements while users on .NET 8 or 9 continue to work seamlessly.

Framework Support Timeline 📅

Current support timeline for SeedFolder:

Lessons Learned 🎓

1. Multi-targeting is powerful: Adding .NET 10 support while maintaining .NET 8 and 9 compatibility was trivial thanks to proper multi-targeting setup.

2. Dependency management matters: Always check dependencies when upgrading. Sometimes staying on older (but stable) dependency versions is the right choice.

3. Testing is essential: Local testing before publishing caught issues that automated tests might miss.

4. Documentation updates are important: Users need to know what versions are supported and what’s changed.

5. CI/CD automation pays off: Once configured properly, the entire build-test-publish pipeline runs automatically on merge.

What’s Next? 🔮

With .NET 10 support in place, SeedFolder is well-positioned for the future. The next areas of focus include:

• Template marketplace functionality (Issue #15)
• Additional project templates based on community feedback
• Enhanced template customization options

The full source code and history of this upgrade are available on GitHub.

Installation 📦

Try the latest version with .NET 10 support:

# Install or update to the latest version
dotnet tool update --global solrevdev.seedfolder

# Create a new project with your favorite template
seedfolder --template python my-new-project

# Or use interactive mode
seedfolder

Success! 🎉

Overview ☀

Sometimes you need to extract structured data from YouTube videos for analysis, documentation, or automation. While there are various web-based solutions, having a command-line tool that outputs clean JSON makes integration with scripts and pipelines much easier.

I built ytx - a .NET Global Tool that extracts YouTube video metadata and transcripts as structured JSON. The tool takes a YouTube URL and returns the video title, description, and full transcript with timestamps in both raw text and markdown formats. This post walks you through building your own .NET global tool from scratch, covering architecture design, caption handling, JSON serialization, NuGet packaging, and setting up automated CI/CD with GitHub Actions.

The Problem 🎯

I wanted a simple way to:

• Extract YouTube video transcripts for analysis
• Get structured JSON output for easy parsing
• Handle different caption languages and auto-generated captions
• Create timestamped links back to specific moments in videos
• Package everything as a portable command-line tool

Project Architecture 🏗️

The tool is built as a single-file .NET console application with a simple but effective architecture:

record Input(string url);

class Output
{
    public string url { get; set; } = "";
    public string title { get; set; } = "";
    public string description { get; set; } = "";
    public string transcriptRaw { get; set; } = "";
    public string transcript { get; set; } = "";
}

The data flow is straightforward:

1. Input validation (command-line args or JSON via stdin)
2. YouTube video data extraction via YoutubeExplode
3. Caption track discovery and selection
4. Transcript formatting (raw + markdown with timestamps)
5. JSON serialization to stdout

Getting Started 🚀

First, I created the project structure:

dotnet new console -n Ytx
cd Ytx

The key to making this a global tool is the .csproj configuration:

 Sdk="Microsoft.NET.Sdk">
  
    Exe
    net8.0;net9.0
    enable
    enable

    
    true
    ytx
    solrevdev.ytx

    
    1.0.2

    
    solrevdev
    Extract YouTube title, description, and transcript (raw + Markdown) as JSON.
    YouTube;transcript;captions;cli;dotnet-tool;json
    https://github.com/solrevdev/solrevdev.ytx
    https://github.com/solrevdev/solrevdev.ytx
    MIT
    README.md

    
    ../../nupkg
  

  
     Include="YoutubeExplode" Version="6.5.4" />
  

  
     Include="../../README.md" Pack="true" PackagePath="\" />
  

The crucial elements are:

• PackAsTool>true - Makes this a global tool
• ToolCommandName - The command users will type
• TargetFrameworks - Multi-targeting for compatibility
• PackageOutputPath - Consistent build artifacts location

Core Implementation ⚙️

The main challenge was handling YouTube’s various caption formats and languages. Here’s the complete Main method:

static async Task<int> Main(string[] args)
{
    try
    {
        string? url = null;

        if (args.Length == 1 && !string.IsNullOrWhiteSpace(args[0]))
        {
            url = args[0];
        }
        else
        {
            string stdin = Console.IsInputRedirected ? await Console.In.ReadToEndAsync() : "";
            if (!string.IsNullOrWhiteSpace(stdin))
            {
                var input = JsonSerializer.Deserialize<Input>(stdin.Trim(),
                    new JsonSerializerOptions { PropertyNameCaseInsensitive = true });
                url = input?.url;
            }
        }

        if (string.IsNullOrWhiteSpace(url))
        {
            Console.Error.WriteLine("Usage: ytx \n   or: echo '{\"url\":\"https://...\"}' | ytx");
            return 2;
        }

        var client = new YoutubeClient();
        var videoId = VideoId.TryParse(url) ?? throw new ArgumentException("Invalid YouTube URL/ID.");
        var video = await client.Videos.GetAsync(videoId);
        var title = video.Title ?? "";
        var description = video.Description ?? "";

        string transcriptRaw = "";
        string transcriptMd = "";

        try
        {
            var manifest = await client.Videos.ClosedCaptions.GetManifestAsync(video.Id);
            var track = manifest.Tracks
                .OrderByDescending(t => t.Language.Name.Contains("English", StringComparison.OrdinalIgnoreCase))
                .ThenByDescending(t => t.IsAutoGenerated)
                .FirstOrDefault();

            if (track != null)
            {
                var captions = await client.Videos.ClosedCaptions.GetAsync(track);

                var rawSb = new StringBuilder();
                var mdSb  = new StringBuilder();

                foreach (var c in captions.Captions)
                {
                    var text = NormalizeCaption(c.Text);
                    if (string.IsNullOrWhiteSpace(text)) continue;

                    if (rawSb.Length > 0) rawSb.Append(' ');
                    rawSb.Append(text);

                    var ts = ToHhMmSs(c.Offset);
                    var link = $"https://www.youtube.com/watch?v={video.Id}&t={(int)c.Offset.TotalSeconds}s";
                    mdSb.AppendLine($"- [{ts}]({link}) {text}");
                }

                transcriptRaw = rawSb.ToString().Trim();
                transcriptMd = mdSb.ToString().TrimEnd();
            }
            else
            {
                transcriptRaw = "";
                transcriptMd = "_No transcript/captions available for this video._";
            }
        }
        catch
        {
            transcriptRaw = "";
            transcriptMd = "_No transcript/captions available or captions retrieval failed._";
        }

        var output = new Output
        {
            url = url,
            title = title,
            description = description,
            transcriptRaw = transcriptRaw,
            transcript = transcriptMd
        };

        var json = JsonSerializer.Serialize(output, new JsonSerializerOptions
        {
            WriteIndented = true,
            Encoder = System.Text.Encodings.Web.JavaScriptEncoder.UnsafeRelaxedJsonEscaping
        });

        Console.OutputEncoding = Encoding.UTF8;
        Console.WriteLine(json);
        return 0;
    }
    catch (Exception ex)
    {
        Console.Error.WriteLine($"Error: {ex.Message}");
        return 1;
    }
}

Smart Caption Detection 🧠

One of the trickiest parts was handling YouTube’s various caption formats. The tool needs to:

• Prefer English captions when available
• Fall back to any available language
• Handle both manual and auto-generated captions
• Gracefully handle videos without captions

The caption selection logic is embedded in the Main method above (lines 32-62), where it:

1. Gets the caption manifest for the video
2. Orders tracks by English language preference, then by auto-generated status
3. Downloads the selected caption track and formats both raw and markdown output
4. Handles error cases gracefully with appropriate fallback messages

Utility Functions 🔧

The tool includes helper functions for formatting and text normalization:

static string ToHhMmSs(TimeSpan ts)
{
    int h = (int)ts.TotalHours;
    int m = ts.Minutes;
    int s = ts.Seconds;
    return h > 0 ? $"{h:00}:{m:00}:{s:00}" : $"{m:00}:{s:00}";
}

static string NormalizeCaption(string text)
{
    if (string.IsNullOrWhiteSpace(text)) return "";
    text = Regex.Replace(text, @"\s+", " ").Trim();
    text = text.Replace(" ", " ");
    return text;
}

Local Development and Testing 🧪

During development, I used this workflow:

# Restore dependencies
dotnet restore src/Ytx

# Build the project
dotnet build src/Ytx -c Release

# Test with a YouTube URL
dotnet run --project src/Ytx --framework net8.0 "https://www.youtube.com/watch?v=dQw4w9WgXcQ"

# Package for local installation testing
dotnet pack src/Ytx -c Release
dotnet tool install -g solrevdev.ytx --add-source ./nupkg

This allowed me to test the tool end-to-end before publishing to NuGet.

Output Format 📄

The tool produces clean, structured JSON:

{
  "url": "https://www.youtube.com/watch?v=dQw4w9WgXcQ",
  "title": "Rick Astley - Never Gonna Give You Up (Official Music Video)",
  "description": "The official video for \"Never Gonna Give You Up\" by Rick Astley...",
  "transcriptRaw": "We're no strangers to love You know the rules and so do I...",
  "transcript": "- [00:17](https://www.youtube.com/watch?v=dQw4w9WgXcQ&t=17s) We're no strangers to love\n- [00:20](https://www.youtube.com/watch?v=dQw4w9WgXcQ&t=20s) You know the rules and so do I..."
}

The markdown transcript format makes it easy to create documentation with clickable timestamps that jump directly to specific moments in the video.

Production-Ready CI/CD Pipeline with GitHub Actions 🤖

To streamline releases and reduce manual work, I set up GitHub Actions to automatically handle the entire release pipeline. Unlike simple workflows, this production pipeline:

• Runs on every push to master (only when source files change, avoiding redundant builds)
• Allows manual triggers with version bump selection (patch, minor, or major)
• Automatically increments semantic versions in your .csproj file
• Commits version changes back to the repository with git tags
• Builds and publishes to NuGet with proper error handling
• Creates GitHub releases with auto-generated release notes
• Supports multiple .NET versions (8.x and 9.x) for maximum compatibility

The complete workflow file (.github/workflows/publish.yml) handles all of this:

name: Publish NuGet (ytx)

on:
  workflow_dispatch:
    inputs:
      bump:
        description: 'Version bump type (major|minor|patch)'
        required: true
        default: 'patch'
  push:
    branches: [ "master" ]
    paths:
      - 'src/Ytx/**'
      - '.github/workflows/publish.yml'

permissions:
  contents: write
  packages: read

env:
  PROJECT_DIR: src/Ytx
  CSPROJ: src/Ytx/Ytx.csproj
  NUPKG_DIR: nupkg
  NUGET_SOURCE: https://api.nuget.org/v3/index.json

jobs:
  build-pack-publish:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: |
            9.x
            8.x

      - name: Restore
        run: dotnet restore $PROJECT_DIR

      - name: Determine and bump version
        id: bump
        shell: bash
        run: |
          set -euo pipefail
          CURR=$(grep -oPm1 '(?<=)[^<]+' "$CSPROJ")
          echo "Current version: $CURR"
          IFS='.' read -r MAJ MIN PAT <<< "$CURR"
          BUMP="${{ github.event.inputs.bump || 'patch' }}"
          case "$BUMP" in
            major) MAJ=$((MAJ+1)); MIN=0; PAT=0 ;;
            minor) MIN=$((MIN+1)); PAT=0 ;;
            patch|*) PAT=$((PAT+1)) ;;
          esac
          NEW="$MAJ.$MIN.$PAT"
          echo "New version: $NEW"
          sed -i "s|$CURR|$NEW|" "$CSPROJ"
          echo "version=$NEW" >> "$GITHUB_OUTPUT"

      - name: Commit version bump
        if: ${{ github.ref == 'refs/heads/master' }}
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          git add ${{ env.CSPROJ }}
          git commit -m "chore: bump version to ${{ steps.bump.outputs.version }}"
          git tag "v${{ steps.bump.outputs.version }}"
          git push --follow-tags

      - name: Build
        run: dotnet build $PROJECT_DIR -c Release --no-restore

      - name: Pack
        run: dotnet pack $PROJECT_DIR -c Release --no-build

      - name: Publish to NuGet
        env:
          NUGET_API_KEY: ${{ secrets.NUGET_API_KEY }}
        run: |
          dotnet nuget push $NUPKG_DIR/*.nupkg \
            --api-key "$NUGET_API_KEY" \
            --source "$NUGET_SOURCE" \
            --skip-duplicate

      - name: Create GitHub Release
        uses: softprops/action-gh-release@v2
        with:
          tag_name: v${{ steps.bump.outputs.version }}
          name: ytx v${{ steps.bump.outputs.version }}
          generate_release_notes: true

Understanding the Workflow Architecture 🏗️

This workflow implements several production best practices that help .NET developers distribute global tools effectively:

Environment Variables for DRY Principle: The env: block defines reusable values (PROJECT_DIR, CSPROJ, NUPKG_DIR, NUGET_SOURCE) referenced throughout the workflow. This approach keeps configuration centralized: change a directory path once, and it updates everywhere. This is crucial when managing complex multi-project solutions or adjusting package output locations.

Permissions Block: The permissions: section restricts the workflow to only what it needs:

• contents: write: Required to create commits, tags, and push back to the repository
• packages: read: Required for accessing NuGet package data

This follows the principle of least privilege, improving security by preventing the workflow from performing unauthorized actions.

Smart Trigger Configuration:

on:
  push:
    branches: [ "master" ]
    paths:
      - 'src/Ytx/**'
      - '.github/workflows/publish.yml'

The paths: filter prevents unnecessary builds when only documentation or other non-source files change. This saves CI/CD minutes and reduces feedback latency.

Semantic Version Bumping with bash: The version bump step demonstrates how to parse and manipulate semantic versions programmatically:

IFS='.' read -r MAJ MIN PAT <<< "$CURR"  # Parse 1.0.2 into components
case "$BUMP" in
  major) MAJ=$((MAJ+1)); MIN=0; PAT=0 ;;  # 1.0.2 → 2.0.0
  minor) MIN=$((MIN+1)); PAT=0 ;;         # 1.0.2 → 1.1.0
  patch|*) PAT=$((PAT+1)) ;;             # 1.0.2 → 1.0.3
esac

This approach ensures version consistency without manually editing .csproj files. The echo "version=$NEW" >> "$GITHUB_OUTPUT" sends the new version to subsequent steps, a key pattern in GitHub Actions workflows.

Git Automation for Reproducible Releases:

git config user.name "github-actions[bot]"
git add $
git commit -m "chore: bump version to $"
git tag "v$"
git push --follow-tags

This creates an immutable audit trail. Every NuGet release corresponds to:

1. A specific git commit (with the bumped version)
2. A git tag (for easy checkout: git checkout v1.0.3)
3. A GitHub release (with release notes)

This traceability is essential for troubleshooting issues and understanding what code produced which package version.

Optimized Build Pipeline: Notice the careful use of build flags:

dotnet restore $PROJECT_DIR              # Explicit restore
dotnet build $PROJECT_DIR -c Release --no-restore    # Skip redundant restore
dotnet pack $PROJECT_DIR -c Release --no-build       # Skip redundant build

The --no-restore and --no-build flags prevent repeating expensive operations. For .NET global tools especially, proper dependency isolation matters because you want to ensure your tool works across different .NET SDK versions, which is why this workflow tests against both 8.x and 9.x.

NuGet Publishing with Idempotency:

dotnet nuget push $NUPKG_DIR/*.nupkg \
  --skip-duplicate

The --skip-duplicate flag means you can safely re-run the workflow without errors if a version was already published. This is crucial for reliability, since sometimes you need to retry a build due to temporary network issues or API timeouts.

Automated GitHub Releases:

- name: Create GitHub Release
  uses: softprops/action-gh-release@v2
  with:
    tag_name: v$
    generate_release_notes: true

This automatically creates a GitHub release with auto-generated release notes based on commit messages since the last release. Users see a clear changelog without manual effort, and the release is properly associated with the NuGet package version.

Installation and Usage 📦

Once published to NuGet, users can install the tool globally:

# Install the tool
dotnet tool install -g solrevdev.ytx

# Basic usage
ytx "https://www.youtube.com/watch?v=dQw4w9WgXcQ"

# Via JSON input for scripting
echo '{"url":"https://www.youtube.com/watch?v=dQw4w9WgXcQ"}' | ytx

# Save to file for further processing
ytx "https://www.youtube.com/watch?v=dQw4w9WgXcQ" > video-data.json

# Update to latest version
dotnet tool update -g solrevdev.ytx

Error Handling and Edge Cases ⚠️

The tool handles various error scenarios gracefully:

• Invalid YouTube URLs (exit code 2)
• Private or region-restricted videos (exit code 1)
• Videos without captions (returns explanatory message)
• Network errors (exit code 1)

This makes it suitable for use in scripts and automation pipelines.

Key Learnings & Best Practices 💡

Building this .NET global tool taught me several valuable lessons applicable to any command-line tool project:

1. YoutubeExplode Library Maturity: Version 6.5.4 resolved transcript extraction issues that plagued earlier versions. Always verify library versions match your use case requirements.
2. .NET Global Tool Packaging: The PackAsTool property, ToolCommandName, and PackageReadmeFile are crucial for NuGet discoverability. Missing these makes your tool harder to find.
3. Multi-targeting Strategy: Supporting both .NET 8 and 9 simultaneously ensures broader compatibility across development environments and CI/CD pipelines.
4. Flexible Input/Output Design: Supporting both command-line arguments and stdin (JSON) makes your tool more versatile for automation, scripting, and pipeline integration.
5. Intelligent Caption Selection: Smart ordering logic (English preference → auto-generated fallback) dramatically improves user experience compared to simple “first available” approaches.
6. Semantic Versioning in CI/CD: Automating patch/minor/major version bumps reduces manual work and ensures consistency across releases.

Future Enhancements 🔮

Potential improvements for future versions:

• Support for downloading specific time ranges
• Batch processing multiple URLs
• Custom output formats (CSV, XML)
• Integration with subtitle file formats (SRT, VTT)
• Translation support for non-English captions

Development Velocity with Modern AI Tooling ⚡

What stands out about this project is the development speed enabled by modern AI assistance. From initial concept through architecture, implementation, testing, and NuGet publication took just a few hours - something that would have required days of work just five years ago.

The AI-Assisted Development Workflow 🤖

This .NET global tool project showcased the power of combining multiple AI tools effectively:

• Claude Code: Handled core architecture decisions, .NET-specific patterns, error handling strategies, and GitHub Actions CI/CD pipeline configuration. Particularly valuable for getting the .csproj packaging configuration correct on the first attempt.
• GitHub Copilot: Excelled at generating repetitive code patterns, JSON serialization boilerplate, regex text normalization functions, and test scaffold code.
• MCPs (Model Context Protocol): Provided seamless integration between different AI tools and development contexts, making the workflow feel natural rather than fragmented.

The Human-AI Partnership in Practice 🤝

The most interesting insight wasn’t that AI wrote the code, but how it transformed the development process itself:

1. Design-First Development: Instead of iterating through implementation details, focus shifted to user experience and clean data flow architecture.
2. Documentation-Driven Development: Writing this technical blog post in parallel with coding helped clarify requirements and catch edge cases early.
3. Risk-Free Exploration: AI assistance made it easy to try different architectural approaches without the usual “sunk cost” hesitation.

What This Means for .NET Developers 🚀

This project represents a new normal in software development, where the bottleneck shifts from typing code to thinking through problems and user needs. The combination of AI coding assistants, intelligent build toolchains (GitHub Actions, NuGet), and human creativity is genuinely transformative.

For developers hesitant about AI tools: they’re not replacing you; they’re amplifying your ability to solve meaningful problems quickly. The future belongs to developers who can effectively collaborate with AI to build better software faster.

Get Started Building Your Own .NET Global Tool 📦

Ready to create your own command-line tool and publish it to NuGet? Install ytx to see a working example:

dotnet tool install -g solrevdev.ytx
ytx "https://www.youtube.com/watch?v=dQw4w9WgXcQ"

Or explore the source code on GitHub to see the complete implementation.

Success! 🎉

Background

When setting up a new Windows machine, I used to rely on Scoop and Chocolatey for package management. Both are excellent tools, but when Microsoft introduced Windows Package Manager (winget), I decided to give it a try on my latest machine setup.

The problem? Finding winget package IDs was tedious. While winget search works, I wanted something faster - a web interface where I could quickly search, find packages, and copy installation commands. That’s how winget-search was born, available at https://solrevdev.com/winget-search/.

The Challenge

Winget packages are stored in Microsoft’s winget-pkgs repository with over 30,000 YAML manifest files. The repository structure follows a pattern: manifests/publisher/package_name/version/ with separate files for different locales and installers.

I needed to:

• Extract package metadata from thousands of YAML files
• Handle multiple versions and keep only the latest
• Filter for English descriptions only
• Build a fast, searchable web interface
• Keep data fresh with automated updates

The Solution

Architecture Overview

I built a three-part system:

1. Python extraction script - Parses YAML manifests and generates JSON
2. Static HTML search interface - Client-side search with instant results
3. GitHub Actions automation - Daily updates and deployment

Data Extraction

The Python script (extract_packages.py) does the heavy lifting:

def extract_package_info(manifest_dir):
    """Extract comprehensive package info from a manifest directory"""
    package_info = {
        "id": None,
        "name": None,
        "description": None,
        "publisher": None,
        "version": None,
        "tags": [],
        "homepage": None,
        "license": None
    }

    # Process version manifest first
    version_file = next((f for f in yaml_files if not '.locale.' in f), None)
    if version_file:
        with open(os.path.join(manifest_dir, version_file), encoding="utf-8") as f:
            doc = yaml.safe_load(f)
            package_info["id"] = doc.get("PackageIdentifier")
            package_info["version"] = doc.get("PackageVersion")

    # Look for English locale file
    locale_file = next((f for f in yaml_files if '.locale.en-US.' in f), None)
    if locale_file:
        with open(os.path.join(manifest_dir, locale_file), encoding="utf-8") as f:
            doc = yaml.safe_load(f)
            package_info["name"] = doc.get("PackageName")
            package_info["publisher"] = doc.get("Publisher")
            package_info["description"] = doc.get("Description")

The script handles version comparison using Python’s packaging library to ensure we only keep the latest version of each package:

def parse_version(ver_str):
    """Parse version string for proper comparison"""
    try:
        return version.parse(ver_str)
    except:
        return version.parse("0.0.0")  # Fallback for non-standard versions

Web Interface

The search interface is pure vanilla JavaScript - no frameworks needed. It loads a ~5MB JSON file containing all package data and performs client-side search for instant results:

function showResults(query) {
    const q = query.trim().toLowerCase();

    let results;
    if (!q) {
        results = packages.slice(0, 50);
    } else {
        results = packages.filter(pkg => {
            const idMatch = pkg.id?.toLowerCase().includes(q);
            const nameMatch = pkg.name?.toLowerCase().includes(q);
            const descMatch = pkg.description?.toLowerCase().includes(q);
            const publisherMatch = pkg.publisher?.toLowerCase().includes(q);
            const tagMatch = pkg.tags?.some(tag =>
                tag && typeof tag === 'string' && tag.toLowerCase().includes(q)
            );

            return idMatch || nameMatch || descMatch || publisherMatch || tagMatch;
        }).slice(0, 100);
    }

    // Render results...
}

Each search result includes a one-click copy button for the winget install command:

function copyCommand(button, cmd) {
    navigator.clipboard.writeText(cmd).then(() => {
        const originalHtml = button.innerHTML;
        button.classList.add('success');
        button.innerHTML = `
            
            Copied!
        `;

        setTimeout(() => {
            button.classList.remove('success');
            button.innerHTML = originalHtml;
        }, 2000);
    });
}

Automation with GitHub Actions

The magic happens in the GitHub Actions workflow that runs daily at 2 AM UTC:

name: Build and Deploy
on:
  schedule:
    - cron: '0 2 * * *'  # Daily at 2 AM UTC
  workflow_dispatch:

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Cache winget-pkgs
        uses: actions/cache@v4
        with:
          path: winget-pkgs
          key: winget-pkgs-$
          restore-keys: winget-pkgs-

      - name: Clone winget-pkgs repository
        run: |
          if [ ! -d "winget-pkgs" ]; then
            git clone --depth 1 https://github.com/microsoft/winget-pkgs.git
          else
            cd winget-pkgs && git pull origin main
          fi

      - name: Extract packages
        run: python extract_packages.py winget-pkgs/manifests/ packages.json

      - name: Deploy to GitHub Pages
        uses: peaceiris/actions-gh-pages@v4
        with:
          github_token: $
          publish_dir: .

Technical Highlights

Performance Optimizations

• Client-side search: No server required, instant results
• Debounced input: 300ms delay prevents excessive filtering
• Result limiting: Shows max 100 results for smooth scrolling
• Caching: GitHub Actions caches the large winget-pkgs repository

User Experience Features

• Keyboard shortcuts: Press / to focus search, Esc to clear
• Dark mode: Automatic theme based on system preferences
• Mobile-friendly: Responsive design works on all devices
• Copy feedback: Visual confirmation when commands are copied

Data Quality

• English-only: Filters for .locale.en-US.yaml files
• Latest versions: Semantic version comparison ensures freshness
• Type safety: Handles edge cases like non-string tags
• Error resilience: Continues processing even if individual manifests fail

Deployment

The entire deployment is automated through GitHub Pages. The workflow:

1. Clones the microsoft/winget-pkgs repository (1GB+, hence the caching)
2. Extracts package data using Python script
3. Generates a packages.json file with ~30,000 packages
4. Deploys everything to GitHub Pages using peaceiris/actions-gh-pages

No manual intervention needed - just push code and GitHub Actions handles the rest!

Results

The end result is a fast, searchable interface hosted at GitHub Pages that:

• Loads 30,000+ packages in under 3 seconds
• Provides instant search results
• Generates copy-ready winget install commands
• Updates automatically every day
• Costs nothing to host

Perfect for when you need to quickly find that package ID for your setup scripts! You can use it right now at https://solrevdev.com/winget-search/.

Future Improvements

Some ideas I’m considering:

• Package categories - Group by software type
• Fuzzy search - Better matching for typos
• PowerShell commands - Alternative to cmd syntax
• Package details modal - Show more metadata
• Search history - Remember recent searches

Live Demo & Resources

Try the winget search tool now: https://solrevdev.com/winget-search/

The source code is available on GitHub under the MIT license.

Success 🎉

Overview ☀

It’s been over 4 years since I first published my .NET Core Global Tool blog post about creating SeedFolder.

What started as a simple tool to copy my personal dotfiles has evolved into something much more powerful and hopefully eventually will be useful to the broader developer community.

The original version was quite limited - it basically just copied my specific .editorconfig, .gitignore, and other dotfiles to new project folders. While this was useful for me, it wasn’t particularly helpful to other developers who might have different preferences or work with different technology stacks.

The Evolution Journey 🌱

Over the years, I’ve made several significant improvements to SeedFolder, particularly leveraging GitHub Copilot to help accelerate development and implement features I might not have found time to build otherwise.

Upgrading Through .NET LTS Versions ⬆️

One of the consistent maintenance tasks has been keeping the tool updated with each .NET LTS release. For example, upgrading to more currwnt .NET versions involved updating the target framework and ensuring compatibility:

  
    Exe
-    net6.0
    
+   net8.0;net9.0
    true
    seedfolder
    
  

The tool now uses multi-targeting to support various .NET SDKs, ensuring users can install and use it regardless of which .NET version they have installed.

GitHub Copilot as a Development Partner 🤖

The real transformation happened when I started using GitHub Copilot - both from the web interface and my iOS app - to help implement more ambitious features. This was a game-changer for a side project that I rarely had dedicated time to improve.

My AI Development Journey 🛤️

This project coincided with my own evolution in AI-assisted development. Over the past couple of years, I’ve progressed through several stages:

1. Context Sharing Era: Using tools like Repomix to bundle codebase snippets for web-based ChatGPT, Claude, and Gemini conversations
2. Desktop Integration: Adopting dedicated ChatGPT and Claude desktop clients for more seamless workflows
3. IDE-Native AI: Integrating GitHub Copilot directly into VSCode, progressing through OpenAI’s GPT 4.0, 4.1, and eventually to GPT-5 and Claude Sonnet 4
4. Terminal-First Development: Embracing agentic terminal clients like Warp Terminal, Claude Code, and Codex for more direct development interaction

Today, my workflow splits between contexts: during work hours, I rely on VSCode with GitHub Copilot and terminal-based AI clients. But evenings and weekends - when I’m often watching TV with my phone in hand - GitHub’s web and iOS Copilot interfaces became the perfect tools for iterating on side projects through issue-driven development.

This hybrid approach proved ideal for SeedFolder’s evolution: I could sketch out features and improvements during downtime, then implement them through focused GitHub issue conversations. The combination of accessibility and power made consistent progress possible on a project that might otherwise have stagnated between day job commitments.

Here’s how the process typically worked:

1. Issue Creation: I’d create a GitHub issue describing what I wanted to achieve
2. Copilot Collaboration: Using GitHub Copilot from the web or iOS app, I’d work through the implementation
3. Iterative Development: Copilot would suggest implementations, and we’d refine them together

For example, Issue #9 outlined a comprehensive roadmap for turning SeedFolder into a proper template system. What would have taken me weeks to implement manually, Copilot helped me accomplish in focused sessions.

From Single Template to Multi-Template System 📂

The biggest transformation was moving from a single set of dotfiles to a comprehensive template system. Pull Request #10 introduced support for six different project types:

# Interactive mode - prompts for template selection
seedfolder

# Specific template usage
seedfolder --template dotnet MyNewProject
seedfolder --template node MyNodeApp
seedfolder --template python data-analysis
seedfolder --template ruby rails-app
seedfolder --template markdown blog-posts
seedfolder --template universal generic-project

# Preview what would be created
seedfolder --dry-run --template node MyApp

Each template now includes carefully curated files appropriate for that project type:

• dotnet: .editorconfig, .gitignore for C#, omnisharp.json
• node: package.json template, .nvmrc, npm-specific .gitignore
• python: requirements.txt, .python-version, Python .gitignore
• ruby: Gemfile template, .ruby-version, Ruby .gitignore
• markdown: Basic structure for documentation projects
• universal: Generic files useful across all project types

Enhanced User Experience ✨

The tool is now much more user-friendly and customizable. Some key improvements include:

Interactive Mode:

$ seedfolder
? Select a project template: (Use arrow keys)
❯ dotnet - .NET applications with C# configuration
  node - Node.js applications with npm setup
  python - Python projects with pip requirements
  ruby - Ruby applications with Bundler setup
  markdown - Documentation and static sites
  universal - Generic template for any project type

Better CLI Interface:

# All the standard options you'd expect
seedfolder --help
seedfolder --version
seedfolder --list-templates
seedfolder --template dotnet --output ./projects MyApi

Cross-Platform Compatibility: The tool now works seamlessly across Windows, macOS, and Linux, with platform-specific optimizations.

Improved CI/CD Pipeline 🔄

Pull Request #16 addressed CI workflow issues and simplified the build process:

# yaml-language-server: $schema=https://json.schemastore.org/github-workflow.json

name: CI

on:
    push:
        branches:
            - master
            - release/*
        paths-ignore:
          - '**/*.md'
          - '**/*.gitignore'
          - '**/*.gitattributes'
    pull_request:
        branches:
            - master
            - release/*
        paths-ignore:
            - '**/*.md'
            - '**/*.gitignore'
            - '**/*.gitattributes'
jobs:
    build:
        if: github.event_name == 'push' && contains(toJson(github.event.commits), '***NO_CI***') == false && contains(toJson(github.event.commits), '[ci skip]') == false && contains(toJson(github.event.commits), '[skip ci]') == false
        runs-on: ubuntu-latest
        env:
          ACTIONS_ALLOW_UNSECURE_COMMANDS: true
          DOTNET_CLI_TELEMETRY_OPTOUT: 1
          DOTNET_SKIP_FIRST_TIME_EXPERIENCE: 1
          DOTNET_NOLOGO: true
          DOTNET_GENERATE_ASPNET_CERTIFICATE: false
          DOTNET_ADD_GLOBAL_TOOLS_TO_PATH: false
          DOTNET_MULTILEVEL_LOOKUP: 0

        steps:
            - name: checkout code
              uses: actions/checkout@v4

            - name: setup .net core sdk
              uses: actions/setup-dotnet@v4
              with:
                  dotnet-version: |
                    8.0.x
                    9.0.x

            - name: dotnet build
              run: dotnet build solrevdev.seedfolder.sln --configuration Release

            - name: run integration tests
              run: ./tests/integration-test.sh

            - name: dotnet pack
              run: dotnet pack solrevdev.seedfolder.sln -c Release --no-build --include-source --include-symbols

            - name: setup nuget
              if: github.event_name == 'push' && github.ref == 'refs/heads/master'
              uses: nuget/setup-nuget@v1
              with:
                  nuget-version: latest

            - name: Publish NuGet
              if: github.event_name == 'push' && github.ref == 'refs/heads/master'
              uses: rohith/publish-nuget@v2.1.1
              with:
                PROJECT_FILE_PATH: src/solrevdev.seedfolder.csproj # Relative to repository root
                NUGET_KEY: $ # nuget.org API key
                PACKAGE_NAME: solrevdev.seedfolder

The Power of AI-Assisted Development 🚀

What I found particularly interesting about working with GitHub Copilot was how it helped me think through problems I might not have tackled otherwise. For instance:

• Error Handling: Copilot suggested comprehensive error handling patterns I wouldn’t have thought to implement
• Cross-Platform Considerations: It caught platform-specific issues early in development
• User Experience: Proposed CLI interface improvements that made the tool much more pleasant to use
• Testing Strategies: Suggested test cases and scenarios I hadn’t considered

Here’s an example of how Copilot helped implement the template system using enums and pattern matching:

// Template metadata structure for future extensibility
internal record TemplateFile(string ResourceName, string FileName, string Description = "");

// Enum for supported project types
internal enum ProjectType
{
    Dotnet, Node, Python, Ruby, Markdown, Universal
}

private static bool TryParseProjectType(string input, out ProjectType projectType)
{
    projectType = input switch
    {
        "dotnet" or "net" or "csharp" => ProjectType.Dotnet,
        "node" or "nodejs" or "javascript" or "js" => ProjectType.Node,
        "python" or "py" => ProjectType.Python,
        "ruby" or "rb" => ProjectType.Ruby,
        "markdown" or "md" or "docs" => ProjectType.Markdown,
        "universal" or "basic" or "minimal" => ProjectType.Universal,
        _ => ProjectType.Dotnet
    };

    return input is "dotnet" or "net" or "csharp" or "node" or "nodejs"
        or "javascript" or "js" or "python" or "py" or "ruby" or "rb"
        or "markdown" or "md" or "docs" or "universal" or "basic" or "minimal";
}

private static TemplateFile[] GetTemplateFiles(ProjectType projectType)
{
    return projectType switch
    {
        ProjectType.Node => GetNodeTemplate(),
        ProjectType.Python => GetPythonTemplate(),
        ProjectType.Ruby => GetRubyTemplate(),
        ProjectType.Markdown => GetMarkdownTemplate(),
        ProjectType.Universal => GetUniversalTemplate(),
        _ => GetDotnetTemplate()
    };
}

Next Steps: The Marketplace Vision 🏪

The next major evolution is planned around Issue #15 - creating a template marketplace. This will allow the community to share and install custom templates:

# Future marketplace commands
seedfolder marketplace search angular
seedfolder marketplace install solrevdev/vue-typescript
seedfolder marketplace list --installed
seedfolder marketplace update

The marketplace will be hosted as a separate GitHub repository at solrevdev/seedfolder-marketplace with this structure:

solrevdev/seedfolder-marketplace/
├── templates/
│   ├── angular/
│   │   ├── template.json
│   │   └── files/
│   ├── vue/
│   └── rust/
├── registry.json
└── README.md

This will enable developers to:

• Share their own project templates
• Override built-in templates with their preferences
• Fork the marketplace for team-specific template collections
• Contribute improvements back to the community

Installation and Usage Today 📦

The current version is available on NuGet and much more capable than the original:

# Install the latest version
dotnet tool install --global solrevdev.seedfolder

# Create a new .NET project with proper scaffolding
seedfolder --template dotnet MyWebApi

# Interactive mode for template selection
seedfolder MyNewProject

# See all available options
seedfolder --help

Lessons Learned 💡

Working on SeedFolder’s evolution taught me several valuable lessons:

1. AI as a Coding Partner: GitHub Copilot isn’t just an autocomplete tool - it’s a thinking partner that can help you explore solutions you might not consider
2. Incremental Improvement: Small, consistent improvements over time can transform a simple tool into something genuinely useful
3. Community Focus: Building for your own needs first is fine, but thinking about broader use cases makes tools more valuable
4. Template Systems: Flexibility through templates is much more powerful than hardcoded configurations
5. Context-Driven Development: Different AI tools excel in different contexts - terminal clients for focused coding sessions, mobile interfaces for planning and ideation

The transformation from a personal dotfile copier to a comprehensive project scaffolding tool shows how AI assistance can help maintain and evolve side projects that might otherwise stagnate. The key insight was finding the right AI tool for each development context rather than trying to force a single solution across all scenarios.

Watch out for the next steps as I work on the marketplace functionality - the goal is to make SeedFolder not just more useful, but a platform for the community to share their own project setup best practices.

If you’re curious about the specific workflows and tools that made this multi-context AI development approach work, I’m planning a follow-up post diving deeper into the practical setup and decision-making process behind choosing the right AI tool for different development scenarios.

Success! 🎉

Overview ☀

While testing a feature locally on my macmini I was uploading an image when I got the following error:

Unable to load shared library ‘libgdiplus’ or one of its dependencies

Dependencies 🌱

So, after a quick google the following was suggested to me:

mono-libgdiplus

brew install mono-libgdiplus

I already had this installed but I re-installed just in case

That did not work so the next option available was to add a reference to a NuGet package that allows you to use System.Drawing on macOS

runtime.osx.10.10-x64.CoreCompat.System.Drawing

 Include="runtime.osx.10.10-x64.CoreCompat.System.Drawing" Version="5.8.64" />

And with that all was working again.

Success 🥳

Overview ☀

The very latest version of .NET Core was launched at .NET Conf.

It is the free, cross-platform and open-source developer platform from Microsoft which includes the latest versions of ASP.NET and C# among others.

I decided to wait until the upgrade was available in all the various package managers such as homebrew on macOS and apt-get on Ubuntu and chocolatey on Windows before I upgraded my projects.

This ensured that my operating systems were upgraded from .NET Core 3.1 to .NET Core 5.0 for me almost automatically.

This post will hopefully document the steps needed to upgrade an ASP.NET Core 3.1 Razor Pages project from ASP.NET Core 3.1 to ASP.NET Core 5.0.

The migrate from .NET Core 3.1 to 5.0 document over at Microsoft should help you as it did me.

But for those that want to know what I had change here goes:

Getting Started 🌱

The main change will be to the Target Framework property in the website’s .csproj file however, in my case I had to change it in my Directory.Build.Props file which covers all of the projects in my solution.

Directory.Build.Props:

- netcoreapp3.1
+ net5.0

Next up I had to make a change to prevent a new build error that cropped up in an extension method of mine, something I am sure worked fine under .NET Core 3.1:

HttpContextExtensions.cs:

public static T GetHeaderValueAs(this IHttpContextAccessor accessor, string headerName)
{
-   StringValues values;
+   StringValues values = default;

    if (accessor.HttpContext?.Request?.Headers?.TryGetValue(headerName, out values) ?? false)
    {
        var rawValues = values.ToString();

Then I needed to make a change to ensure that Visual Studio Code (Insiders) would debug my project properly.

.vscode/launch.json:

{
    "name": ".NET Core Launch (console)",
    "type": "coreclr",
    "request": "launch",
    "preLaunchTask": "build",
-   "program": "${workspaceRoot}/src/projectname/bin/Debug/netcoreapp3.1/projectname.dll",
+   "program": "${workspaceRoot}/src/projectname/bin/Debug/net5.0/projectname.dll",
    "args": [],
    "cwd": "${workspaceFolder}",
    "stopAtEntry": false,
    "console": "externalTerminal"
},

This particular project has the source code hosted at Bitbucket and my pipelines file needed the following change.

Bitbucket Pipelines is basically Atlassian’s version of Github Actions.

bitbucket-pipelines.yml:

- image: mcr.microsoft.com/dotnet/core/sdk:3.1
+ image: mcr.microsoft.com/dotnet/sdk:5.0
pipelines:
    default:
        - step:

A related change was that I needed to make a change to my Dockerfile so that it uses the latest .NET 5 SDK and runtime.

Dockerfile:

- FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
+ FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build

- FROM mcr.microsoft.com/dotnet/core/aspnet:3.1 AS runtime
+ FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS runtime

I then ran a tool called dotnet outdated which upgraded all my NuGet packages including the Microsoft Frameworks packages going from 3.1 to 5.0.

For example:

dotnet outdated:

dotnet tool install --global dotnet-outdated-tool
dotnet outdated -u

» web
  [.NETCoreApp,Version=v5.0]
  AWSSDK.S3                                          3.5.3.2       -> 3.5.4
  Microsoft.AspNetCore.Mvc.NewtonsoftJson            3.1.9         -> 5.0.0
  Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation  3.1.9         -> 5.0.0
  Microsoft.EntityFrameworkCore.Design               3.1.9         -> 5.0.0
  Microsoft.Extensions.Configuration.UserSecrets     3.1.9         -> 5.0.0
  Microsoft.VisualStudio.Web.CodeGeneration.Design   3.1.4         -> 5.0.0
  Microsoft.Web.LibraryManager.Build                 2.1.76        -> 2.1.113

This changed my website’s csproj file to use the correct nuget packages for .NET 5.

A much quicker way than doing it manually!

web.csproj:

- 
+ 

Deployments 🚀

And finally, one thing I forgot once I tried to deploy was that in my project, I use Visual Studio Publish Profiles to automatically deploy the site via MsBuild and I needed to change the Target Framework and Publish Framework versions before it would deploy correctly.

/Properties/PublishProfiles/deploy.pubxml

-    netcoreapp3.1
+    net5.0
-    netcoreapp3.1
+    net5.0
     false
     <_IsPortable>true

And with that I was done. A fairly large and complex application was ported over.

By all accounts .NET 5 has performance and allocation improvements all across the board so I am looking forward to seeing the results of all that hard work.

Success 🥳

Evolution and Updates 🔄

Since publishing this post, SeedFolder has evolved significantly! The tool now supports multiple project templates, cross-platform compatibility, and has been enhanced with the help of GitHub Copilot.

Read about the journey from a simple dotfile copier to a comprehensive project scaffolding tool in my follow-up post: Evolving SeedFolder with GitHub Copilot - From Personal Tool to Multi-Template System.

Overview ☀

I have now built my first .NET Core Global Tool!

A .NET Core Global Tool is special NuGet package that contains a console application that is installed globally on your machine.

It is installed in a default directory that is added to the PATH environment variable.

This means you can invoke the tool from any directory on the machine without specifying its location.

The Application 🌱

So, rather than the usual Hello World example to install as a global tool I wanted a tool that would be useful to me.

I wanted to build a tool that will create a folder prefixed with either a bespoke reference (in my case a Trello card number) or the current date in a YYYY-MM-DD format followed by a normal folder name.

The tool once it has created the folder will then also copy some dotfiles that I find useful in most projects over.

For example:

818_create-dotnet-tool

2020-09-29_create-dotnet-tool

It will also copy the following dotfiles over:

• .dockerignore
• .editorconfig
• .gitattributes
• .gitignore
• .prettierignore
• .prettierrc
• omnisharp.json

I won’t explain how this code was written; you can view the source code over at GitHub to understand how this was done.

The important thing to note is that the application is a standard .NET Core console application that you can create as follows:

dotnet new console -n solrevdev.seedfolder

Metadata 📖

What sets a standard .NET Core console application and a global tool apart is some important metadata in the `.csproj` file.

 Sdk="Microsoft.NET.Sdk">
  
    Exe
    netcoreapp3.1

    true
    seedfolder
    ./nupkg
    true
    1.0.0

    
    A nice description of your tool
    A nice description of your tool
    your github username
    your github username
    https://github.com/username/projectname
    https://github.com/username/projectname
    https://github.com/username/projectname
    MIT
    git
    dotnetcore;;dotnet;csharp;dotnet-global-tool;dotnet-global-tools;
  

The extra tags from PackAsTool to Version are required fields while the Title to PackageTags are useful to help describe the package in NuGet and help get it discovered.

Packaging and Installation ⚙

Once I was happy that my console application was working the next step was to create a NuGet package by running the dotnet pack command:

dotnet pack

This produces a nupkg package. This nupkg NuGet package is what the .NET Core CLI uses to install the global tool.

So, to package and install locally without publishing to NuGet which will be needed while you are still testing you need the following:

dotnet pack
dotnet tool install --global --add-source ./nupkg solrevdev.seedfolder

Your tool should now be in your path accessible from any folder.

You call your tool whatever was in the ToolCommandName property in your .csproj file

seedfolder

You may find you need uninstall and install while you debug.

To uninstall you need to do as follows:

dotnet tool uninstall -g solrevdev.seedfolder

Once you are happy with your tool and you have installed in globally and tested it you can now publish this to NuGet.

Publish to NuGet 🚀

Head over to NuGet and create an API Key

Once you have this key go to your GitHub Project and under settings and secrets create a new secret named NUGET_API_KEY with the value you just created over at NuGet.

Finally create a new workflow like the one below which will check out the code, build and package the .NET Core console application as a NuGet package then using the API key we just created we will automatically publish the tool to NuGet.

Each time you commit do not forget to bump the version tag e.g. 1.0.0

name: CI

on:
    push:
        branches:
            - master
            - release/*
    pull_request:
        branches:
            - master
            - release/*

jobs:
    build:
        runs-on: windows-latest

        steps:
            - name: checkout code
              uses: actions/checkout@v2

            - name: setup .net core sdk
              uses: actions/setup-dotnet@v1
              with:
                  dotnet-version:  '3.1.x' # SDK Version to use; x will use the latest version of the 3.1 channel

            - name: dotnet build
              run: dotnet build solrevdev.seedfolder.sln --configuration Release

            - name: dotnet pack
              run: dotnet pack solrevdev.seedfolder.sln -c Release --no-build --include-source --include-symbols

            - name: setup nuget
              if: github.event_name == 'push' && github.ref == 'refs/heads/master'
              uses: NuGet/setup-nuget@v1.0.2
              with:
                  nuget-version: latest

            - name: Publish NuGet
              uses: rohith/publish-nuget@v2.1.1
              with:
                PROJECT_FILE_PATH: src/solrevdev.seedfolder.csproj # Relative to repository root
                NUGET_KEY: $ # nuget.org API key
                PACKAGE_NAME: solrevdev.seedfolder

Find More 🔍

Now that you have built and published a .NET Core Global Tool you may wish to find some others for inspiration.

Search the NuGet website by using the “.NET tool” package type filter or see the list of tools in the natemcmaster/dotnet-tools GitHub repository.

Success! 🎉

All of a sudden spotlight on my macOS Mojave macmini stopped working…

There is a process called mdutil which manages the metadata stores used by Spotlight and was the culprit for my issue.

The fix after some Google Fu and some trial and error was to restart this process as follows:

sudo mdutil -a -i off  
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist  
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist  
sudo mdutil -a -i on

Hopefully this won’t happen too often but if it does at least I have a fix!

Success? 🎉

Every time apt-get upgrade upgrades my local MySQL instance on my Ubuntu laptop I get the following error:

(1698, "Access denied for user 'root'@'localhost'")

The fix each time is the following, so here it is for me next time save me wasting time googling the error every time.

sudo mysql -u root

use mysql;

update user set plugin='mysql_native_password' where User='root';

flush privileges;

And with that all is well again!

Success? 🎉

Last night I decided to pull the trigger and upgrade from Ubuntu 19.10 (Eoan Ermine) to Ubuntu Focal Fossa 20.04

A fairly smooth upgrade all in all.

I did have to re-enable the .NET Core APT repository using the following command:

sudo apt-add-repository https://packages.microsoft.com/ubuntu/20.04/prod

I also discovered a neat shortcut to move programs from one workspace to another:

Ctrl+Alt+Shift+Arrow key

I hope this will soon become muscle memory 💪 !

Success 🎉

Background

What do you do when you have a website that you do not want Google or other search engines to index and therefore NOT display in search results?

Robots! 🤖

In the past, you have simply been able to add a robots.txt file.

This is a file that website owners could use to inform web crawlers and robots such as the Googlebot about whether you wanted your site indexed or not and if so which parts of your site.

If you wanted to stop all robots from indexing your site you created a file called robots.txt in your site root with the following content

While still used, it is no longer the recommended way to block or remove a URL or site from Google.

Google’s Removal Tool ✂

Your first step should be to head over to the Google Search Removal Tool and enter your page or site into the tool and submit.

For more information you can read about it here.

Doing this will remove your page or site for up to 6 months.

Meta Tags 📓

To permanently remove it you will need to tell Google not to index your page using the robots meta tag.

You add this into any page that you do not want Google to index.

 name="robots" content="noindex">

For example:

     name="robots" content="noindex" />
    


You do not want Google to index this page

Inspect 🔎

Once you have removed your page or site using the removal tool and used meta tags to stop it being indexed again in the future you will want to keep an eye on your domain and inspect the page(s) or site you removed.

To view your pending removals login to the Google Search Console and choose the Removals tab.

From here you can submit new pages for removal and generally inspect your website and how it is managed by Google’s index.

Summary

To recap, when you want to remove a page or site from Google search index you need to…

• Use the Google Search Removal Tool to remove temporarily.
• Permanently remove using robots meta tag

Hope this helps others or me from the future!

Success 🎉

Background

Today I wanted to clean up my Pocket account, I had thousands of unread articles in my inbox and while their web interface allows you to bulk edit your bookmarks it would have taken days to archive all of them that way.

So, instead of spending days to do this, I used their API and ran a quick and dirty script to archive bookmarks going back to 2016!

Here be dragons!

Now, since I ran this script I found a handy dandy page that would have done the job for me although instead of archiving all my bookmarks it would have deleted them so I am pleased I used my script instead.

If you want to clear your Pocket account without deleting your account head over to this page:

https://getpocket.com/privacy_clear

To be clear this will delete ALL your bookmarks and there is no going back

So, If like me you want to archive all your content carry on reading

Onwards!

To follow along you will need Visual Studio Code and a marketplace plugin called Rest Client which allows you to interact with API’s nicely.

I will not be using it to its full potential as it supports variables and such like so I will leave that for an exercise for the reader to refactor away.

So, to get started create a working folder, 2 files to work with and then open Visual Studio Code

mkdir pocket-api
cd pocket-api
touch api.http
touch api.js
code .

Step 1: Obtain a Pocket platform consumer key

Create a new application over at https://getpocket.com/developer/apps/new and make sure you select all of the Add/Modify/Retrieve permissions and choose Web as the platform.

Make a note of the consumer_key that is created.

You can also find it over at https://getpocket.com/developer/apps/

Step 2: Obtain a request token

To begin the Pocket authorization process, our script must obtain a request token from Pocket by making a POST request.

So in api.http enter the following

### Step 2: Obtain a request token
POST https://getpocket.com/v3/oauth/request HTTP/1.1
Content-Type: application/json; charset=UTF-8
X-Accept: application/json

{
    "consumer_key":"11111-1111111111111111111111",
    "redirect_uri":"https://solrevdev.com"
}

This redirect_uri does not matter. You can enter anything here.

Using the Rest Client Send Request feature you can make the request and get the response in the right-hand pane.

You will get a response that gives you a code that you need for the next step so make sure you make a note of it

{
  code:'111111-1111-1111-1111-111111'
}

Step 3: Redirect user to Pocket to continue authorization

Take your code and redirect_url from Step 2 above and replace in the URL below and copy and paste the below URL in to a browser and follow the instructions.

https://getpocket.com/auth/authorize?request_token=111111-1111-1111-1111-111111&redirect_uri=https://solrevdev.com

Step 4: Receive the callback from Pocket

Pocket will redirect you to the redirect_url you entered in step 3 above.

This step authorizes the application giving it the add/modify/delete permissions we asked for in step 1.

Step 5: Convert a request token into a Pocket access token

Now that you have given your application the permissions it needs you can now get an access_token to make further requests.

Enter the following into api.http replacing consumer_key and code from Steps 1 and 2 above.

POST https://getpocket.com/v3/oauth/authorize HTTP/1.1
Content-Type: application/json; charset=UTF-8
X-Accept: application/json

{
    "consumer_key":"11111-1111111111111111111111",
    "code":"111111-1111-1111-1111-111111"
}

Again, using the fantastic Rest Client send the request and make a note of the access_token in the response

{
  "access_token": "111111-1111-1111-1111-111111",
  "username": "solrevdev"
}

Make some requests

Now we have an access_token we can make some requests against our account, take a look at the documentation for more information on what can be done with the API

We can view all pockets:

### get all pockets
POST https://getpocket.com/v3/get HTTP/1.1
Content-Type: application/json; charset=UTF-8
X-Accept: application/json

{
    "consumer_key":"1111-1111111111111111111111111",
    "access_token":"111111-1111-1111-1111-111111",
    "count":"100",
    "detailType":"simple",
    "state": "unread"
}

We can modify pockets:

### modify  pockets
POST https://getpocket.com/v3/send HTTP/1.1
Content-Type: application/json; charset=UTF-8
X-Accept: application/json

{
    "consumer_key":"1111-1111111111111111111111111",
    "access_token":"111111-1111-1111-1111-111111",
    "actions" : [
                    {
                        "action": "archive",
                        "item_id": "82500974"
                    }
                ]
}

Generate Code Snippet

I used the Generate Code Snippet feature of the Rest Client Extension to get me some boilerplate code which I extended to loop until I had no more bookmarks left archiving them in batches of 100.

To do this once you’ve sent a request as above, use shortcut Ctrl+Alt+C or Cmd+Alt+C for macOS, or right-click in the editor and then select Generate Code Snippet in the menu, or press F1 and then select/type Rest Client: Generate Code Snippet.

It will show the available languages.

Select JavaScript then select enter and your code will appear in a right-hand pane.

Below is that code slightly modified to iterate all unread items then archive them until all complete.

You will need to replace consumer_key and access_token for the values you noted earlier.

let keepGoing = true;

while (keepGoing) {
    let response = await fetch('https://getpocket.com/v3/get', {
        method: 'POST',
        headers: {
            'content-type': 'application/json; charset=UTF-8',
            'x-accept': 'application/json'
        },
        body:
            '{"consumer_key":"1111-1111111111111111111111111","access_token":"111111-1111-1111-1111-111111","count":"100","detailType":"simple","state": "unread"}'
    });

    let json = await response.json();
    //console.log('json', json);

    let list = json.list;
    //console.log('list', list);

    let actions = [];

    for (let index = 0; index < Object.keys(list).length; index++) {
        let current = Object.keys(list)[index];

        let action = {
            action: 'archive',
            item_id: current
        };
        actions.push(action);
    }

    //console.log('actions', actions);

    let body =
        '{"consumer_key":"1111-1111111111111111111111111","access_token":"111111-1111-1111-1111-111111","actions" : ' +
        JSON.stringify(actions) +
        '}';

    //console.log('body', body);

    let response = await fetch('https://getpocket.com/v3/send', {
        method: 'POST',
        headers: {
            'content-type': 'application/json; charset=UTF-8',
            'x-accept': 'application/json'
        },
        body: body
    });

    let json = await response.json();

    console.log('http post json', json);

    let status = json.status;

    if (status !== 1) {
        console.log('done');
        keepGoing = false;
    } else {
        console.log('more items to process');
    }
}

Run in Chrome’s console window

And so the quick and dirty solution for me was to copy the above JavaScript and in a Chrome console window paste and run.

It took a while as I had content going back to 2016 but once it was finished I had a nice clean inbox again!

Success 🎉

Background

So, I have a small ASP.NET Core Razor Pages application that I recently enhanced by adding Vue in the same way that I once would add jQuery to an existing application to add some interactivity to an existing page.

Not all websites need to be SPA’s with full-on JavaScript frameworks and build processes and just like with jQuery back in the day I was able to add Vue by simply adding a exclude="Development">