dotnet new gitignore

TLDR

The root cause of this error is that the boundary value was wrapped in double quotes in the media type header but was not wrapped in quotes in the request body. The solution was just to trim the double quotes from the boundary value.

Deeper Dive

Here's the content-type header value from the http request. Notice how the GUID is wrapped in double quotes.

multipart/form-data; boundary=\"8fee35ce-e3f2-4589-9992-d4871575effa\"

Here's the gist of the request body (binary data omitted). Notice how the same GUIDs lack the double quotes.

--8fee35ce-e3f2-4589-9992-d4871575effa
Content-Type: application/octet-stream
Content-Disposition: form-data; name=file; filename=foo.jpg; filename*=utf-8''foo.jpg

BINARY DATA
--8fee35ce-e3f2-4589-9992-d4871575effa--

I was using Microsoft.AspNetCore.WebUtilities.MultipartReader to read the http request body. Like so:

var reader = new MultipartReader(mediaTypeHeader.Boundary.Value, request.Body);

The exception was being thrown on this line directly below:

var section = await reader.ReadNextSectionAsync(cancellationToken);

The solution was to trim the double quotes from the boundary:

var reader = new MultipartReader(mediaTypeHeader.Boundary.Value.Trim('"'), request.Body);

public static class LiteDatabaseExtensions
{
    public static ILiteCollection<BsonDocument> GetCollectionByType(this ILiteDatabase database, Type type)
    {
        if (database == null)
        {
            throw new ArgumentNullException(nameof(database));
        }

        if (type == null)
        {
            throw new ArgumentNullException(nameof(type));
        }

        // We can use the database's built in BsonMapper to get the default collection name for the type.
        // This technique only works for collections that were resolved without custom names.
        // EX: var collection = database.GetCollection<T>();
        var collectionName = database.Mapper.ResolveCollectionName(type);
        var collection = database.GetCollection(collectionName);
        return collection;
    }
}

When loading a secure url (https) in Firefox, you see "Secure Connection Failed", "Error code: SEC_ERROR_INADEQUATE_KEY_USAGE".

The Solution

1. Go to about:profiles in Firefox. Do this by entering "about:profiles" in the address bar like a URL.
2. Locate the profile that is currently in use. This will be the profile that has no Remove button.
3. Click Open Folder in Root Directory.
4. Delete the cert9.db and cert_override.txt files. You may need to close Firefox to delete these files.
5. Try problematic url again. The problem should be resolved.

int a = 1;
int b = 0;
(a, b) = (b, a);

Evidently it's just as efficient as using a temporary variable as well. The generated IL (machine code) is exactly the same as if you used a temporary variable.

In the example below, there's a Button that is bound to a property named Save on view model. Save is an ICommand and the behavior of the button is to enable or disable itself based on whether or not the ICommand.CanExecute returns true or false. This sets the button's IsEnabled property, and thus we can set a binding on the button's Visibility property that changes when the button is enabled or disabled. Note that in the binding, a BooleanToVisibilityConverter is used to convert a boolean to a corresponding Visibility enum value.

<Button
    Command="{Binding Path=Save}"
    Content="Save"
    Visibility="{Binding RelativeSource={RelativeSource Mode=Self}, Path=IsEnabled, Converter={StaticResource BooleanToVisibilityConverter}}" />

TLDR

The TLDR is that you should add a CheckBox control to your DataTemplate and then bind the box's IsChecked property to the ListBoxItem.IsSelected property, using a relative source binding.

MainWindow.xaml

In this file, we've got a ListBox that is bound to an Items property on the Window. The ListBox's SelectionMode property has been set to Multiple to allow multiple items to be selected at a time. Additionally, the ListBox.ItemTemplate has been set to a custom DataTemplate which contains our CheckBox. The IsChecked property is bound to the IsSelected property of the ListBoxItem.

ListBox controls automatically create a ListBoxItem for every item provided in the ListBox.ItemsSource. Every ListBoxItem.IsSelected is kept in sync with the containing ListBox control and that IsSelected property can be modified to change what's selected within the ListBox.

By using a RelativeSource binding on our IsChecked property, we tell the CheckBox to crawl up the tree until the containing ListBoxItem is located (via the AncestorType). Once the item is located, we simply bind to the item's IsSelected property, effectively synchronizing our CheckBox.IsChecked state to the ListBoxItem.IsSelected state.

<Window x:Class="MultiSelectionSpike.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:local="clr-namespace:MultiSelectionSpike"
        d:DataContext="{d:DesignInstance local:MainWindow}"
        mc:Ignorable="d"
        Title="MainWindow" Height="450" Width="800">
    <ListBox ItemsSource="{Binding Path=Items}" SelectionMode="Multiple">
        <ListBox.ItemTemplate>
            <DataTemplate>
                <DockPanel>
                    <CheckBox IsChecked="{Binding RelativeSource={RelativeSource Mode=FindAncestor, AncestorType=ListBoxItem}, Path=IsSelected}" DockPanel.Dock="Left" />
                    <TextBlock Text="{Binding}" />
                </DockPanel>
            </DataTemplate>
        </ListBox.ItemTemplate>
    </ListBox>
</Window>

MainWindow.xaml.cs

A few points to note about this class. First, it defines the Items property that is used by the ItemsSource in our xaml. Next, it initializes a new collection with some sample items in it. Finally, it sets MainWindow's DataContext to itself, enabling the ItemsSource binding to work correctly.

using System.Collections.ObjectModel;

namespace MultiSelectionSpike
{
    /// <summary>
    ///     Interaction logic for MainWindow.xaml
    /// </summary>
    public partial class MainWindow
    {
        public MainWindow()
        {
            Items = new ObservableCollection<string> {"First", "Second", "Third"};
            InitializeComponent();
            DataContext = this;
        }

        public ObservableCollection<string> Items { get; }
    }
}

First, here's the code for the attached property that will be used in the demonstrations below. In this code, an attached property named Foo is defined within the Demonstration class. The attached property can be attached to any DependencyObject.

public static class Demonstration
{
    public static readonly DependencyProperty FooProperty = 
        DependencyProperty.RegisterAttached("Foo",
        typeof(string), typeof(Demonstration),
        new PropertyMetadata(default(string)));

    public static void SetFoo(DependencyObject element, string value)
    {
        element.SetValue(FooProperty, value);
    }

    public static string GetFoo(DependencyObject element)
    {
        return (string)element.GetValue(FooProperty);
    }
}

The example's DataContext has been set to this in the constructor.

DataContext = this;

In XAML

The code in this example will bind the Foo attached property to the Title property in XAML. Note that the namespace local is set to the DemoApp namespace. That's because the Demonstration class that defines the attached property is located there. In this case, no binding source has been provided, so the DataContext will be assumed as the binding source.

xmlns:local="clr-namespace:DemoApp"
Title="{Binding Path=(local:Demonstration.Foo)}"

In Code-Behind

Here's how to do the same thing in code-behind. This specific example assumes that this is a System.Windows.Controls.Page instance. Similarly, no source has been set on the binding, so the DataContext will act as the source.

var binding = new Binding
{
    Path = new PropertyPath("(0)", new object[] { Demonstration.FooProperty })
};
BindingOperations.SetBinding(this, Page.TitleProperty, binding);

Sometimes when you're serializing a C# class to JSON, you want to include polymorphic properties in the JSON output. If you're using System.Text.Json (version 4.0.1.0 or lower) to do the serialization, this won't happen automatically. Consider the following code below for an example.

public class Chart
{
    public ChartOptions Options { get; set; }
}

public abstract class ChartOptions
{
    public bool ShowLegend { get; set; }
}

public class LineChartOptions : ChartOptions
{
    public IEnumerable<Color> DefaultLineColors { get; set; }
}

In the above code, we have a class that describes a Chart and that chart has a property with some Options. The property's type is ChartOptions, which is a base class that is common to all the different types of charts. There's a LineChartOptions class that inherits from ChartOptions and includes an additional property called DefaultLineColors that defines some colors for the lines of the line chart.

Chart chart = new Chart
{
    Options = new LineChartOptions
    {
        DefaultLineColors = new [] { Color.Red, Color.Purple, Color.Blue }
    }
};
string json = JsonSerializer.Serialize(chart);

The value of json will be {"Options":{"ShowLegend":false}}. Note that it's missing the DefaultLineColors property. Why is that happening? It's because the behavior of JsonSerializer is to only serialize members of the types that are defined in the object hierarchy at compile time. In other words, the serializer looks at the Chart class and sees that the type of the Options property is ChartOptions, so it looks at the ChartOptions class's members and only sees ShowLegend, so that's the only thing that it serializes, even though the instance of the object inside of the Options property might be a subclass of ChartOptions that includes additional properties.

Solution

So how do we get it to serialize all of the properties, including those defined in subtypes? Unfortunately, there's not a great answer to that question at the time of this writing. There are active discussions and complaints about this missing functionality on GitHub. The best solution I've found thus far (aside from switching back to Newtonsoft.Json for serialization) is to use a customer JsonConverter<T>. An example of one such converter is below. Please note that deserialization has not been implemented.

public class PolymorphicJsonConverter<T> : JsonConverter<T>
{
    public override bool CanConvert(Type typeToConvert)
    {
        return typeof(T).IsAssignableFrom(typeToConvert);
    }

    public override T Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
    {
        throw new NotImplementedException();
    }

    public override void Write(Utf8JsonWriter writer, T value, JsonSerializerOptions options)
    {
        if (value is null)
        {
            writer.WriteNullValue();
            return;
        }

        writer.WriteStartObject();
        foreach (var property in value.GetType().GetProperties())
        {
            if (!property.CanRead)
                continue;
            var propertyValue = property.GetValue(value);
            writer.WritePropertyName(property.Name);
            JsonSerializer.Serialize(writer, propertyValue, options);
        }
        writer.WriteEndObject();
    }
}

Here's how to apply it.

Chart chart = new Chart
{
    Options = new LineChartOptions
    {
        DefaultLineColors = new[] { Color.Red, Color.Purple, Color.Blue }
    }
};
var options = new JsonSerializerOptions();
options.Converters.Add(new PolymorphicJsonConverter<ChartOptions>());
string json = JsonSerializer.Serialize(chart, options);
return JsonSerializer.Serialize(this, s_serializerOptions);

The PolymorphicJsonConverter<T> is a generic type and an instance of that converter must be added to the JsonSerializerOptions for every root type in your inheritance hierarchy. For example, if you want to support polymorphic serialization for class Baz that inherits from class Bar that inherits from class Foo, then you'd need to add an instance of PolymoprhicJsonConverter<Foo> to your serializer options.

Here's the correct JSON that was generated from the example above that uses PolymorphicJsonConverter<T>.

{
    "Options":{
        "DefaultLineColors":[
            {
                "R":255,
                "G":0,
                "B":0,
                "A":255,
                "IsKnownColor":true,
                "IsEmpty":false,
                "IsNamedColor":true,
                "IsSystemColor":false,
                "Name":"Red"
            },
            {
                "R":128,
                "G":0,
                "B":128,
                "A":255,
                "IsKnownColor":true,
                "IsEmpty":false,
                "IsNamedColor":true,
                "IsSystemColor":false,
                "Name":"Purple"
            },
            {
                "R":0,
                "G":0,
                "B":255,
                "A":255,
                "IsKnownColor":true,
                "IsEmpty":false,
                "IsNamedColor":true,
                "IsSystemColor":false,
                "Name":"Blue"
            }
        ],
        "ShowLegend":false
    }
}

I was recently trying to run a unit test containing a WPF class and received the following error during test execution: "System.InvalidOperationException: 'The calling thread must be STA, because many UI components require this.'" This exception was thrown when I tried to instantiate a class that was derived from System.Windows.Controls.UserControl. It's complaining because only STA threads can create those types of classes and my unit test isn't an STA thread.

I did some Googling and just about every result that appeared was for NUnit, but I'm using MSTest (MSTest.TestFramework), so I needed a solution for that framework specifically.

Solution

The solution was actually really simple when I found this link. I created a WpfTestMethodAttribute class and then applied it to my unit tests.

Here's the WpfTestMethodAttribute. It is used instead of the normal TestMethodAttribute that MSTest provides.

public class WpfTestMethodAttribute : TestMethodAttribute
{
    public override TestResult[] Execute(ITestMethod testMethod)
    {
        if (Thread.CurrentThread.GetApartmentState() == ApartmentState.STA)
            return Invoke(testMethod);

        TestResult[] result = null;
        var thread = new Thread(() => result = Invoke(testMethod));
        thread.SetApartmentState(ApartmentState.STA);
        thread.Start();
        thread.Join();
        return result;
    }

    private TestResult[] Invoke(ITestMethod testMethod)
    {
        return new[] { testMethod.Invoke(null) };
    }
}

Here's a quick and dirty example of the attribute in use.

[TestClass]
public class MyTestClass
{
    [WpfTestMethod]
    public void MyWpfTest()
    {
        // The following line will fail unless executed on an STA thread.
        var userControl = new UserControl();
        Assert.IsNotNull(userControl);
    }
}

I was working on a custom WPF control recently and spent several hours trying to figure out why the bindings on my custom dependency properties weren't functioning correctly. The control was initially displayed in a Collapsed visibility state but then later became visible after user interaction. Within that control, I had some content that I wanted to display, but I wanted the content's color to be inherited from a parent control.

This problem only occured when the custom control was initially rendered with a Collapsed visibility. If the control started out as Visible or even Hidden, the bindings worked as expected.

The following is a derived, and greatly simplified example to illustrate the problem I was having. Please keep in mind that this coding style does not reflect best practices for production quality code. In this example, we have a Window that appears with a button in the middle of the screen that says "Click me." We have a custom FooteredContentControl that should appear when the user clicks the button. The custom control should have text that says "Body" in the main Content property, and then we want to see an icon of a foot in the Footer property. Oh, and we want them both to inherit the hot pink color from the window.

The xaml below defines the MainWindow layout.

<Window
    x:Class="WpfApp1.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:local="clr-namespace:WpfApp1"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    Title="MainWindow"
    Width="800"
    Height="450"
    Foreground="HotPink"
    mc:Ignorable="d">
    <Window.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="FooteredContentControl.xaml" />
            </ResourceDictionary.MergedDictionaries>
            <PathGeometry x:Key="PathGeometryFoot" Figures="M16 2A2 2 0 1 1 14 4A2 2 0 0 1 16 2M12.04 3A1.5 1.5 0 1 1 10.54 4.5A1.5 1.5 0 0 1 12.04 3M9.09 4.5A1 1 0 1 1 8.09 5.5A1 1 0 0 1 9.09 4.5M7.04 6A1 1 0 1 1 6.04 7A1 1 0 0 1 7.04 6M14.53 12A2.5 2.5 0 0 0 17 9.24A2.6 2.6 0 0 0 14.39 7H11.91A6 6 0 0 0 6.12 11.4A2 2 0 0 0 6.23 12.8A6.8 6.8 0 0 1 6.91 15.76A6.89 6.89 0 0 1 6.22 18.55A1.92 1.92 0 0 0 6.3 20.31A3.62 3.62 0 0 0 10.19 21.91A3.5 3.5 0 0 0 12.36 16.63A2.82 2.82 0 0 1 11.91 15S11.68 12 14.53 12Z" />
        </ResourceDictionary>
    </Window.Resources>
    <DockPanel>
        <local:FooteredContentControl
            x:Name="Control"
            DockPanel.Dock="Top"
            Visibility="Collapsed">
            <local:FooteredContentControl.Footer>
                <Path
                    Width="20"
                    Height="20"
                    Data="{StaticResource PathGeometryFoot}"
                    Fill="{Binding RelativeSource={RelativeSource Mode=FindAncestor, AncestorType=Window}, Path=Foreground}"
                    Stretch="Uniform" />
            </local:FooteredContentControl.Footer>
            <TextBlock Text="Body" />
        </local:FooteredContentControl>
        <Button
            HorizontalAlignment="Center"
            VerticalAlignment="Center"
            Click="VisibilityToggle_Click"
            Content="Click Me" />
    </DockPanel>
</Window>

Here's the code-behind that drives MainWindow class behavior.

using System.Windows;

namespace WpfApp1
{
    /// <summary>
    /// Interaction logic for MainWindow.xaml
    /// </summary>
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
        }

        private void VisibilityToggle_Click(object sender, RoutedEventArgs e)
        {
            Control.Visibility = Control.Visibility == Visibility.Visible ?
                Visibility.Collapsed : Visibility.Visible;
        }
    }
}

The FooteredContentControl is the custom control that we're having problems with. It is defined below.

using System.Windows;
using System.Windows.Controls;

namespace WpfApp1
{
    public class FooteredContentControl : ContentControl
    {
        public static readonly DependencyProperty FooterProperty =
            DependencyProperty.Register("Footer", typeof(object), typeof(FooteredContentControl),
                new FrameworkPropertyMetadata(null));

        static FooteredContentControl()
        {
            DefaultStyleKeyProperty.OverrideMetadata(typeof(FooteredContentControl),
                new FrameworkPropertyMetadata(typeof(FooteredContentControl)));
        }

        public object Footer
        {
            get { return GetValue(FooterProperty); }
            set { SetValue(FooterProperty, value); }
        }
    }
}

Here's the style for the FooteredContentControl that defines the visual layout.

<ResourceDictionary
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="clr-namespace:WpfApp1">
    <Style x:Key="{x:Type local:FooteredContentControl}" TargetType="{x:Type local:FooteredContentControl}">
        <Setter Property="Template">
            <Setter.Value>
                <ControlTemplate TargetType="{x:Type local:FooteredContentControl}">
                    <StackPanel>
                        <ContentPresenter />
                        <ContentPresenter ContentSource="Footer" />
                    </StackPanel>
                </ControlTemplate>
            </Setter.Value>
        </Setter>
    </Style>
</ResourceDictionary>

Everything else is standard, out-of-the-box WPF project files.

In the example above, we click the button and only the word "Body" shows up but we don't see any feet. After snooping around with debugging tools, you can see that the Path with the feet is actually there, but it's just not visible because the Binding in the path's Fill is not being evaluated correctly. Thus, the Fill which defines the color is set to null, rendering the feet effectively transparent. To solve this problem, the issue with the binding needs to be addressed.

Solution

The solution was to make the value of my custom dependency property part of the logical tree. To accomplish this, a property changed callback was added to the FooterProperty and that callback method then invokes RemoveLogicalChild and AddLogicalChild to ensure that any footer content is added to the logical tree. This allows the relative binding to work as expected.

using System.Windows;
using System.Windows.Controls;

namespace WpfApp1
{
    public class FooteredContentControl : ContentControl
    {
        public static readonly DependencyProperty FooterProperty =
            DependencyProperty.Register("Footer", typeof(object), typeof(FooteredContentControl),
                new FrameworkPropertyMetadata(null, new PropertyChangedCallback(OnFooterPropertyChanged)));

        static FooteredContentControl()
        {
            DefaultStyleKeyProperty.OverrideMetadata(typeof(FooteredContentControl),
                new FrameworkPropertyMetadata(typeof(FooteredContentControl)));
        }

        public object Footer
        {
            get { return GetValue(FooterProperty); }
            set { SetValue(FooterProperty, value); }
        }

        /// <summary>
        /// This called by the dependency property when its value has changed.
        /// </summary>
        /// <remarks>
        /// This is what was added to fix the bug
        /// that prevented the Footer content from showing
        /// when this control first appears in Collapsed
        /// visibility.
        /// </remarks>
        /// <param name="d"></param>
        /// <param name="e"></param>
        private static void OnFooterPropertyChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
        {
            var control = (FooteredContentControl)d;

            // The following methods are provided by the FrameworkElement base class.

            // Removes any old content from the logical tree.
            control.RemoveLogicalChild(e.OldValue);
            // Adds new content to the logical tree.
            control.AddLogicalChild(e.NewValue);
        }
    }
}

The demo code will now show the feet icon when the user clicks the button.

There are at least a couple of ways to execute fire and forget tasks. The first way is by running the task with a continuation. Here's how that's done.

static void FireAndForgetExample1(Task taskToForget)
{
    _ = taskToForget.ContinueWith(t =>
    {
        if (t.IsFaulted)
        {
            // Log the exception.
        }
    });
}

The previous example uses ContinueWith which was popular before the async and await keywords were introduced. It's now preferred to use the new key words instead of the older continuation style. Here are a couple of reasons why:

• It's easier to debug: The await keyword creates a state machine when your code is compiled and that state machine aids in your debugging.
• It's optimized: As mentioned above, the await keyword creates a state machine that is optimized for execution and can continue to be optimized in the future. One such optimization is that completed tasks return immediately. Conversely, ContinueWith is less efficient because it must allocate a continuation task for each continuation.

Here's how to execute fire and forget tasks using a local function, which takes advantage of the async and await keywords.

static void FireAndForgetExample2(Task taskToForget)
{
    async Task Forget(Task task)
    {
        try
        {
            await task;
        }
        catch (Exception ex)
        {
            // Log the exception.
        }
    }
    _ = Forget(taskToForget);
}

Version Property

The most straightforward and popular approach is simply to use the Version property from the assembly's name. This can be set by right-clicking on the project and setting the Assembly version within the project's properties. In a .NET Framework app, this is found under the Application -> Assembly Information section of the project's properties, while in .NET Core, it can be found in the Package section of the project's properties.

Here's how you can read the value in code.

// Retrieve the assembly that contains this code.
// If this code lives in a DLL, you might want to use
// Assembly.GetEntryAssembly() instead.
var assembly = Assembly.GetExecutingAssembly();
// Get the version from the assembly.
var version = assembly.GetName().Version.ToString();

AssemblyInformationalVersionAttribute

Sometimes you might want to describe your version as a string instead of a series of octets. For example, maybe your version is "2.0.0-alpha.3". If you want to describe your version in this way, then you won't be able to use the Version property mentioned above because it limits you to four integer octets, like "3.0.1.0".

The AssemblyInformationalVersionAttribute can be used to specify a string with version info. This will display a warning if the string is not in the format that is used by the assembly's version number, or if the string contains wildcard characters, but the warning can be ignored.

// Retrieve the assembly that contains this code.
// If this code lives in a DLL, you might want to use
// Assembly.GetEntryAssembly() instead.
var assembly = Assembly.GetExecutingAssembly();
// Search the assembly attributes for the informational
// version number and return the first one found or
// null if none were found for this assembly.
var version = assembly
    .GetCustomAttributes<AssemblyInformationalVersionAttribute>()
    .Select(x => x.InformationalVersion)
    .FirstOrDefault();

.NET Framework

If your application runs on the traditional .NET Framework, then you'll want to ensure that you have the attribute added to the AssemblyInfo.cs file.

using System.Reflection;

[assembly: AssemblyInformationalVersion("1.0.0-alpha.4")]

.NET Core

If you're using .NET Core, the AssemblyInformationalVersionAttribute is automatically added and is based on the <Version></Version> element in the csproj file.

<PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <UseWPF>true</UseWPF>
    <LangVersion>8.0</LangVersion>
    <Nullable>enable</Nullable>
    <!-- This populates the AssemblyInformationalVersionAttribute -->
    <Version>1.0.0-alpha.4</Version>
</PropertyGroup>

If your application still explicitly defines an AssemblyInformationalVersionAttribute inside of your .NET Core project, then you'll get an error that states "Duplicate 'System.Reflection.AssemblyInformationalVersionAttribute' attribute". The easy way to resolve this is just to delete the attribute from your code (typically located in AssemblyInfo.cs) and just use the <Version></Version> xml element inside of your csproj instead.

dotnet ef migrations add Initial -o Model\Migrations

Note that you'll only need to specify the output argument for the first migration. Entity Framework Core is smart enough to put future migrations in the correct folder.

Add

The Action is NotifyCollectionChangedAction.Add when items are added to the collection.

Remove

The Action is NotifyCollectionChangedAction.Remove when items are removed from the collection.

Replace

The Action is NotifyCollectionChangedAction.Replace when old items are replaced with new items.

Move

The Action is NotifyCollectionChangedAction.Move when one or more items are moved within the collection. This operation is logically treated as a Remove followed by an Add, so NewStartIndex is interpreted as though the items had already been removed.

Reset

The Action is NotifyCollectionChangedAction.Reset when a collection is completely reset. None of the properties in the event args will have values.