[.NET Internals 01] Basics of memory structure

Have you ever wondered about what’s under the hood of the applications you develop? Ever been surprised that there’s no need to worry about memory allocation and deallocation using high-level programming languages such as Java or C# after leaving the university? Still remember (old) C++ times with delete statement?
Source: “Arnaud Porterie – The Truth About C++”
By this post, I’d like to introduce a new “.NET Internals” series on the blog. I will be publishing a new post on .NET internal concepts every Wednesday. No end date for the moment 🙂 Posts within the series will be mostly about memory management and performance aspects of .NET applications. All discussed concepts are applicable to most of the modern programming platforms, but the examples will be based on .NET Framework. If you’re interested in such topics, I encourage you to check this blog every Wednesday starting today 🙂 *there is 1 assumption and 1 fact here:
  • assumption: you used to program in C/C++ (before C++11) on the university,
  • fact: that’s not true you don’t need to worry about memory management using high-level programming languages; wait for the next posts to get to know why.


Each application targeting .NET is managed by CLR (Common Language Runtime), which is a part of .NET Framework, which must be installed on the computer on which the .NET application is launched – the exception are

.NET Core self-contained apps

T-SQL/SSMS: transaction rollback in scripts with XACT_ABORT ON, GO statements and syntax errors

I’ve recently met a weird issue with T-SQL scripts at work and would like to share it with you today 🙂

T-SQL script with multiple objects created

On daily basis I work a lot with MS SQL Server databases. We often create many T-SQL objects (tables, views, procedures, functions) and because of some reasons we cannot use Entity Framework or another from widely available ORMs. Nonetheless, all objects created in the database must be kept in the form of SQL scripts (files) containing set of CREATE, ALTER, INSERT, DELETE or whatever T-SQL statements. What we often do is to create a single .sql file, which in fact often contains more than one, separate (independent) SQL statements (e.g. creates a table and a procedure). What we obviously want to ensure is that when executing the script either all statements are committed to the database or none of them. This means that if in a part responsible for creating a particular object any SQL error is raised, execution of the whole script should be interrupted and the whole transaction rolled back, so in effect none of the objects contained within this script are created (none of the statements batches is committed). Here the issue comes out.

SQL script with XACT_ABORT ON and GO statements

In order to handle above-described requirements, the template for SQL script looks as follows: .gist table { margin-bottom: 0; } Firstly, we set XACT_ABORT to ON. This setting,

according to Microsoft docs

.NET Developer Days 2017

On 18-20.10.2017 I had a pleasure to attend .NET Developer Days 2017 conference in Warsaw. The first day we took part in a full-day workshop on containers with Docker and the next two days we attended the conference itself. In this post I’d like to share my thoughts and insights on the conference, its organizational aspects as well as my subjective opinions on the sessions I attended. Let me start by describing the workshops and all sessions I was present at. You can find the list of all sessions that were held during the conference

on its official website

Entity Framework Core – database initialization with Unit Test

I’ve recently been presented a concept of initializing the database (creating or re-creating it) with Unit Test method. Initially I thought it’s a non-sense, but after a while of taking a deeper look…

Code First approach

The method of initializing the database I mentioned was used with Entity Framework Core in ASP.NET Core project, where Code First database creation approach was used. As you know, this approach implies that we create models (classes) representing our database entities in the code first and then, using an ORM system (such as EF), database structures are created. This is very convenient, especially in prototyping. I’ve developed few small or average-size ASP.NET apps and I always used Code First. However, I cannot say how it works on production as these apps were university or pet projects which I’ve never deployed on real customer’s environment. What I noticed is that creating entities using this approach is fast and quite easy.

Database initialization in development phase

As long as your project is in development phase, different developers are working on it and there is some database behind, but the data itself is not very important (you only need the database structure – there’s no production data in it yet), programmers often need to have the database (re)created. To make this process quick and easy, instead of using Migrations straightaway, you can define your models, DbContext and write a Unit Test method which initializes the database. Then, each developer working on the project only needs to re-run this Unit Test to have the database created. What’s more, as soon as another programmer makes any change in any of the models, the others just need to re-run the Unit Test which re-creates the database and potentially fills it with sample data. There’s no need to keep any migration files/scripts in the development phase. The following subsections present how to do that. Examples are based on a simple ASP.NET Core MVC application called CarServiceMvc. I’ve used .NET Core 2.0 Preview 2 and Visual Studio 2017 15.3.0 Preview 3.0. The whole source code

is available on GitHub

Xamarin.Android – debugging via WiFi

In this short post, I’m going to show you a very handy feature of Android Debug Bridge (adb) – possibility to debug Xamarin.Android apps in Visual Studio via WiFi connection.

Using ADB to debug Android apps

By default, adb is configured to “map” Android devices connected via USB ports to the computer as debug devices, which are then available e.g. in Visual Studio as the device on which our app can be deployed and debugged. In may cases we debug apps on Android emulators, which is frequently fair enough, but at some point we need to make our tests on a physical device. It may not be very comfortable to have the phone connected using USB cable all the time, especially when testing some physical sensors like accelerometer or gyroscope. For such purposes, ADB gives us the possibility to connect Android devices via WiFi instead of USB. Let’s see how to configure it.

Configure ADB to work on WiFi

The first requirement is – obviously – that both our development PC and Android device must be connected to the same WiFi network. Then we need to find out what is the IP address of our Android device – it can be checked by going to Settings -> WiFi -> Menu – Advanced settings (Android 6.0):
Android 6.0 – IP address
As soon as you have IP address of the device noted, connect it to the computer via USB port. Now we need to use adb.exe to configure it for connecting with the device via WiFi. You can either add system environmental variable pointing to where the adb.exe is stored or just open cmd, go to the catalogue where it’s located (Android\platform-tools\) and execute the following commands:
  1. Change ADB to listen on TCP port:

adb tcpip 5555