Tag: dotnet

FYI: Tracking down transitive dependencies in .NET

dotnet nuget why - command reference

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
# / 2025 / 04 / 18

.NET Aspire 9.2

Release Notes

I'm always excited when I see a new .NET Aspire release. The 9.2 update has lots of small quality-of-life improvements. The most interesting new feature for me is "Automatic database creation support". This means that if you add a Postgres database, it will get automatically created, but the best part is that you can also provide a custom SQL script. This lets you customize the creation. I might use this to seed the database with some fake data, so I don't have to manually create data.

This project is showing really great promise. The team is actively listening to developer feedback and reacting to it quickly.
# / 2025 / 04 / 10

.NET Aspire 9.1 just dropped

Release Notes

I'm very excited about this release of .NET Aspire. It's an absolute game changer for me, specifically in doing dev work on this blog.

This release has a bunch of great stuff, but I'm actually only interested in the bug fix to this issue. I really love the `dotnet watch run` command, which will perform a hot reload of your application when you make changes to the source files. Before this bug fix, sockets would not be freed up in a timely manner if the process ends, meaning that on reload, it would try to rebind to the existing ports and fail. This meant my workflow was 1. make a change 2. kill the running process 3. wait 10-15 seconds 4. run dotnet run again. Sometimes, I would have to rinse and repeat 3 and 4, if I hadn't waited long enough.

Now, I run `dotnet watch run`, make changes to my code (.cs, .css, and .razor files), and all I have to do to see the new changes is refresh my browser page. It's like magic. My dev loop has gone from ~30 seconds to see the changes reflected in the browser to near-instantly (the time it takes me to press F5 in Safari).

I've been very happy with .NET Aspire so far. But because I deploy to Heroku and not Azure, I can't take advantage of any of the deployment features. A side project I've been thinking about is to build a Heroku deployer based on a .NET aspire deployment manifest.
# / 2025 / 02 / 26