Useful NLog Targets

NLog has many targets to which it can save log entries. Here are some that I consider quite useful.


I’ve added some parameters to archive log on everyday basis.


NLog will create custom application log MyAppLog.

Visual Studio Debug window

Also NLog allows to save log in a database table, but it needs more efforts and lines of code to setup it. You can read more in the article Database target in NLog project documentation.

Reloading Configuration In NLog

When you use NLog in your C# project, its configuration is loaded once on the application startup. Now I want to change the configuration (targets, rules, levels) while application is running. It’s easy – just edit NLog.config file.

That’s not enough. Application should notice that changes and reapply them. This can be triggered by re-reading NLog.config again at some point, by pressing the button or calling Web API, i.e. you or your application should initiate reloading.

As for NLog, reloading is implemented by 3 lines of code.

C#. Passing Lambda Expression As Parameter

Using delegates you can pass a lambda expression as a parameter to a function, and then use it in LINQ queries. This can be done with Func<…> delegates.

If you want to pass a lambda expression to be used, for example, in Where clause, you need a Func<T, bool> delegate. Just hover the mouse over Where in your code, and IntelliSense would show you the required syntax.

Here is a simple demo program:

C#. Passing Function As Parameter Using Delegate

I need a generic C# module that will execute different functions for some classes, or execute none. This can be done with delegates.

The basic info is described in MSDN articles:
Using Delegates (C# Programming Guide)
Func<T, TResult> Delegate

Here is my simple console application that would call different functions that are passed as parameters.

Comparison: Entity Framework vs C#. When Equality Operators Are Not Equal

When you compare numbers, you know that 5 equals 5. But C#, Entity Framework, SQL and many programming languages have a special value called “null”. It’s something unknown. So when you compare a definite number, for example 5, with null, the result will be “false”, because 5 and unknown is not the same.
But the situation differs when you compare null with null. Guess will it be true or false? But the right answer is: It depends… And now I’ll tell you why.

T-SQL has a concept that unknown value NULL is not equal to another unknown value NULL. At the same time C# and Entity Framework believe that two nulls are equal. This comes from the reference types where null means that a pointer does not reference to any variable. So when 2 pointers are null, so they are equal, because they don’t reference to any variable.

To better understand the differences between Entity Framework and C# I created a simple test to compare values. Here is my C# project StringEqualityTest that you can download and run in your own pace.

The results are the following:

Left operand Right operand C# Entity Framework Explanation
“A” “A” true true Exact match
“B” “b” (lowercase) false true* EF uses SQL Server comparison rules
“B” “B ” (with trailing space) false true EF uses SQL Server comparison rules
“” “” (empty string) true true Exact match
null null true true EF uses C# rules
* – not always

Let’s look deeper into what’s going on.

When Entity Framework compares two not null strings, it applies rules defined in SQL Server. It seems that EF sends a query and merely receives the result from SQL Server. And all the rules come from SQL Server. That’s the reason why SQL Server discards trailing spaces (look at “B” = “B “). Also it uses a collation for comparison and ordering. In my case it’s a Cyrillic_General_CI_AS, CI means Case Insensitive, AS means Accent Sensitive. So “B” = “b”. If you have another collation, the result might be different.

Just compare these examples with C# rules where “B” <> “b”, and “B” <> “B “. C# always returns the same result.

But when EF compares null strings, it shows they are equal like C# do. To do this, EF generate a special query for SQL Server to receive the result in C# logic. When you look at SELECT command generated by EF, you’ll find something interesting.

EF adds a second condition when both operands are null. That’s why EF shows the result in C# style while SQL Server executes all the comparison as it did forever.

Entity Framework has a dedicated parameter that could change the null comparison logic to be implemented by SQL Server. In EF 6.0 it’s a UseDatabaseNullSemantics. When you set it to true (the default is false), you’ll get a SQL Server rules for null equality. Some previous versions of EF uses an opposite parameter UseCSharpNullComparisonBehavior.

This time the SQL query would not have an additional condition for nulls.

I’ve missed an important option that influence SQL behavor (thanks to Arthur Zubarev for his valuable comment). There’s an option ANSI_NULLS. If you set it to false, so SQL Server would think that nulls are equal. But you can hardly see it in action because SQL Server Native Client driver automatically set it to ON when connecting.

Calling SQL Server Stored Procedure With Table-Valued Parameter in C#

In one of my previous post I described how to use table-value parameter in T-SQL code. Today I will show how to use it in your .NET application.

This is a sample C# console application. The most important things you should pay attention to are the following:

  1. create DataTable with structure equivalent to table type defined in SQL database (in my case string for varchar(20), and Int16 for smallint)
  2. fill your DataTable with data
  3. add parameter to SqlCommand object with type SqlDbType.Structured
  4. assign DataTable to parameter’s Value property