In this article, we’ll talk about what exactly is DLL Hell, how these kinds of problems can occur, and the best ways to dealing with them.
For almost a year now, I’ve been writing a book about debugging and problem-solving in .NET. I’m pretty upset at whoever said writing a book is just like writing a series of blog posts. That was way more work than I signed up for. But it’s over now and my book Practical Debugging for .NET …
We are constantly dealing with libraries and NuGet packages. These libraries depend on other popular libraries and there are a lot of shared dependencies. With a large enough web of dependencies, you’ll eventually get into conflicts or hard situations. The best way to deal with such issues is to understand how the mechanism works internally.
Memory leaks are very common, hard to notice, and eventually, lead to devastating consequences. The main tool to detect and fix memory leaks is a Memory Profiler. In fact, I believe the most common usage of memory profilers in .NET is exactly for the purpose of fixing memory leaks. In this article, you’ll see exactly how to use memory profilers to find the leaky objects, why they are still referenced, and how to solve the problem.
Memory leaks and GC Pressure cause pretty inconvenient effects like out-of-memory crashes, performance problems, and high memory consumption. Our primary tools when dealing with those issues are memory profilers. They are one of the most important category of tools in .NET troubleshooting, and in this article, you’ll see how to use them and extract the most information from them.
It’s not so rare to see weird things happen in 3rd party library code. Call some method and you’ve got a strange exception. Or an incorrect behavior or even a process crash. It sure would be nice to debug some of these issues. In this article we’re going to do just that – You’ll see how to debug 3rd party library code in Visual Studio.