Dotnet

Or how dotnet-dump collect works on Linux If you are trying to diagnose the behaviour of a mis-behaving application in production, one option is to use the dotnet-dump tool to get a memory dump of the application so you can study it offline. With a dump, you can get stack traces, look at all the threads and even dig through the entire heap offline. But how does dotnet-dump actually work? This post will try and summarize what I found as I tried digging through what dotnet dump collect does under the hood. ...

Or, how to deal with error:0E07607: configuration file routines…. TLDR: # Only for .NET 5 or .NET Core 3.1 sudo dnf install -y compat-openssl11 export OPENSSL_CONF=/etc/pki/openssl11.cnf dotnet whatever Introduction How do you get .NET applications - whether the SDK/runtime itself or a self-contained application - working on RHEL 9? Generally, this should be a walk in the park. .NET is a cross platform runtime. It explicitly supports RHEL. There shouldn’t be any surprises here. ...

Why Bootstrap? Compiling code is supposed to be straightforward: you run a compiler over the code and the compiler gives you back an executable program. But what do you do if there’s no compiler? That’s the dilemma .NET runs into in Fedora. Every release of .NET (Core) needs a recent version of a .NET (Core) SDK that can be used to build it. But that’s exactly what’s missing and what we are trying to build. ...

Have you ever tried to debug a .NET application and seen errors saying debug information or debug symbols are not available? What are debug symbols? Where are they used? When would you need them? How do you get them? This post will try to resolve confusion by calling out things you absolutely need to know about them. What are debug symbols? Source code contains a lot of information that’s not strictly part of it’s functionality. It contains human readable names, including names of types, classes, methods and local variables. It contains lines of code in an order that (hopefully!) makes it possible to understand what is happening in order. ...

This post covers the versions and components in .NET Core 1.x. Components .NET Core consists of multiple components that are each versioned independently and can often be mixed and matched. The Shared Framework contains the APIs and the Virtual Machine and other runtime services needed for running .NET Core applications. The current .NET Core Virtual Machine is called CoreCLR. This executes the .NET bytecode by compiling it JIT and provides various runtime services including a garbage collector. The complete source code for CoreCLR is available at https://github.com/dotnet/coreclr. The .NET Core standard APIs are implemented in CoreFX. This provides implementations of all your favourite APIs such as System.Runtime, System.Theading and so on. The source code for CoreFX is available at https://github.com/dotnet/corefx. The Host is also sometimes called the muxer or driver. This components represents the dotnet command and is responsible for deciding what happens next. The source for this is available at https://github.com/dotnet/core-setup. The SDK consists of the various tools (dotnet subcommands) and their implementations that deal with building code. This includes handling the restoring of dependencies, compiling code, building binaries, producing packages and publishing standalone or framework dependent packages. The SDK itself consists of the CLI , which handles command line operations (at https://github.com/dotnet/cli) and various subprojects that implement the various operations the CLI needs to do. Versions Each of the components listed above are versioned separately. You can find out the version of each of those components. ...