Resolving “Response status code does not indicate success: 400 (Bad Request)” in NuGet Packages Push to GitHub Packages with GitHub Actions

GitHub packages registry can be use to keep your organization NuGet packages privately or share them publicly. If you create a package in a private repo it would be private to the repo or for the organization if you use an organization. If you keep your packages in a public repo you can share it publicly. Ideally when you build reusable NuGet packages you would build and publish such packages with GitHub action workflow to your GitHub packages. While implementing this you may encounter “Response status code does not indicate success: 400 (Bad Request)” at the push of the package, due to special needs of GitHub based NuGet packages. Let’s look at them in this post.

Enhanced YAML Conversion for Azure DevOps Classic Build Pipelines

Azure DevOps YAML pipelines is the way to implement pipeline as code and version control the pipelines alongside your application code. However, among Azure DevOps users classic build pipelines are still popular due to its simple, visual ability to implement and understand faster etc. Additionally, classic pipeline agent job or individual step could be converted to YAML by using “View YAML” option available in each step/task as well as for a given agent phase. With a recent update to Azure DevOps new feature has been added to enable exporting entire classic build pipeline as YAML replacing the “View YAML” feature. This is a great improvement feature added to Azure DevOps as “View YAML” feature was only able to consider information in web UI when generating YAML out of classic pipeline, which at times generated incorrect YAML. With the new export YAML feature, now you can derive a reliable YAML implementation of a given classic pipeline. This would help people to implement pipeline quickly using classic pipeline UI and convert and obtain a YAML, which would help pipeline as code adoption easier. Let’s look at how we can use this new export to YAML feature.

Resolve the “Entity Framework tools version '3.1.9' is older than that of the runtime '5.0.0' in Visual Studio Package Manager”

.NET 5 is released recently and you can use entity framework core 5 with your projects by setting up the version 5.0.0 of the packages, Microsoft.EntityFrameworkCore, Microsoft.EntityFrameworkCore.Design, Microsoft.EntityFrameworkCore.SqlServer, Microsoft.EntityFrameworkCore.Tools if you are using SQL server as the database. However, when you execute dotnet ef commands in the package manager console in Visual Studio you might see the message “Entity Framework tools version '3.1.9' is older than that of the runtime '5.0.0' in Visual Studio Package Manager”. Let’s see how we can get it fixed.

Deploying .NET 5 Web App via GitHub Actions to Azure App Service

.NET 5 is released recently and now you can develop applications using .NET. While releasing .NET five with zero delays Azure App Services started supporting .NET 5 with Early Access. This is helping us to deploy our application code, without having to deply them as self-contained with framework. Meaning we can now deploy our .NET 5 Web Apps, APIs or Function Apps to Azure, just as published project binaries and things will start to run without any issues. In this post let’s look at how we can setup a quick build deployment pipeline deploying a .NET 5 web application to Azure using GitHub Actions.