The art of simplicity

After pulling some NuGet packages into my .NET Aspire project, I ran into this cryptic startup failure: Aspire.Hosting.DistributedApplicationException: Newer version of the Aspire.Hosting.AppHost package is required to run the application. Ensure you are referencing at least version '13.2.2'. at Aspire.Hosting.Dcp.DcpDependencyCheck.EnsureDcpVersion(DcpInfo dcpInfo) at Aspire.Hosting.Dcp.DcpDependencyCheck.GetDcpInfoAsync(...) at Aspire.Hosting.Dcp.DcpHost.StartAsync(...) The app host refuses to start, and the logs point you toward a version check deep inside DCP internals. The error message tells me that a minimum version of the hosting package is required,but no matter how many times I ran dotnet restore or update NuGet packages through Visual Studio, the error persists. That's because there are two places that pin the Aspire version. Why updating NuGet packages isn't enough Aspire AppHost projects use a special SDK reference at the very...

In my previous post , I introduced Dependency-Track and explained why we chose it to manage our software supply chain security. Now it's time to get practical. In this post, I'll walk you through how we deployed Dependency-Track on Azure Container Apps, including our architecture decisions, configuration choices, and lessons learned along the way. Why Azure Container Apps? Before diving into the setup, let me explain why we chose Azure Container Apps for hosting Dependency-Track. We evaluated several deployment options including Azure Kubernetes Service (AKS), Azure Container Instances (ACI), and App Service, but Container Apps emerged as the best fit for our needs: Simplified Management : Container Apps abstracts away much of the complexity of Kubernetes while still providing container orchestration capabilities. We don't need to manage nodes, clusters, or complex networking configurations. Cost-Effective : With built-in autoscaling and the ability to scale to zero...

Modern software development relies heavily on third-party dependencies. Whether you're building a Java application with Maven, a Javascript app with npm,  a .NET application with NuGet, or a Python service with pip, you're likely incorporating dozens—if not hundreds—of external libraries into your codebase. While this approach accelerates development, it also introduces significant security and compliance risks that many organizations struggle to manage effectively. This is the first post in a three-part series about how we evolved from OWASP Dependency Checker to Dependency-Track to gain visibility and control over our software supply chain. In this post, I'll introduce what Dependency-Track is and explain why we decided to adopt it. What is Dependency-Track? Dependency-Track is an open-source Component Analysis platform that helps organizations identify and reduce risk in their software supply chain. At its core, it's a continuous monitoring solution that ingest...

Yes! .NET 10 is out and not only does it come with a new SDK and runtime version, but it is accompanied by a new NuGet version. With this version, Microsoft has significantly strengthened NuGet's security capabilities to help build more secure applications. These enhancements focus on improved vulnerability detection, automated package management, and better tooling for managing your dependency tree. Let's explore what's new and how these features can help protect your projects. Transitive dependency auditing The change with probably the biggest impact is the NuGet Audit's default behavior. For projects targeting .NET 10 or higher, the NuGetAuditMode property now defaults to all instead of direct . This means that NuGet will automatically scan not just your direct package references, but also all transitive dependencies for known security vulnerabilities. That’s good news as a a majority of vulnerabilities are often found in indirect dependencies. In a typical...

I think everyone has encountered the frustrating scenario where your .NET solution builds perfectly on your local machine but mysteriously fails in Azure Pipelines. Most of the time there is a mistake you made that is easy to fix but sometimes it is the build tooling itself that causes the problem. And that is unfortunately exactly the case when using NuGet Package Source mapping in Azure Pipelines. What is Package Source Mapping? Package Source Mapping in NuGet, introduced in version 6.0, is a security-enhancing feature that allows developers to explicitly define which package sources should be used for specific packages in a project. Traditionally, NuGet would scan all configured sources—public or private—to find and restore packages, which could pose risks by inadvertently pulling packages from untrusted locations. With Package Source Mapping, developers can centralize and control package restoration by specifying patterns that map packages to designated sources in the nuget.c...

While working with Azure DevOps pipelines I encountered a frustrating NuGet package restore failure. The culprit behind these issues is Azure DevOps using an outdated version of NuGet by default, which lead to version conflicts and compatibility problems with modern .NET projects. The problem: Old NuGet versions cause conflicts When running NuGet restore tasks in Azure DevOps, you might encounter errors like these: ##[error]The nuget command failed with exit code(1) and error(NU1107: Version conflict detected for Castle.Core. Install/reference Castle.Core 3.1.0 directly to project SOFACore.PerformanceBenchmarks to resolve this issue. SOFACore.PerformanceBenchmarks -> Castle.Core.AsyncInterceptor 0.1.0 -> Castle.Core (>= 3.1.0) SOFACore.PerformanceBenchmarks -> SOFACore.NHibernate -> NHibernate 2.1.2.4000 -> Castle.DynamicProxy 2.1.0 -> Castle.Core (= 1.1.0). NU1107: Version conflict detected for xunit.v3.extensibility.core. Install/reference xunit.v3.ex...

Centralized Package Management is a NuGet feature that allows you to manage NuGet package dependencies for multiple projects from a single location. This is particularly useful for large solutions with many projects, as it simplifies the process of keeping package versions consistent across the entire solution. After enabling Central Package Management for an existing solution and committing those changes, one of our build pipelines started to fail. When we took a look at the logs we encountered the following error message: ##[error]The nuget command failed with exit code(1) and error(NU1008: Projects that use central package version management should not define the version on the PackageReference items but on the PackageVersion items: Dapper;Microsoft.Data.SqlClient;Microsoft.Extensions.Configuration;Microsoft.Extensions.Configuration.Binder;Microsoft.Extensions.Configuration.Json;Microsoft.Extensions.Http;Spectre.Console;Spectre.Console.Json. What is happening? The reason we...

I'm a big fan of the Central Package Management feature of NuGet. This allows to manage your NuGet package versions centrally instead of at the project level. Why is this important? It helps to avoid that multiple versions of the same packages are used inside your solution. This could lead to strange behavior and unexpected bugs. Central Package Management solves this problem by managing all package versions at the solution level in (one or more) Directory.Packages.props files: Transitive dependencies By default only direct/top level dependencies are managed through Central Package Management. But you also have transitive dependencies . Transitive dependencies refer to the indirect dependencies that a package brings into your project. When you install a NuGet package, it might depend on other packages, which in turn might have their own dependencies. These chains of dependencies create a dependency graph that can go several levels deep. Here's a breakdown of how it w...

Today I had to make an update in an old application that was still based on .NET 4.8. When trying to build the application I got the following warning message: NU1803 – NuGet requires HTTPS sources. When going to the NuGet Package Manager in Visual Studio I got a similar warning: The clean solution is switch to an HTTPS based URL. For this application I just removed the old HTTP based package source from my nuget.config file as it was no longer used. If you are absolutely certain you can trust the HTTP source, you can opt out of this warning by setting allowInsecureConnections to true for this package source: More information NuGet Warning NU1803 | Microsoft Learn

Centralized package management in Visual Studio is a feature that allows you to manage NuGet package dependencies for multiple projects from a single location. This is particularly useful for large solutions with many projects, as it simplifies the process of keeping package versions consistent across the entire solution. To enable centralized package management, you need to create a Directory.Packages.props file at the root of your repository and set the MSBuild property ManagePackageVersionsCentrally to true . Inside this file, you define the package versions required by your projects using <PackageVersion /> elements. For each project, you then define a <PackageReference /> but omit the Version attribute, as the version will be obtained from the corresponding <PackageVersion /> item. Although this is not that much work, if you find this still too cumbersome I have some good news for you; with the latest release of the .NET Upgrade Assistant, you can let t...

Today a colleague contacted me because she got an error when trying to build a specific solution inside Visual Studio. The compilation process failed on contacting the internal Azure DevOps Artifacts nuget feed. Instead she got the following error message: NU1301 Unable to load the service index for source  I tried to load and build the same project but I couldn’t reproduce the issue. There are multiple reasons why this error message appears. I suggested here to try any of the following: Restart Visual Studio: always a good one to try first Run dotnet restore in Interactive Mode : Run the dotnet restore command in interactive mode can help resolve the issue. Clear NuGet Cache : Sometimes, clearing the NuGet cache can help. You can do this by running the following command in the terminal: nuget locals all -clear Neither of my suggestions seemed to help. In the end she was able to solve the issue by removing the local nuget.config file. As she had the pack...

My understanding has always been that when packaging a library in a nuget package, I had 2 options available: Option 1 - Using a nuspec file with nuget pack command Option 2 - Using a csproj file with dotnet pack command Turns out I was wrong. So I want to use this post to explain where I was wrong. But before I do that let me dive into the 2 options above… Using a nuspec file with nuget pack One option you have is to put all the metadata for your nuget package inside a nuspec file. Here is how such a file can look like: To transform this nuspec file to a valid nuget package, use the following command: nuget pack example.nuspec Using a csproj file with dotnet pack A second option is to put all the metadata inside your csproj file: Now we can transform this to a valid nuget package, use the following command dotnet pack example.csproj Where was I wrong? Both of the options above work, but first of all I though that these are the only options(my first ...

In this post I'll give a short introduction about the Polyglot Notebooks extension in VS Code and focus one specific element; how to update the NuGet dependencies inside your code cells when using this extension. Let’s dive in… Polyglot Notebooks in VS Code As opposed to traditional notebooks that are typically used with Python, the Polyglot Notebooks VS Code extension allows you to use multiple programming languages natively all in the same notebook . It supports languages like C#, F# but also SQL, JavaScript, Powershell and more. The Polyglot Notebooks extension is powered by .NET Interactive , an engine and API for running and editing code interactively. A notebook is a combination of code and documentation in the same file. After installing the extension, you can open a notebook(recognizable by the ipynb extension) and execute the coding blocks by clicking on ‘play’: Using NuGet packages inside your code blocks Inside a code block you are not limited to C# code i...

When creating and maintaining (.NET Core) applications, it is always a good idea to keep the dependencies up-to-date. This helps to fix identified vulnerabilities but also keeps the upgrade path short as you closely stay to the latest package version. In this post I show you 3 ways to identify outdated packages and update them when necessary. Through the Visual Studio Package Manager When using Visual Studio, it is easy to find out whether newer versions of the NuGet packages used by your project is available, by using the NuGet Package Manager: Open your solution/project in Visual Studio Go to Tools -> NuGet Package Manager –> Manage NuGet Packages for Solution… Go to the Updates tab, check the Select all packages checkbox and click on Update Through the dotnet-outdated global tool A second option is to use the open source global .NET tool: dotnet-outdated . First install the tool using the following command: dotnet tool install --global dotnet-...

When adding NuGet packages to your .NET projects, it's important to understand the difference between direct dependencies and transitive dependencies . Direct dependencies are the packages that are added directly as a package reference to your project file. For example in this Azure Function project, you see one direct dependency: So knowing and managing your direct dependencies is quite easy. But this package has also dependencies that are not directly added to your project. These are the transitive dependencies. To prevent supply-chain attacks, it is important to have a good understanding of the full dependency treed and know all packages that are used directly or indirectly in our projects. Visual Studio helps you to see and manage these transitive dependencies by making them visible in the NuGet Package Manager: You can hover over any transitive dependency to understand the top-level dependencies that brought it into your project: And you can always promote a tran...

Just before the start of my weekend, I got a message from one of our administrators, the disk space on one of our build servers was filling up. Whoops! A took a look at the server and noticed that a lot of the disk space was eaten up by the .nuget folder: What is this .nuget folder? The .nuget folder is the default global packages folder. It is the location where NuGet installs any downloaded package. In the first NuGet versions packages were installed as part of the solution tree where the packages were used. But since a long time, this got replaced by the global packages folder avoiding having package copies found everywhere on your local file system. The default location is: Windows: %userprofile%\.nuget\packages Mac/Linux: ~/.nuget/packages How to change the global packages location? The easiest way to change this location is by setting the NUGET_PACKAGES environment variable to a different path: $Env:NUGET_PACKAGES = "d:\.nuget\packages" More...

With big traffic jams everywhere, I try to use public transport as much as possible for my daily commute. This allows me to work already before I arrive at the office. As connectivity is not that great during travel, I tend to work offline. Most of the time this works great, but I get into trouble the moment I need to add or update a NuGet package to a project in Visual Studio. Visual Studio starts to complain when connectivity is lost and I want to add a NuGet Package: Of course, this is not related to Visual Studio directly, if I try do this from the command line, I also get errors: The stupid thing is that I do have the package available offline. If you go to %userprofile%\.nuget\packages, you’ll find a local copy of every package you have installed in your projects: Instead of failing back to the cache when the package source is not accessible, it just fails. Local feeds What you can do, is setup a local feed. This will use a simple hierarchical folder structure on you...

I blogged before about the following Azure Pipelines error wen trying to do a NuGet restore: ##[error]The nuget command failed with exit code(1) and error(Unable to load the service index for source https://tfs.server.be/tfs/DefaultCollection/_packaging/797f899f-9ad1-4158-93bc-8f3293cf4a59/nuget/v3/index.json. Response status code does not indicate success: 403 (Forbidden - User 'Build\534a066a-3992-4851-a816-b189836bee69' lacks permission to complete this action. You need to have 'ReadPackages'. (DevOps Activity ID: 8D53BF1D-E45E-49C4-879F-6CBD8635D1CE)). Although the solution I mentioned in the original blogpost should work, I found a different solution that should also do the trick. Here are the steps: Go to the Azure DevOps project that contains the failed pipeline in Azure DevOps. Go to Artifacts Select the feed that causes the problem from the drop down (if not selected by default) Click the Feed Setting gear on the top right corner. ...