What is agency? In philosophy, agency refers to the capacity to act and make choices in an environment based on goals and beliefs. It’s not blind obedience – it’s the ability to initiate action and adapt, to decide between alternatives in order to achieve a goal (this is a VERY condensed and simplistic definition, there are many nuances and discussions in this area. Go down the rabbit hole… interesting stuff).

When you give an agent instructions, you’re defining goals, guidance, and tools it can use to achieve those goals. But an agent with agency can deviate if it believes a different approach better serves those goals or adapts better to the environment and can interpret the goal in different ways which don’t exactly align with your expectations.

This is how we behave too. A surgeon ignores a checklist if something unexpected appears. A good employee uses judgment. We call this intelligence and respect it. Yet when agents do it, we’re frustrated. Your agent might just be exercising the very capability that makes it useful, and that is what makes it so powerful.

There are times when agency is a liability. If you need guaranteed, deterministic behavior – where the process must follow a specific sequence every time – don’t rely on instructions. Give the agent tools that enforce the process.

A very simple example: if content must be appended to the end of a file and never edited elsewhere, don’t give the agent an “edit file” tool with instructions to append. Give it an “append to file” tool that can only do one thing. This is more work: you’re building specific tools instead of general ones. But if consistency is non-negotiable, this is how you achieve it. The constraint is moved from the agent’s judgment into the tool’s design.

The next time your agent does something unexpected, ask: is it broken, or is it exercising agency? If it’s pursuing a goal in a way that makes sense given the context, it’s working correctly. The solution isn’t to remove agency – it’s to better communicate your goals and refine your constraints. Your agents work best when you recognize and leverage their capacity to choose, adapt, and act.

But sometimes you agent it is broken, because agents and LLMs are emergent technologies that are evolving at an incredible pace, and this pace sometimes makes them unstable and unpredictable. So also keep this in mind.

I’ve been exploring AI-assisted coding tools and methodologies, and stumbled upon Spec Kit, a toolkit for spec-driven development using AI agents. The idea is that for every feature you want to implement, you go through a specification → planning → tasking → implementation workflow fully supported by the AI agent (read more). As an ex-Product Manager (and a geek for software development methodologies), I loved this idea and was eager to use it.

AI agent shine in this process because they can create extremely detailed specifications that are mostly consistent as the project grows. I’ve seen projects grow and maintaining specs without contradictions can be challenging – but AI agents do this very well. They still miss things, but humans also miss things. And if I ask the AI agent enough questions, and use separate agents to do the validations, the AI agent has the upper hand here.

So, for the past two months, in between meetings and for an hour here and there, I’ve specified, tested, and reviewed the work of the AI agent towards creating the first part of my project – a working backgammon web application and playing server. No manual coding allowed.

GitHub Copilot has advanced rapidly since I last tried it, so I decided to use all the time, with the “Auto” model. I chose this simply because I believe AI should simplify my decisions, not add more. And since it is my default at work, I also made it my default here.

This is what I’ve learned this time around:

• Roughly 60%-70% of the time was spent doing manual validations. Give the AI agent testing tools, and even better, let it generate them. The percentage of time won’t be reduced, but total time will be.
• Follow-up on the first point, the most critical code to review is testing code. And by “tests” I mean anything that the AI agent can use after each coding session to validate their own work – unit, component, E2E tests, etc. For web apps, tools like playwright (or similar) are a must.
• Many people have written already, but I will repeat it: keep the context small. Large contexts confuse AI agents.
• Use source control (this should be obvious). You will have long conversations with the AI agent doing changes in the middle (because we get carried away), which is bad (see previous point), generating code that you will have to throw away. So make sure you always commit your latest working product.
• Customize your AI agent with instructions and prompts. There are many sources for great instructions in GitHub. I’ve used cline/prompts and github/awesome-copilot for inspiration. The two instructions that I can’t do without are thought logging and self-improvement. They are great to help the AI agent know why things were done in the past.

The AI agent also had a funny (and frustrating) behavior. In one instruction, it was told to maintain a chronological changelog. It rebelled: sometimes it would add the changes at the top, sometimes at the bottom, sometimes it will update previous changes (!!!). Tweaked instructions, tested with different models – kept on happening. Not always, but sometimes. Go figure.

Third time’s the charm: this attempt was much more successful than the previous two, and I now have a working backgammon application that actually plays by the rules (most of the time). The next step of the project is creating the backgammon playing agent, which I’m sure will be very fun. So stay tuned :-).

Let me explain.

The Failure

First the failure – the project is almost in the same place it was a week ago. The agents and I started working on a small UI interaction where the user selected (clicked) a checker with a valid move on the board, which should have de-highlighted the other checkers with available moves and changed the highlight of the selected checker. Simple, right?

We had a board. We had checkers. We had dice. The player could roll the dice and after this the checkers with valid moves were highlighted. All this was implemented by the AI Agent with multiple prompts, instructions, and a detailed description of the game of backgammon. Things were going well.

And then we got stuck. No matter how much detail I added to the prompts or how many tests we added, the agent was unable to implement the interaction.

That is when I decided to take a look under the hood and see if there is anything I can do to help. Until now I let the AI run without looking at the code in depth, just a look here and there, not really digging into the code as I would in a PR at work.

Boy, what a mess! Variables named i, j, k, s; Unused variables and methods all over the place; And then came the worst part – the AI Agent had implemented the game model and logic in two different places – once in the UI and the second in the model – and each implementation was being used by a different part of the application.

Tried doing some manual “intervention” to salvage the project, but the code was so bad that this will require a lot of work and beats the whole point. I’m thinking of throwing out all game logic implementation and leaving only the UI which looks good enough (much better than if I would have written it, even if I knew how to write it. I’m really bad at UI). We’ll see.

Great Success – Lessons Leaned

Now let’s talk about the great success. I’ve learned TONS during this process:

1. My prompt writing capabilities have improved tremendously! I’m also learning new workflows to create the prompts, like asking another AI Agent to write a prompt and having long conversations with the AI Agent before starting implementation to make sure the Agent understand what I want it to do.
2. It is VERY important to set up the project basics before writing the first line of code: architectural decisions, languages, frameworks, test frameworks, CI pipelines, code conventions, etc. And, obviously, these can be done with the help of AI Agents.
3. Similar to (2), a good set of system prompts is a MUST HAVE for the AI Agent to perform correctly. This prompt (or many prompts) provides instructions that are given at the start of every session, explaining it how plan the task, system design guidelines, and general information for the AI agent that are relevant for all tasks. There are a number of repos with sample for this – awesome-ai-system-promts stands out with many start (3.5K at the moment), and kind mention also to my past co-worker who pointed me in this direction and also maintains his own PromptEngineering repo.
4. My TypeScript and HTML/CSS reading abilities are much better than they were 1 week ago :-).

Last Thoughts

I’ve heard many people saying that AI Agents are like junior developers. This comparison does a disservice to the junior developers (and all developers in general). Humans are constantly learning, adapting, and improving through experience and feedback. In contrast, AI agents operate on static models that aren’t retrained after each task. Having memory banks and self-improvement helps but doesn’t mitigate the issue.

Most developers I’ve worked with don’t repeat the same mistake five times without progress. When I offer feedback, they internalize it and apply it moving forward. With AI agents, replicating that kind of learning is still tedious, imprecise, and resource-intensive.

Despite the frustrations and setbacks, this “experiment” with AI agents has been awesome. My vacation just ended so I’ll have less time to experiment with this personal project, but I’m definitely going to apply all the learnings to my daily work and see how it goes.

But don’t worry, the journey continues…

Recently, there’s been a surge of enthusiasm around the idea that anyone can build an application quickly using AI coding agents. I played a bit with base44 and the results are impressive! Curious to test this narrative myself without intermediaries, I decided to explore the capabilities of these tools in a more “personal” setting.

I’m now on vacation, so I’ve taken on a side project: recreating an AI-driven backgammon player, something I did many years ago (yes, this is what I like to do on vacations, outside of going to the beach, drinking margaritas, doing treks, and other stuff). This time, however, I’m relying entirely on AI agents for the implementation. I’m calling this approach “AI Coding”, a term I prefer over the more ambiguous “vibe coding.” In this experiment, I’m responsible for product specification and high-level architecture, while the AI selects the programming languages and frameworks. I can read most popular languages, so if the agent does really dumb stuff (and it does sometimes), I can fix them. Otherwise, I let it proceed autonomously.

Over the past two days, I’ve spent about two hours per day on this project. One of the first things I noticed is how different the time-on-task feels compared to traditional coding. When I write code myself, I usually have a clear sense of the scope and duration of each task. With AI Coding, this predictability disappears. Tasks that seem trivial, like changing the background color of a rectangle, can take multiple iterations. At the same time, more complex tasks, such as animating a pair of dice and triggering a roll on user interaction, are completed correctly in a single attempt. Still trying to understand why.

Another key insight is the importance of writing good prompts (as many people have written already). Instructions must be very specific, which sometimes make them very long and tedious. But vague or overly complex prompts often lead to partial or wrong implementations, misinterpretations, or complete failures. This unpredictability can be frustrating.

I’m using both GitHub Copilot and Cline, switching between them when one or the other gets stuck and can’t complete the task. It’s very important to configure these tools correctly. However, maintaining consistent global settings across the tools is not straightforward. I’m still refining my workflow, and the learning process has been enjoyable.

At times, AI coding feels like doomscrolling. You write a prompt, the agent responds with a working solution—great! Then the next prompt breaks everything. You revise it, and things get worse. You revert, try again, and slowly inch toward a solution. What should have taken two minutes ends up consuming half an hour.

Am I using the wrong tools? I don’t think so. Many developers report success with the same platforms. Am I using them incorrectly? Possibly. I’ve already seen noticeable improvements in my workflow after just a few hours of focused use. Time will tell – I’ve been doing this for a relatively short time, and I think I’m getting the hang of it. But there is still a lot to learn.

Final thoughts: AI-assisted software development is not magic, but it is powerful. It requires a shift in mindset and a willingness to experiment. With the right approach, I’m sure it can become a great tool, as others have demonstrated.

The journey continues…

The simplest way to do this is to deploy to Azure Container Apps. To do this, we need to install the [Azure Developer CLI (azd)](https://learn.microsoft.com/en-us/azure/developer/azure-developer-cli/). Ready? Let’s go!

First, initialize the azure development environment for the project:

> azd init

This commands scans the directory where it runs for instances of aspire app hosts. Detecting the one we have, it asks if we want to continue:

Initializing an app to run on Azure (azd init)

? How do you want to initialize your app? Use code in the current directory

  (✓) Done: Scanning app code in current directory

Detected services:

  .NET (Aspire)
  Detected in: {redacted}\Part3-DeploySimpleWebApp\src\SimpleApp-AppHost\SimpleApp-AppHost.csproj    

azd will generate the files necessary to host your app on Azure.
? Select an option  [Use arrows to move, type to filter]
> Confirm and continue initializing my app
  Cancel and exit  

I select to continue. Now I’m asked for a unique name for the environment. This affects a couple of things:

1. the name of the resource group that is created in Azure.
2. The unique suffix that is given to all resources (using a hash).
3. The text on the tag(s) that is added to all resource groups used by the environment.
4. Maybe something else that is not documented and I haven’t noticed?

Anyway, choose wisely. I chose Vainolo-Aspire-Part3:

? Enter a unique environment name: Vainolo-Aspire-Part3

Generating files to run your app on Azure:

  (✓) Done: Generating ./azure.yaml
  (✓) Done: Generating ./next-steps.md

SUCCESS: Your app is ready for the cloud!
You can provision and deploy your app to Azure by running the azd up command in this
directory. For more information on configuring your app, see ./next-steps.md

After the project has been configured, we can deploy the app to azure in one command:

> azd up

I’m asked to enter the subscription and location for the deployment. The tool asks this only the first time it runs, storing the selections locally:

? Select an Azure Subscription to use:  [Use arrows to move, type to filter]
>  1. {redacted} ({redacted})

? Enter a value for the 'location' infrastructure parameter:  [Use arrows to move, type to filter]
  53. (US) West US (westus)
  54. (US) West US 2 (westus2)
> 55. (US) West US 3 (westus3)

Here we go!

Packaging services (azd package)


Provisioning Azure resources (azd provision)
Provisioning Azure resources can take some time.

Subscription: {redacted} ({redacted})
Location: West US 3

  You can view detailed progress in the Azure Portal:
  https://{redacted}

  (✓) Done: Resource group: rg-Vainolo-Aspire-Part3 (3.467s)
  (✓) Done: Container Registry: acrz44hwzvck46as (15.744s)
  (✓) Done: Log Analytics workspace: law-z44hwzvck46as (19.271s)
  (✓) Done: Container Apps Environment: cae-z44hwzvck46as (2m16.714s)

Deploying services (azd deploy)

  (x) Failed: Deploying service Web1

ERROR: error executing step command 'deploy --all': failed deploying service 'Web1': updating container app service: applying manifest: PUT https://{redacted}
--------------------------------------------------------------------------------
RESPONSE 400: 400 Bad Request
ERROR CODE: ContainerAppInvalidName
--------------------------------------------------------------------------------
{
  "error": {
    "code": "ContainerAppInvalidName",
    "message": "Invalid ContainerApp name 'Web1'. A name must consist of lower case alphanumeric characters or '-', start with an alphabetic character, and end with an alphanumeric character and cannot have '--'. The length must be between 2 and 32 characters inclusive."
  }
}
--------------------------------------------------------------------------------

TraceID: 5459bdbc77f6a12c75cd588bd0de35a5

I have a confession to make – fixing this took me waaaaay longer than it should have. It was not clear which instance of `Web1` was causing the issue, and I was sure it was related to the `SimpleApp-Web1` project name. I was so convinced that I forgot `Web1` was the name I gave the application in the host code 🤦‍♂️🤦‍♂️🤦‍♂️.

Changing Web1 to web1 in the Program.cs file of the SimpleApp-AppHost fixed the issue 👍. I though about adding validation in azd, but alas, the tools is written in Go (☹️ why???). Maybe another time… Anyway, here, we go again!

Packaging services (azd package)


Provisioning Azure resources (azd provision)
Provisioning Azure resources can take some time.

Subscription: {redacted} ({redacted})
Location: West US 3

  (-) Skipped: Didn't find new changes.

Deploying services (azd deploy)

  (✓) Done: Deploying service web1
  - Endpoint: https://web1.{redacted}.westus3.azurecontainerapps.io/

  Aspire Dashboard: https://aspire-dashboard.ext.{redacted}.westus3.azurecontainerapps.io

SUCCESS: Your up workflow to provision and deploy to Azure completed in 45 seconds.

Dashboard is up and running:

And the app also works:

Now for a very important part of this tutorial: removing the test app. Cloud resources can be
pretty pricey and usage is charged by the second. The Aspire team did this the right way, with a single command to remove the whole environment:

> azd down

Deleting all resources and deployed code on Azure (azd down)
Local application code is not deleted when running 'azd down'.

  Resource(s) to be deleted:

  Resource Group: rg-Vainolo-Aspire-Part3
    • Log Analytics workspace: law-z44hwzvck46as
    • Container Registry: acrz44hwzvck46as
    • Container Apps Environment: cae-z44hwzvck46as
    • Container App: web1

? Total resources to delete: 6, are you sure you want to continue? Yes
Deleting your resources can take some time.e you want to continue? (y/N) y

  (✓) Done: Deleted resource group rg-Vainolo-Aspire-Part3


SUCCESS: Your application was removed from Azure in 18 minutes 4 seconds.

Cool 😎.

Next time, a drill down into the deployment process, what is created, and how it can be changed. Or maybe something else. Time will tell.

As always, the code for this tutorial (and all other tutorials) can be found on my GitHub. Until next time, happy coding!

First, we create a new Aspire AppHost:

> dotnet new aspire-apphost -n SimpleApp-AppHost

The AppHost is the manager / orchestrator of the distributed application that we are building using the Aspire framework. Since it is an executable application, we can run it as soon as it is created. It will not do much, but does run:

> cd SimpleApp-AppHost<br>> dotnet run<br>Using launch settings from <redacted>\src\SimpleApp-AppHost\Properties\launchSettings.json...<br>Building...<br>info: Aspire.Hosting.DistributedApplication[0]<br>      Aspire version: 8.2.2+5fa9337a84a52e9bd185d04d156eccbdcf592f74<br>info: Aspire.Hosting.DistributedApplication[0]<br>      Distributed application starting.<br>info: Aspire.Hosting.DistributedApplication[0]<br>      Application host directory is: <redacted>\src\SimpleApp-AppHost<br>info: Aspire.Hosting.DistributedApplication[0]<br>      Now listening on: https://localhost:17114<br>info: Aspire.Hosting.DistributedApplication[0]<br>      Login to the dashboard at https://localhost:17114/login?t=f3f0cf47ebc34c01d5214c2eb0d5cd18<br>info: Aspire.Hosting.DistributedApplication[0]<br>      Distributed application started. Press Ctrl+C to shut down.

We can navigate to the dashboard, which is completely empty. But for me, working things are comforting, so this is good :-).

Turns out that adding a new application is not complicated at all. First thing that we need is create the service defaults project. This project defines the shared settings and configurations for the applications that run with the same host:

> dotnet new aspire-servicedefaults -n SimpleApp-ServiceDefaults

We will also create our web application:

> dotnet new web -n SimpleApp-Web1

There are a couple of “wires” that must be connected for these projects (settings, host, app) to work together. Applications that run with the host must reference the same service defaults project. The host needs to reference the applications. First, we’ll add a reference from the web app to the service defaults project:

> dotnet add .\SimpleApp-Web1\SimpleApp-Web1.csproj reference .\SimpleApp-ServiceDefaults\SimpleApp-ServiceDefaults.csproj

And then a reference from the host to the web app project:

> dotnet add .\SimpleApp-AppHost\SimpleApp-AppHost.csproj reference .\SimpleApp-Web1\SimpleApp-Web1.csproj

Two small code changes are needed to finish the job. First – add the defaults configuration to the web app for it to run on the Aspire host. This is done in the `Program.cs` file of the web app just after creating the builder:

var builder = WebApplication.CreateBuilder(args);
builder.AddServiceDefaults();

Finally the app project is added to the host builder so the host executes it. This is done in the `Program.cs` file of the app host project after creating the builder (promise next time to give better names to these files):

var builder = DistributedApplication.CreateBuilder(args);
builder.AddProject<Projects.SimpleApp_Web1>("Web1").WithExternalHttpEndpoints();

If you read this change carefully, you’ll notice that the name of the project is `SimpleApp_Web1` and not `SimpleApp-Web1`. This is because `C#` identifiers (and pretty sure most programming languages) don’t allow `-` as an identifier. Something to take into consideration when naming projects in the future.

Let’s run the host to see the results.

> dotnet run --project .\SimpleApp-AppHost\SimpleApp-AppHost.csproj
Using launch settings from .\SimpleApp-AppHost\Properties\launchSettings.json...
Building...
info: Aspire.Hosting.DistributedApplication[0]
      Aspire version: 8.2.2+5fa9337a84a52e9bd185d04d156eccbdcf592f74
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application starting.
info: Aspire.Hosting.DistributedApplication[0]
      Application host directory is: <redacted>\src\SimpleApp-AppHost
info: Aspire.Hosting.DistributedApplication[0]
      Now listening on: https://localhost:17114
info: Aspire.Hosting.DistributedApplication[0]
      Login to the dashboard at https://localhost:17114/login?t=6e00479dd713c387209238f98db39b32
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application started. Press Ctrl+C to shut down.

We can navigate to the dashboard, and we see that the app shows up:

Last check, click on the link to the app… Hello World!

Thats all I have for today. The process was straightforward, which encourages me to continue investigating Aspire. Next time, I’m going to learn how to deploy the application to Azure. And from there, who know where the path will take me.

As always, you can find the code for this tutorial on my GitHub repo.

Until next time, happy coding!

I’m using Microsoft Learn, and the official documentation as my baseline, expanding and exploring as I see fit. Hope you enjoy the ride :-).

Let’s start by creating a new .NET aspire by executing:

> dotnet new aspire-starter -n MyFirstAspireApp

I’m using the -n flag to give the project a name, otherwise it takes the name of the directory, which in this case is quite ugly.

This command creates quite a lot of code:

1. MyFirstAspireApp.AppHost: the “orchestration” project that.. orchestrates stuff? I’m sure we’ll learn more about this later.
2. MyFirstAspireApp.ServiceDefaults: the project that contains the configuration for all the applications.
3. MyFirstAspireApp.ApiService: a web api that exposes a service to query weather data.
4. MyFirstAspireApp.Web: a Blazore WebAssembly application that is the UI for a weather application.

Let’s see this run:

> cd MyFirstAspireApp.AppHost
> dotnet run

Since the AppHost project is dependent on the other projects, this builds everything and runs the application. In the console, we can see some traces and also information on how to login to the application dashboard:

info: Aspire.Hosting.DistributedApplication[0]
      Aspire version: 8.2.2+5fa9337a84a52e9bd185d04d156eccbdcf592f74
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application starting.
info: Aspire.Hosting.DistributedApplication[0]
      Application host directory is: <redacted>\learning-dotnet-aspire>\Part1-TheBasics\MyFirstAspireApp.AppHost
info: Aspire.Hosting.DistributedApplication[0]
      Now listening on: https://localhost:17299
info: Aspire.Hosting.DistributedApplication[0]
      Login to the dashboard at https://localhost:17299/login?t=c8cd13362afa4b22cc49b897792d9a4f
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application started. Press Ctrl+C to shut down.

Navigating to the login dashboard we get a very nice page where we can see a lot of information:

I think a full tutorial is needed only for this dashboard. For now, I’ll click on the URL of the webfrontend resource to navigate to the web app that was created.

The app has a counter which can be incremented and a weather page that shows data fetched from the weather API (also in the project).

To get my hands dirty, I’m going to change the App so the Summary of the weather is related to the temperature, and not random (I’m getting -10 C – Warm, which doesn’t make sense). The code for the weather API is in the Program.cs file in the ApiService project. I’m going to replace this code:

var summaries = new[]
{
    "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
};

app.MapGet("/weatherforecast", () =>
{
    var forecast = Enumerable.Range(1, 5).Select(index =>
        new WeatherForecast
        (
            DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
            Random.Shared.Next(-20, 55),
            summaries[Random.Shared.Next(summaries.Length)]
        ))
        .ToArray();
    return forecast;
});

With this code:

string Summary(int forecast) => forecast switch
{
    <= 0            => "Freezing",
    > 0 and <= 10   => "Cool",
    > 10 and <= 20  => "Mild",
    > 20 and <= 30  => "Warm",
    > 30            => "Scorching"
};

WeatherForecast GenerateForecast(int index)
{
    var temperature = Random.Shared.Next(-20, 55);
    return new
    (
        DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
        temperature,
        Summary(temperature)
    );
}

app.MapGet("/weatherforecast", () =>
{
    var forecast = Enumerable.Range(1, 5).Select(index => GenerateForecast(index)).ToArray();
    return forecast;
});

Restarting the app, and there we go – the summary now makes sense 🎉.

This is enough for today. There is a LOT to cover going forward. I’m going to try and take it step by step, understand all the components that make up this huge beast called Aspire.

As always, the code for this tutorial can be found on Github.

Happy Coding!

Anyway, let’s get back to what I want to share today. I manage my expenses using excel, and I have some credit cards for internet purchases that charge in a different currency than the one in which I do my account consolidations. Getting the exchange rate for each transaction was out of the question, so there had to be another option.

Enter the magic of Excel’s STOCKHISTORY function. While the function is built for stocks, we can use it to get exchange rates using the <source-currency>:<target-currency> as the name of the stock. For example, to get the exchange rate from USD to EUR, we use “USD:EUR”.

In its simplest form, the function receives two arguments – the stock and a date – and creates an array containing the matching values for the stock on the date. For example, to get the USD:EUR exchange rate for 2024-01-01, we enter the formula:

=STOCKHISTORY("USD:EUR", DATE(2024,1,1))

Which adds this data to the worksheet:

Good start. For my purpose, I want just one cell containing the exchange rate from the currency of the transaction to my base currency based on the date of the transaction that is also in this row. We can also do that by changing other parameters of the STOCKHISTORY function that lets us tweak what data to fetch and how to return it. First, to get only the exchange rate, we set the Headers argument to 0, which removes the headers:

=STOCKHISTORY("USD:EUR",DATE(2024,1,1),,,0)

Returning:

Almost there! I only want the value of the exchange rate, so we need a bit more tweaking. There are 5 “properties” that can be passed to the STOCKHISTORY function, which define what values it returns. Setting property0 to 1 will ensure that only the closing rate is returned:

=STOCKHISTORY("USD:EUR",DATE(2024,1,1),,,0,1)

Returning:

Great… But what happens when we try to get the exchange rate in a day where the market is not open? Even if Excel does not allow it, I do purchase things on Sundays. In these cases, the function will return #VALUE. For example, if we try to fetch the USD:EUR exchange for 2024-01-06, this is what we get:

What we can do here is fetch a range of dates for the exchange rate (from a start to an end date) and get the maximum from this range. Let’s do this in our example, fetching a range of 5 days and getting the maximum value:

=MAX(STOCKHISTORY("USD:EUR",DATE(2024,1,6)-2,DATE(2024,1,6),,0,1))

Which returns:

Excel is awesome .

First, we start with a C# class library project, which we can create by running dotnet new classlib on the console. This will create a new project that has the name of the directory where the command runs. Many times, this is not what we want so we’ll either create a directory with the name of the project or use the --name flag to give our project a name (which creates this directory). In this case I’m going to use dotnet new project or --name MyFirstNuGet which creates a MyFirstNuGet directory containing two files: Class1.cs and MyFirstNuGet.csproj.

At this point, we are ready to create the package, by running dotnet pack. This creates a NuGet package that takes the name of the project for author and package identifier (a unique identifier for all packages, which is also used to reference the package using NuGet), and defaults to version 1.0.0.

We probably don’t want that, so let’s configure things a bit. NuGet properties are set in the csproj file inside a PropertyGroup (like any other MSBuild property). To me, the most important things we can set there are:

• PackageId: the identifier of the package, which should be different from all other packages in NuGet.org, otherwise we will not be able to publish it there. And giving it a “catchy” name may also make it more popular, so choose wisely .
• Version: a sematic versioning compliant version for the package being created.
• TargetFramework(s): a semicolon separated list of target frameworks that are supported by the package. This list can also have one element, and if you only have on element you can use TargetFramework.

Other than these two, we can add a list of Authors, License, Description, Copyright, and many others.

Let’s change these settings, run dotnet pack, and our package is ready!

As always, the (very small) code for this tutorial can be found in my GitHub repo.

I’m not going to repeat the official tutorial because it is easy to follow, and it works (which is not the case in many tutorials…).

Anyway, one small thing that I did add is a way to “see” the code that is generated. Why? Mainly because I like to navigate to the code in my editor. The default settings don’t generate a source file, but after some digging I found you can generate the source files by adding the <EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles> directive in the project, and voila, the code shows up. Hidden deep down in the compiler directories, but it is there:

You can check out the code for the generator and the program that uses the generator here: https://github.com/vainolo/Vainosamples/tree/master/CSharp/Generators/MyFirstGenerator.

Happy coding!