I run recently into this strange error with one of my Git repositories:
Pull Failed: error: could not delete reference refs/remotes/origin/HEAD: cannot lock ref 'refs/remotes/origin/HEAD': unable to resolve reference 'refs/remotes/origin/HEAD': reference broken error: vs-ssh.visualstudio.com:v3/* did not send all necessary objects
As I was refactoring a .Net project, I run into an annoying little problem that cost me a lot of time. While I could compile the project on my developer machine, it failed with this error on Azure DevOps:
[error]...: Error : This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is packages\SkiaSharp.NativeAssets.macOS.3.119.0\build\net462\SkiaSharp.NativeAssets.macOS.targets.
If we committed something into a Git repository that should not be there, we could rewrite the history and make it look as it was never there.
I usually try to prevent rewriting the history, especially when I already pushed the changes. Then when we modify the past, everyone in the team needs to do some extra work to catch up.
If this is not a problem or the lesser evil, we can use the following steps to rewrite the Git history.
C# 11 introduced collection expressions (formerly known as list patterns) to .Net 7+. This little feature allows us to match lists by shape, not just by checking every position. Let us see how this can influence how we write checks.
Packages get outdated in no time. Keeping your dependencies up to date is not only a good thing, but because of the many security issues also an important task. It is already a few years since I wrote about the little .NET helper libyear. While this tool is still under active development and does its job the same way as it did in 2019, it is time to see what new tools could help us to keep an eye on our dependencies.
A nice little helper I found is dotnet-outdated, that gives us a detailed list of our projects and the outdated packages.
By default, ASP.NET validates the dependency injection container configuration at runtime. As a result, we only discover missing or misconfigured dependencies when the application runs. While this approach works, getting feedback at the build time would be a time saver.
As we moved from .Net Full Framework to .NET 6, we had to use the little hack of creating a AssemblyInfo.cs file and put this content into it to access the internal classes and methods from our test project:
A few months back I reviewed an application. It was sad to see in how little time you could create a mess that is not only hard to work with, but that can only be changed with a lot of effort. In this post we focus on one tiny little detail that can help you as a warning sign early on: having test code directly in the production code.
If you search for a value with an _ in the name, you learn something new about SQL Server, but end up with a result that does not match your expectation:
If we run this query, we do not get back everything with an _ in it. Instead, we get back everything. How is that possible? The _ is a placeholder that stands for any character, what gives us back every row that has any character anywhere in the column we search for. That is most likely not what we try to do.
There is an interesting pattern that you can find in many projects, that usually starts with a good idea and turns into a dump in no time: the core folder. You start with an application and think about the core business, the important stuff. So, you go on and create a core folder. Here is now the place for the important stuff, right? No. Here is the start of your mess that from now on only grows.