If you’re using ASP.NET Core 3.1.1 and are seeing HTTP Error 500 when deploying your application into Azure App Service, there’s a high change that the issue is caused by a known issue:

If your project has a package reference that transtively references certain assemblies in the Microsoft.AspNetCore.App shared framework
that are also available as NuGet packages and executes on a runtime other than 64-bit Windows, you will receive a runtime exception at the time the assembly is loaded with a message like:

Could not load file or assembly 'Microsoft.AspNetCore.DataProtection.Abstractions, Version=3.1.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The located assembly's manifest definition does not match the assembly reference. (0x80131040)

 

Solution is to switch to 64 bit Azure App Service or to manually reference the problematic package.

Debugging this can be a pain as Azure App Service’s diagnostic tools think that everything is running smoothly and IIS’ stdout only reports that application has successfully started. What can help is wrapping the CreateWebHostBuilder inside a try-catch. Here’s an example which uses nLog:

        public static void Main(string[] args)
        {
            var environment = Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT");
            var isDev = string.Equals(environment, "development", StringComparison.InvariantCultureIgnoreCase);
            var configFileName = isDev ? "nlog.Development.config" : "nlog.config";

            var logger = NLogBuilder.ConfigureNLog(configFileName).GetCurrentClassLogger();

            logger.Info("Starting application. {Environment}, {LoggingConfigurationFileName}", environment, configFileName);

            try
            {
                CreateWebHostBuilder(args).Build().Run();
            }
            catch (Exception e)
            {
                logger.Error(e, "Failed to start application", e);
            }
            finally
            {
                NLog.LogManager.Shutdown();
            }
        }

There’s now a new version 2.0.0 of Adaptive Cards for Blazor available.

This update changes two things:

• It targets .NET Core 3.1 instead of .NET Core 3.0.
• It also updated Adaptive Cards SDK to the latest version.

There’s also some internal changes on how the package is created. This makes it easier to use the library with Blazor WebAssembly.

How to learn more about Adaptive Cards for Blazor

As before, the best way to start learning about Adaptive Cards for Blazor is the “Getting Started” –tutorial. There’s also a “Quick start” available.

There’s also more than 40 samples available which show you how to use features like Card Collections and how to handle submit actions in C#.

For the source code and current issues & feature requests, please see GitHub.

Last month I wrote about a new library called Blazor.Animate which aims to make it easier to add animations into Blazor Applications. There’s now a new version 2.0.0 available from NuGet.

The new version adds couple things:

• The library now targets .NET Core 3.1, which is a LTS-version of .NET Core.
• The library now works better with Blazor WebAssembly (thanks to Matthias Gernand)

The project repository now contains a new WebAssembly sample. 

Background

If you’re new to Blazor.Animate, here’s a quick introduction to the library. Blazor.Animate is a Blazor Component which allows you to animate how other components are brought into the view. The library is powered by AOS.

To animate a component, wrap it inside Animate-component and use the Animation-parameter to define the animation:

<Animate Animation="Animations.ZoomIn" Duration="TimeSpan.FromSeconds(0.5)" >
    <Counter></Counter>
</Animate>

The library currently supports the following animations:

• Fade
• FadeIn
• FadeUp
• FadeDown
• FadeLeft
• FadeRight
• FadeUpRight
• FadeUpLeft
• FadeDownRight
• FadeDownLeft
• FlipUp
• FlipDown
• FlipLeft
• FlipRight
• SlideUp
• SlideDown
• SlideLeft
• SlideRight
• ZoomIn
• ZoomInUp
• ZoomInDown
• ZoomInLeft
• ZoomInRight
• ZoomOut
• ZoomOutUp
• ZoomOutDown
• ZoomOutLeft
• ZoomOutRight

Blazor.Animate is a new MIT-licensed Blazor-component which allows you to easily add fade, slide and zoom-effects into your Blazor applications. Blazor.Animate is powered by the AOS-library.

Blazor.Animate is available through Nuget. Its source code and project home can be found from GitHub.

What can it do?

With Blazor.Animate you can animate how other components are brought into the view.

How to use it?

To animate a component, wrap it inside Animate-component and use the Animation-parameter to define the animation:

    <Animate Animation="Animations.ZoomIn" Duration="TimeSpan.FromSeconds(0.5)" >
        <Counter></Counter>
    </Animate>

Is it really that easy?

Yes, after you have added the required Nuget-package and JSInterop. For guidance, please see the readme for a more throughout Getting Started guide: https://github.com/mikoskinen/Blazor.Animate

What animations are supported?

Here’s the built-in animations provided by Blazor.Animate:

• Fade
• FadeIn
• FadeUp
• FadeDown
• FadeLeft
• FadeRight
• FadeUpRight
• FadeUpLeft
• FadeDownRight
• FadeDownLeft
• FlipUp
• FlipDown
• FlipLeft
• FlipRight
• SlideUp
• SlideDown
• SlideLeft
• SlideRight
• ZoomIn
• ZoomInUp
• ZoomInDown
• ZoomInLeft
• ZoomInRight
• ZoomOut
• ZoomOutUp
• ZoomOutDown
• ZoomOutLeft
• ZoomOutRight

Are there any samples of these animations?

Blazor.Animate’s sample site contains a testbed-page which can be used to check all the animations: https://animateblazorsamplessvc.azurewebsites.net/testbed

Is that all?

There’s also easings. And default animations. And named animations. And anchoring.

All these are demonstrated in the sample and in the readme.

Did you do all the animations?

No. All the animations are provided by AOS.

Where to learn more?

The best way to learn more is to head to GitHub and to browse the source or the sample code. If you have any questions, please submit a GitHub issue on the repo.

Null conditional operator allows us to write more terse code. And unfortunately, more subtle bugs. The combination of Null Conditional Operator with Any() is easily my current favourite for The Winner of 2019’s Most Bugs Caused by a New C# Feature.

Combining Null Conditional Operator ?. with System.Linq.Enumerable.Any allows us to quickly check if our collection is not null AND not empty. So instead of writing this:

        public static void DoWork(List myWorkItems)
        {
            if (myWorkItems != null && myWorkItems.Any())
            {
                Console.WriteLine("Doing work");
                return;
            }

            Console.WriteLine("Nothing to do");
        }

We can use Null Conditional Operator and save few key strokes:

        public static void DoWork(List myWorkItems)
        {
            if (myWorkItems?.Any() == true)
            {
                Console.WriteLine("Doing work");
                return;
            }

            Console.WriteLine("Nothing to do");
        }

Maybe we could make the code even better, by reducing nesting by inverting the if:

        public static void DoWork(List myWorkItems)
        {
            if (myWorkItems?.Any() == false)
            {
                Console.WriteLine("Nothing to do");
                return;
            }

            Console.WriteLine("Doing work");
        }

Ah, no. Did you spot the bug?

If we expand the example, we get a better picture of the situation:

Why this happens? Because myWorkItems?.Any() doesn’t return false when the collection is null. It returns Nullable Boolean instead:

Getting around the issue is quite simple: Instead of checking for == false, we check for != true:

            if (myWorkItems?.Any() != true)
            {
                Console.WriteLine("Nothing to do");
                return;
            }

But do we always remember this? Based on the code I’ve seen this year the answer is quite simply no.

Maybe there’s a Roslyn Analyzer for spotting this automatically?