Tag: fyi

If you are using Aspire and EF core to manage the schema of your database, this documentation is a great starting place to make the two work together.

The core concept is that you add a worker service that is dedicated to running migrations, creating the initial database, and seeding data to the database. Essentially any operation that should be performed before the actual web app starts up. I implemented this in the blog this evening with the help of Claude Code while I watched Twin Peaks.

One prerequisite was that I had to move my DbContext and Entity classes to a shared library so that the web app and worker services could both access them. I had actually tried to do this when I first created the blog but ran into issues and decided to simplify the design. I first told Claude to separate out the database entities, migrations, and contexts to a separate project. I was surprised how long this actually took. But in the end, something like 20+ files were touched, but all tests passed and the changes looked good.

Next, I started a new chat with Claude (/new command), and gave it the same link provided in this post.

It then proceeded to one-shot the changes and everything just worked. Here are the full changes: https://github.com/david-jarman/link-blog/pull/7

I hate having to update package dependencies in projects. Fortunately there is a handy dotnet tool that will report and update packages that are out of date. I used this to update all the packages in the link-blog source code this evening and was pleasantly surprised it just worked. Only issue I found was that because I create a msbuild property to store the OpenTelemetry version (there are three OTel packages with the same version), the tool updated the PackageVersions directly instead of just updating the property. Not a big deal, and I would have been shocked if it was able to handle a corner case like that.

Now I need to see if I can get this to run as a daily CI task.

I just found that there is a new(ish) command for figuring out where a transitive dependency comes from in your dotnet project (starting with dotnet 8.0.4xx)

dotnet nuget why <PROJECT|SOLUTION> <PACKAGE>

If you have a dependency in your project that has a vulnerability, you can use this to figure out which package is bringing it in. For example, System.Net.Http 4.3.0 has a high severity vulnerability. I've found instances where this package is brought into my projects by other packages. It's very handy to be able to trace it with a built-in tool. Before this was available, I would use the dotnet-depends tool, which is a great tool, but a little clunkier than I'd like, and doesn't seem to support central package management.