If your .NET application is no longer responding on production you might want to urgently restart the process. However, if you do that you will lose valuable information into why it got unresponsive.

Let's collect that valuable information and after that restart the application.

First of all download a tool called procdump.exe (you can find it here: https://learn.microsoft.com/en-us/sysinternals/downloads/procdump) It is a small executable, without installation, that you can use via commandline. Copy the tool to the server.

Before we start: there are some things that you will need:

• Dump Type
• Process ID

Figuring out the Dump Type

Since you have an unresponsive application and you plan to restart it, and thus don't have a second chance to capture the data, you want a full dump.

Figuring out the Process ID:

There are multiple ways to figure out the Process ID, I will leave that up to you.

Now the command that you want:

procdump <dumptype> <process id>

Example:

procdump -ma 18228

The result will look like this:

When you are introducing an ORM to communicate with your database. You will need to know upfront where in your application your objects will be placed and where the configuration belongs. The objects are represented in the domain layer in the following drawing.

As you can see in the above drawing the domain layer is the heart of the application. It should have as few dependencies as possible. This also means that the domain layer should be storage agnostic and have no knowledge about the storage medium or ORM used. Concrete: your domain layer should not know Entity Framework.

Convention

If you just started using Entity Framework you might have noticed that it just seems to work out of the box. That's a good and a bad thing. This means that you can get started pretty fast as everything is configured via conventions. Entity Framework does this by looking at the name of properties and it will try to figure out what you are doing.

The risk of using conventions is that they are not explicit and that you have no guarantee that with the next version everything will be working exactly the same. It might be that due to a bug fix something works a little bit different. If you work with conventions you are also not able to rename any property as you have no mapping configured with the database column names. If you give a property a wrong name it will also silently fail as Entity Framework cannot figure out if you wanted it to do something.

Attributes

Working with the Domain Model is already hard enough. Developers should not be overwhelmed with irrelevant things like the configuration between the ORM and the actual database. When you are working with Domain-Driven Design you are focussing on delivering business value by automating existing processes. This is the only thing you want to focus on in the domain layer.

Another downside of using attributes is that you cannot combine multiple properties as the attribute is placed above 1 property (if property A has value X than property B cannot have value Y). On top of that your domain layer now has a vendor lock to a specific ORM and/or database technology.

EntityTypeConfiguration - Explicit configuration

The last and preferred way is to use explicit configuration. You know very well what property is mapped to what column and table in your database.

Entity Framework configurations have an order in which configurations are applied. At first there are conventions for when you do not configure anything, after that you can work with attributes but these have limitations. The final way is to use Entity Type Configurations that also overrules all the previous configurations.

You only have 1 place to look if you only use explicit configuration. If you use attributes you will always have to verify that they are not overridden.

The place to configure this is the infrastructure code that glues the domain layer and the domain layer together. This might also be the same place where your repositories are located.

public class StudentEntityConfiguration : EntityTypeConfiguration<Student>
{
      public StudentEntityConfiguration()
      {
      ToTable("StudentInfo");
      HasKey<int>(s => s.StudentKey);
      Property(p => p.DateOfBirth)
         .HasColumnName("DoB")
         .HasColumnOrder(3)
         .HasColumnType("datetime2");
      Property(p => p.StudentName)
         .HasMaxLength(50);
      Property(p => p.Version)
         .IsConcurrencyToken();
      HasMany<Course>(s => s.Courses)
         .WithMany(c => c.Students)
         .Map(cs =>
         {
            cs.MapLeftKey("StudentId");
            cs.MapRightKey("CourseId");
            cs.ToTable("StudentCourse");
         });
   }
}

Now you need to tell Entity Framework where to look for these explicit configurations. You do this by adding the configurations to the model builder.

public class SchoolDBContext: DbContext 
{
   public SchoolDBContext(): base() 
   {
   }

   public DbSet<Student> Students { get; set; }
    
   protected override void OnModelCreating(DbModelBuilder modelBuilder)
   {
      // Moved all Student related configuration to StudentEntityConfiguration class
      modelBuilder.Configurations.Add(new StudentEntityConfiguration());
   }
}

Inversion of control was in part introduced to fix the problem of writing tests. How can we write tests, focussed on a small part of our application, if every dependency is instantiated inside the part we are trying to test? Simple. We introduced interfaces so that we were in control of the implementation.

The goal of writing tests is to ensure your code remains stable when you add or change existing features. In order to reduce the costs of writing tests we started to use interfaces. This enabled us to ignore other, irrelevant parts of the application within a test.

So an interface is just a contract that contains the signature of methods, properties, events or indexers. It does not contain any implementation. This gives us the freedom to choose the implementation that fits our test the best.

Interfaces and Domain-Driven Design

In an application that is Domain-Driven Design centric you have a domain layer. This part is the heart of your application. It contains state and behaviour and makes sure it remains consistent at all times. It should be storage agnostic and have the least dependencies in your application. The domain does not know about the application layer, it goes inwards. The UI knows the application layer and the application layer knows the domain layer.

Domain is the heart of the application

When you are writing tests that involve the heart of your application it makes no sense to fake it. You could ask yourself the question: What am I actually testing? You should be testing your implementation.

Thus, you shouldn't use any interface inside your domain model. Although any interfaces is maybe a bit exorbitant. What I really mean is: you do not want interfaces like IEntity or IAggregateRoot. As you would give the opportunity for the wrong part of your application to be faked.

Semantically

An interface defines signatures but no implementations. If a class (or struct) implements an interface it is a can-do relationship. Order : IAggregateRoot An Order can-do IAggregateRoot is meaningless. Inheritance on the other hand defines an is-a relationship. Order : AggregateRoot An Order is-an AggregateRoot.

As interfaces do not contain any implementation details it would be difficult to reuse certain methods or even properties. What if you want to use a private setter for a property and define it in an interface? It is not possible. As a result the property would be really read-only. Entity Framework Core up until version 2.1 did not support writing to a property when it only had a getter available.

Attributes on interfaces

Another problem with interfaces, although it is not a good idea, is that attributes are not inherited when you implement an interface. If you use a RequiredAttribute to indicate its value is required it will silently fail in your classes.

Application Service

The yellow circle indicates the boundary of the application service

Let's focus on this last part: orchestrating. What would be the consequence of faking this part? You would lose one of the main responsibilities. What you really want to test is the orchestration logic. So that you can fetch the needed information, manipulate it and that your unit of work completes its action successfully. If an email needs to be send you want to be sure the correct code is called the right amount of times with the correct parameters. You don't want to be able to fake this part. What you really want is to fake all its dependencies and verify that these dependencies were all called with the right parameters. So interfaces between layers do make sense, but inside the application layer you might want to avoid them.

In conclusion: think about the impact of using interfaces. Are you using them on the right class? Do you want this class to have another implementation via inversion of control? And if tests are not one of your concerns, think about reusability because properties defined on an interface need to be re-implemented all the time...

A new tool emerged and, while it is still in beta, it is already quite handy. When we take a look at the SQL developer tools we will see that Microsoft placed a new tool on the top

Screenshot in case the page is edited.

SQL Operations Studio (preview) is a free tool that runs on Windows, macOS, and Linux, for managing SQL Server, Azure SQL Database, and Azure SQL Data Warehouse; wherever they're running. It is open source and you can find it on Github. Although the current version 0.23 it is already promising and useful.

If you have read Installing SQL on macOS without using the command line! you will be able to continue this post and connect to your new database.

The server name is localhost, since we did not change or specify a username it is still sa and our password is Passw0rd!. Click on Connect.

Let us explore how easy it is to install SQL Server 2017 on macOS by using Docker. Let me prove to you how easy it is to install SQL Server 2017 on macOS by prohibiting myself from using the command line. We will use Docker and Kitematic.

The first step is to install Docker, once you have finished that step we need to increase the memory. SQL Server 2017 needs at least 2 GB of RAM (3.25 GB prior to 2017-CU2).

To be in the clear and to avoid having issues increase the memory to something like 4 GB, although the default value of 2 GB should be sufficient.

Step 2 is to pull and install the Docker Image.
Pulling the Docker image is something we can do by using Kitematic. When you click on the Docker icon in the menu bar you should see Kitematic, click on it and it should download the Kitematic app.

Click on New next to Containers in the left hand corner and search for microsoft/mssql-for-linux and click on create.

After that the image should start to download:

The output window is not accepting user input so we need to put some environment flags in place. Set the following environment variables:
ACCEPT_EULA = Y

SA_PASSWORD = Passw0rd!

MSSQL_PID = Developer

click on save and hit back to the Home tab.

Step 4 Profit!

You are finished, nothing else to do. It is even easier than installing the default windows version.

Step 5 Connect to your database

Microsoft made it very easy to get started. We need 2 prerequisites to get it up and running. Download the following installers:

• https://dot.net/core
• https://www.visualstudio.com/vs/visual-studio-mac/

Installing .NET Core

Introduction

Click 'Continue'

Destination select

Select your preferred Hard Drive  

Installation type

Click 'Install'

Installation

Enter your password

Summary

Installing Visual Studio for mac

Click on the big circle

Accept warning "application downloaded from the internet"

Click "Open"

Thank you for downloading Visual Studio

Press "Continue"

Some features require Xcode

These features are related to Xamarin and building iOS apps. You can  safely skip this. If you do need them you can rerun the installer and  select them afterwards.  

What would you like to install

We only need Visual Studio and the tools. I already installed Android and iOS on my machine.  

Downloading and installing...

Enter your credentials  

Installation successful

Getting started

Start Visual Studio for mac

Click the purple "New Project..." button underneath Recent.

Choose a template for your new project

Select .NET Core followed by the project type you prefer. In this example "ASP.NET Core Web App"  

Configure your new ASP.NET Core Web App

Start the application

Just press the 'Play' button next to Debug at the top left.

Watch the result in your browser

Enjoy

It is a library for ASP.NET Core developers to send realtime messages from server to the client and vice versa. Full duplex communication with 2 parties performing RPC operations on each other.

What changed?

• jQuery is removed as a dependency, a new javascript client is created and can be found on npm;
• SignalR no longer supports auto-reconnect and is no longer durable as these were features for long polling;
• There is no longer hub state, the hub state needed to be passed around when something changed;
• No more multiple hubs per endpoint. In earlier versions SignalR they used long polling from the ground up because web sockets were not as widely supported as now;
• No more single-model, scale-out. This made scaling harder when you have clients directly communicating with each other, resulting in you not having control over the model;
• No more multi-server ping-pong. Earlier when you had multiple servers every message was send to every server so that they could dispatch it. Now you need a sticky sessions.

What is new?

• Binary data support, e.g. send/receive binary data;
• Host-agnostic (enables non-HTTP transport);
• All-new connection-level “Endpoints” API;
• Multiple protocols/formats support, e.g. JSON, ProtoBuf, custom;
• Support “pure” WebSocket clients, you can use any WebSocket client without having to use the SignalR client;
• Return results from client method invocations;
• TypeScript client;
• Flexible scale-out extensibility.

Durable vs Persisted vs Realtime

SingalR now only supports realtime messaging and has dropped support for durable subscriptions.

Durable

When you have 1 producer and several consumers, you typically let the producer send a message to a topic. That topic then has multiple queues (1 queue per consumer) subscribed. Durable here means that the messages are stored when a consumer is offline. Once the consumer is back online it continues processing the messages.

Persisted

When a server restart is required the messages are stored on disk. For durable messages to survive a server restart they need to be persisted as well.

Realtime

Durable and persisted messages come with a heavy I/O cost. SignalR does in contrast with previous versions not work with durable subscriptions. The focus is shifted towards being light weight and realtime.

Getting started

Read: "ASP.NET Core SignalR - Getting started on macOS"

How do you protect your company against known vulnerabilities? It starts by having an inventory of all the software, client-side and server-side, that you are using (including plugins) and its dependencies and having it continuously updated. Make sure there is a centralized list that has the knowledge of all software and the versions installed. The list should be updated autonomously and automatically. Otherwise, you might get the chance of having an outdated list. If somebody is unavailable and somebody else updates something or forgets to update something then that's the beginning of a problem. Make sure the list can update itself otherwise you have no guarantee that your list is up-to-date.

Now that you have a list and know what to look out for you can be on the lookout. Use software composition analysis tools to automate the process of continuously monitoring sources like the National Vulnerability Database. This way you prevent your company from being dependent on a person or team that reads the latest vulnerabilities. What if they miss something? What if they unexpectedly unavailable? What if...? You have an automated solution that notifies you the moment a vulnerability sees the daylight.

How will you handle a security problem that is reported to you, will you wait for the fix (internal or external) or do you want to immediately protect yourself from the issue? What if you know there is a zero-day exploit out there? What if it takes a couple of days to fix a security problem?

To be able to respond to security issues add an extra layer in front of your web application. This means that your web application does not accept direct connections. It does not accept machine to machine connections, it accepts process to process connections. By installing an additional layer you
can filter the requests that come in and prevent them from reaching your application directly. You have the possibility to protect yourself against a known vulnerability while the problem itself is not patched yet. You can do this by installing a virtual patch. In short, you install an active filter that blocks known vulnerabilities until a permanent solution is available.

Pay attention when you are using virtual patches:

• There is a risk that you are addressing some parts of the vulnerability but not all of them.
• There is a risk that you forgot to implement the virtual patch on all the places that needed it.
• The company loses the incentive to update to the permanent solution, thinking it is safe. It is possible that the vulnerability gets wider while it is in the open, for example by combining multiple exploits/vulnerabilities.
• A virtual patch is a temporary solution, make sure there is a protocol in place to follow up when a permanent solution is in place. There is a chance that it might be forgotten.

If you need to validate data it might be a good idea to keep the validation as close as possible to the data. If a string comes in that represents a VIN number, wrap it inside a class and only use one entry point to make it easier to validate.

Let's say you are working for a car brand. In this case it might not be unreasonable to think that you are using the VIN number from the car as an identifier for the car. There might be several parts of our application interested in the VIN number, maybe for different reasons, for example: aftercare, dealers, insurance, ... The first thing that a part of our application will do is validate that the VIN number is valid. Why should we repeat ourselves in every part of the application and have the chance of forgetting to implement this check somewhere? We could create a VIN number value object with the validation built-in and pass it around in our application. Now let's say there comes an extension to how a VIN number looks like, this will cause you to have to search through the code for every occurrence and modify it. If it was already validated (and not forgotten to be implemented) and if we happen to find every occurrence (nothing says that it was implemented in the same way everywhere). By centralizing it you have less maintenance costs.

The previous sample was not really related to security (although it covered a bit of data security). It just showed that it could be handy to keep the validation as close as possible to the data. Time for another example: suppose you are working for a webshop now. Some parts might seem very trivial but might have a tricky outcome if they are implemented wrong. The flow for an order might be that an order with order items comes in. The order items might have an amount and an identifier for the product. Now let's zoom in on the amount. People should never be able to order a negative amount of order items. This would mean that we would owe the customer money and the customer would owe us a product. This was not foreseen in our business plan so we want to avoid it from ever happening. It might be a good idea to use an amount value object where you validate that the amount is a positive and natural number. This might seem weird to do for something trivial but the same amount that came into the system will be passed onto the stock management system, to the billing department and maybe to a customer care system, ... These systems could be part of our application. To be able to be consistent we would need to repeat ourselves on all these places and it is very easy to skip one place. Working with value objects makes it so much easier for everybody developing on the system because it is something less to actively think about.

In a traditional approach, we think of security as something very explicit. Think of tasks that would be prioritized and implemented. We then probably look at the following list: attack vectors, 0-day exploits, web vulnerabilities, OWASP to create our backlog. Afterwards we would prioritize the backlog.

This way of working has the shortcoming of not being future proof. We focus our attention to known security problems and we try to mitigate them today. It also has the disadvantage of having your developers and everybody involved actively and explicitly thinking about security. Sometimes a problem is so difficult that it is very hard to actively think about security, somebody might forget something. Everybody involved in the project also needs to be a security specialist, everything we do has an impact on security. If we would change something in the project you would need to know what the security impact is for that particular change. This also means that we need to be aware of every concept into the application.

Why is using AutoMapper for DTO to Entity mapping a bad idea? AutoMapper does its job by using reflection. When you use reflection you divert from the normal path and you manipulate data that you potentially shouldn't. In other words: we enable our domain model to be mutable from everywhere. This makes it very hard to track down from where in the code a certain property can be modified. This drills down to how will you write tests if anything from anywhere can modify properties? Which part of your application will be responsible for enforcing the business rules. How can we ensure that we are in a consistent state?

Inconsistent state

If every part of your application can change properties directly in your domain model you lose the possibility to validate domain logic. Let's say we are working with triangles. When we receive an instance of a TriangeDto class we want to be sure that the values are consistent. We know that our triangle is valid if the sum of all the angles is 180°. How can we be 100% that the sum will always be 180? We can't. Because we allowed AutoMapper to make changes in such a way that they are invisible.

Another example is conditional logic. When you set the value of a property you don't have the value of other properties available (in the setter of a property). You cannot enforce that when property X has value A that property Y cannot/should/could have value B.

Thirdly, when you want to reuse domain logic inside a class (e.g. value object) you can never be sure that the logic in the class was used and not bypassed by AutoMapper (by directly setting the value of a property, while the property used a private setter). For example, when you place an order you want to be sure that the amount is a positive or natural number.
If you use a value object with validation then you are always sure that when you get an instance of that class, the values are correct. E.g. The amount is non-negative, correct ISBN number or a correct VIN number. See: ValueObjects as a security solution

Fourth, all your access paths are visible if you use constructors or factory methods (method on the same class, calling a private constructor), it also makes it easier to test. You can trace down from where the domain was called. It all comes down to: preventing the domain from becoming inconsistent.

Technical view

If you use an ORM like Entity Framework you will lose change tracking. Instead of using a tracked instance you are forcefully creating a new instance via reflection. This will become a real issue when you have relationships between entities. Your ORM will recreate all the navigation properties and the primary keys will collide (if you are lucky: meaning your problem becomes visible). It will always add a new child instead of updating it.

Author's opinion

What is the opinion of Jimmy Bogard (the author of AutoMapper)?

There is no two-way mapping because we never need two-way mapping. There was a point very early on where we were at a critical junction, and could decide to do two-way mapping. But we didn’t. Why? Because then our mapping layer would influence our domain model. I strongly believe in POCOs, and a very writeable domain model meant that POCOs were out. What exactly would two-way mapping do to our domain layer?

• Force mutable, public collection , like “public EntitySet Categories { get; }” <- NO.
• Make testing much, much harder, as we only ever wanted to update a portion of a domain model
• Force our domain model to be mutable everywhere
  So my question to those wanting two-way mapping:
• What scenarios are you looking at doing two-way mapping?
• What impact would two-way mapping have on the originating source type?
• How would you test two-way mappings?

Security is way too often seen as a feature instead of a concern. We should not put security on the backlog as features.

Although if we take a look at the backlog we might see some items that are actually security features, these are security features addressing a specific security problem. A login page is used because of a concern that people should only see their own data. "We are concerned that people should only see their data."

Looking at security as a feature might also introduce the following problem: What if added to the previous feature: "we also want the customer to be able to download his data, instead of only seeing it. We also want this to be fast". The result of this extension can be that the team choses to work with physical files. Nobody in the team thought about the security impact and they forgot the lock the physical files away and if a filename pattern emerges people might start to guess and download the data of others.

If we translate this into the real world outside of an IT context we could say that in order to be burglarproof we need a good (expensive) lock. We could add this as a product backlog item and once installed we are good. Or are we? Did we upgrade the hinges as well? No? How did we miss this? Because we described adding the lock as a feature and were lost into thinking about features. We started in a good way, we wanted to be burglarproof and then decided to implement a feature that was not adequate. The concern for security was not met. If we kept looking at it as a concern we could have seen that the hinges also needed to be replaced. We could question who would need a new key and make an inventory of the keys.

Additionally, another reason why we should not look at security as features: Features are prioritized and unfortunately security is often not seen as adding direct business value and therefore it gets lowered in priority for another item.

When you are using Entity Framework migrations you will probably use the Package Manager Console to execute commands like update-database.

Now the question arises: how can I debug my code if I am not debugging it via Visual Studio. Add the following line to your code and you will get asked which visual studio instance you would like to use to debug.

Debugger.Launch();

How do you make DateTime testable in .NET? Once you use DateTime.UtcNow in the body of a method and you did not pass it as a parameter you no longer have control over DateTime.

In order to gain control you should wrap DateTime.UtcNow inside an implementation of an interface.

public interface IUtcDateTime
{
   DateTime UtcNow { get;  }
}

public class UtcDateTime : IUtcDateTime
{
    public DateTime UtcNow { get; } => DateTime.UtcNow;
}

Now you can let IUtcDateTime be injected by your Depency Injection framework of your choice and write unit tests. An additional benefit is that you are sure that the right usage of DateTime is used. In larger projects it becomes harder to spot mistakes like DateTime.Now vs DateTime.UtcNow.