Enable markdownlint check in CI

.github/workflows/markdownlint-problem-matcher.json

@@ -0,0 +1,17 @@
+{
+    "problemMatcher": [
+        {
+            "owner": "markdownlint",
+            "pattern": [
+                {
+                    "regexp": "^([^:]*):(\\d+):?(\\d+)?\\s([\\w-\\/]*)\\s(.*)$",
+                    "file": 1,
+                    "line": 2,
+                    "column": 3,
+                    "code": 4,
+                    "message": 5
+                }
+            ]
+        }
+    ]
+}

.github/workflows/markdownlint.yml

@@ -0,0 +1,20 @@
+name: Markdownlint
+
+on: pull_request
+
+jobs:
+  lint:
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v2
+    - name: Use Node.js
+      uses: actions/setup-node@v1
+      with:
+        node-version: 12.x
+
+    - name: Run Markdownlint
+      run: |
+        echo "::add-matcher::.github/workflows/markdownlint-problem-matcher.json"
+        npm i -g markdownlint-cli
+        markdownlint "**/*.md" -i "entity-framework/ef6/"

.markdownlint.json

@@ -1,6 +1,10 @@
 {
     "default": true,
     "MD013": false,
+    "MD024": false,
     "MD025": { "front_matter_title": "" },
-    "MD033": { "allowed_elements": ["sup", "sub", "nobr", "span"] }
+    "MD027": false,
+    "MD028": false,
+    "MD033": { "allowed_elements": ["sup", "sub", "nobr", "span", "a"] },
+    "MD036": false
 }

README.md

@@ -1,12 +1,12 @@
-## Entity Framework Docs
+# Entity Framework Docs
 
-This project contains the source for EF Core and EF6 documentation located at [docs.microsoft.com/ef](https://docs.microsoft.com/ef/). 
+This project contains the source for EF Core and EF6 documentation located at [docs.microsoft.com/ef](https://docs.microsoft.com/ef/).
 
 Documentation issues for both EF Core and EF6 should be filed in this repo. Product issues (bugs) should be filed in the [EF Core repo](https://github.com/dotnet/efcore) or the [EF6 repo](https://github.com/dotnet/ef6) as appropriate.
 
 **We accept pull requests!**
 
-## Fixing typos/spelling/grammar/etc.
+## Fixing typos/spelling/grammar/etc
 
 Consider sending a pull request rather than filing an issue. This can be done entirely from the web:
 

entity-framework/core/extensions/index.md

@@ -78,13 +78,13 @@ Geco (Generator Console) is a simple code generator based on a console project,
 
 [GitHub repository](https://github.com/iQuarc/Geco)
 
-### EntityFrameworkCore.Scaffolding.Handlebars 
+### EntityFrameworkCore.Scaffolding.Handlebars
 
 Allows customization of classes reverse engineered from an existing database using the Entity Framework Core toolchain with Handlebars templates. For EF Core: 2, 3.
 
 [GitHub repository](https://github.com/TrackableEntities/EntityFrameworkCore.Scaffolding.Handlebars)
 
-### NeinLinq.EntityFrameworkCore 
+### NeinLinq.EntityFrameworkCore
 
 NeinLinq extends LINQ providers such as Entity Framework to enable reusing functions, rewriting queries, and building dynamic queries using translatable predicates and selectors. For EF Core: 2, 3.
 
@@ -138,14 +138,12 @@ Allow full-featured Entity Framework Core queries against [SQL Server Temporal H
 
 [GitHub repository](https://github.com/VantageSoftware/EFCore.TimeTraveler)
 
-
 ### EntityFrameworkCore.TemporalTables
 
 Extension library for Entity Framework Core which allows developers who use SQL Server to easily use temporal tables. For EF Core: 2.
 
 [GitHub repository](https://github.com/findulov/EntityFrameworkCore.TemporalTables)
 
-
 ### EntityFrameworkCore.Cacheable
 
 A high-performance second-level query cache. For EF Core: 2.

entity-framework/core/get-started/wpf.md

@@ -19,9 +19,7 @@ The screen shots and code listings in this walkthrough are taken from Visual Stu
 
 ## Pre-Requisites
 
-* You need to have Visual Studio 2019 16.3 or later installed with the **.NET desktop workload** selected to complete this walkthrough.
-
-    For more information about installing the latest version of Visual Studio, see [Install Visual Studio](/visualstudio/install/install-visual-studio).
+You need to have Visual Studio 2019 16.3 or later installed with the **.NET desktop workload** selected to complete this walkthrough. For more information about installing the latest version of Visual Studio, see [Install Visual Studio](/visualstudio/install/install-visual-studio).
 
 ## Create the Application
 
@@ -45,7 +43,7 @@ The screen shots and code listings in this walkthrough are taken from Visual Stu
 1. Repeat the steps to search for `entityframeworkcore.proxies` and install **Microsoft.EntityFrameworkCore.Proxies**.
 
 > [!NOTE]
-> When you installed the Sqlite package, it automatically pulled down the related **Microsoft.EntityFrameworkCore** base package. The **Microsoft.EntityFrameworkCore.Proxies** package provides support for "lazy-loading" data. This means when you have entities with child entities, only the parents are fetched on the initial load. The proxies detect when an attempt to access the child entities is made and automatically loads them on demand. 
+> When you installed the Sqlite package, it automatically pulled down the related **Microsoft.EntityFrameworkCore** base package. The **Microsoft.EntityFrameworkCore.Proxies** package provides support for "lazy-loading" data. This means when you have entities with child entities, only the parents are fetched on the initial load. The proxies detect when an attempt to access the child entities is made and automatically loads them on demand.
 
 ## Define a Model
 
@@ -91,7 +89,7 @@ The **Products** property on the **Category** class and **Category** property on
 
 EF Core gives you an option of loading related entities from the database automatically the first time you access the navigation property. With this type of loading (called lazy loading), be aware that the first time you access each navigation property a separate query will be executed against the database if the contents are not already in the context.
 
-When using "Plain Old C# Object" (POCO) entity types, EF Core achieves lazy loading by creating instances of derived proxy types during runtime and then overriding virtual properties in your classes to add the loading hook. To get lazy loading of related objects, you must declare navigation property getters as **public** and **virtual** (**Overridable** in Visual Basic), and your class must not be **sealed** (**NotOverridable** in Visual Basic). When using Database First, navigation properties are automatically made virtual to enable lazy loading. 
+When using "Plain Old C# Object" (POCO) entity types, EF Core achieves lazy loading by creating instances of derived proxy types during runtime and then overriding virtual properties in your classes to add the loading hook. To get lazy loading of related objects, you must declare navigation property getters as **public** and **virtual** (**Overridable** in Visual Basic), and your class must not be **sealed** (**NotOverridable** in Visual Basic). When using Database First, navigation properties are automatically made virtual to enable lazy loading.
 
 ## Bind Object to Controls
 

entity-framework/core/get-started/xamarin.md

@@ -70,11 +70,11 @@ It is assumed that you are familiar with the Xamarin.Forms topics of [displaying
 
 > [!IMPORTANT]
 > Entity Framework Core uses reflection to invoke functions which the Xamarin.iOS linker may strip out while in **Release** mode configurations. You can avoid that in one of two ways.
-> 
+>
 > * The first is to add `--linkskip System.Core` to the **Additional mtouch arguments** in the **iOS Build** options.
 > * Alternatively set the Xamarin.iOS **Linker behavior** to `Don't Link` in the **iOS Build** options.
 > [This article explains more about the Xamarin.iOS linker](/xamarin/ios/deploy-test/linker) including how to set the behavior on Xamarin.iOS.
-> 
+>
 
 ## Entity Framework Core NuGet packages
 

entity-framework/core/index.md

@@ -45,16 +45,16 @@ Data is created, deleted, and modified in the database using instances of your e
 
 While EF Core is good at abstracting many programming details, there are some best practices applicable to any ORM that help to avoid common pitfalls in production apps:
 
- - Intermediate-level knowledge or higher of the underlying database server is essential to architect, debug, profile, and migrate data in high performance production apps. For example, knowledge of primary and foreign keys, constraints, indexes, normalization, DML and DDL statements, data types, profiling, etc.
-- Functional and integration testing:  It's important to replicate the production environment as closely as possible to:
-  - Find issues in the app that only show up when using a specific versions or edition of the database server .
-  - Catch breaking changes when upgrading EF Core and other dependencies. For example, adding or upgrading frameworks like ASP.NET Core, OData, or Automapper. These dependencies can affect EF Core in unexpected ways.
-- Performance and stress testing with representative loads. The naïve usage of some features doesn't scale well. For example, multiple collections Includes, heavy use of lazy loading, conditional queries on non-indexed columns, massive updates and inserts with store-generated values, lack of concurrency handling, large models, inadequate cache policy.
-- Security review: For example, handling of connection strings and other secrets, database permissions for non-deployment operation, input validation for raw SQL, encryption for sensitive data.
-- Make sure logging and diagnostics are sufficient and usable. For example, appropriate logging configuration, query tags, and Application Insights.
-- Error recovery. Prepare contingencies for common failure scenarios such as version rollback, fallback servers, scale-out and load balancing, DoS mitigation, and data backups.
-- Application deployment and migration. Plan out how migrations are going to be applied during deployment; doing it at application start can suffer from concurrency issues and requires higher permissions than necessary for normal operation. Use staging to facilitate recovery from fatal errors during migration. For more information, see [Applying Migrations](xref:core/managing-schemas/migrations/applying).
-- Detailed examination and testing of generated migrations. Migrations should be thoroughly tested before being applied to production data. The shape of the schema and the column types cannot be easily changed once the tables contain production data. For example, on SQL Server, `nvarchar(max)` and `decimal(18, 2)` are rarely the best types for columns mapped to string and decimal properties, but those are the defaults that EF uses because it doesn't have knowledge of your specific scenario.
+* Intermediate-level knowledge or higher of the underlying database server is essential to architect, debug, profile, and migrate data in high performance production apps. For example, knowledge of primary and foreign keys, constraints, indexes, normalization, DML and DDL statements, data types, profiling, etc.
+* Functional and integration testing:  It's important to replicate the production environment as closely as possible to:
+  * Find issues in the app that only show up when using a specific versions or edition of the database server .
+  * Catch breaking changes when upgrading EF Core and other dependencies. For example, adding or upgrading frameworks like ASP.NET Core, OData, or Automapper. These dependencies can affect EF Core in unexpected ways.
+* Performance and stress testing with representative loads. The naïve usage of some features doesn't scale well. For example, multiple collections Includes, heavy use of lazy loading, conditional queries on non-indexed columns, massive updates and inserts with store-generated values, lack of concurrency handling, large models, inadequate cache policy.
+* Security review: For example, handling of connection strings and other secrets, database permissions for non-deployment operation, input validation for raw SQL, encryption for sensitive data.
+* Make sure logging and diagnostics are sufficient and usable. For example, appropriate logging configuration, query tags, and Application Insights.
+* Error recovery. Prepare contingencies for common failure scenarios such as version rollback, fallback servers, scale-out and load balancing, DoS mitigation, and data backups.
+* Application deployment and migration. Plan out how migrations are going to be applied during deployment; doing it at application start can suffer from concurrency issues and requires higher permissions than necessary for normal operation. Use staging to facilitate recovery from fatal errors during migration. For more information, see [Applying Migrations](xref:core/managing-schemas/migrations/applying).
+* Detailed examination and testing of generated migrations. Migrations should be thoroughly tested before being applied to production data. The shape of the schema and the column types cannot be easily changed once the tables contain production data. For example, on SQL Server, `nvarchar(max)` and `decimal(18, 2)` are rarely the best types for columns mapped to string and decimal properties, but those are the defaults that EF uses because it doesn't have knowledge of your specific scenario.
 
 ## Next steps
 

entity-framework/core/managing-schemas/migrations/applying.md

@@ -77,6 +77,7 @@ The following generates a SQL script from the specified `from` migration to the
 ```powershell
 Script-Migration AddNewTables AddAuditTable
 ```
+
 You can use a `from` that is newer than the `to` in order to generate a rollback script. *Please take note of potential data loss scenarios.*
 
 ***
@@ -92,13 +93,13 @@ The SQL scripts generated above can only be applied to change your schema from o
 
 The following generates idempotent migrations:
 
-#### [.NET Core CLI](#tab/dotnet-core-cli)
+### [.NET Core CLI](#tab/dotnet-core-cli)
 
 ```dotnetcli
 dotnet ef migrations script --idempotent
 ```
 
-#### [Visual Studio](#tab/vs)
+### [Visual Studio](#tab/vs)
 
 ```powershell
 Script-Migration -Idempotent

entity-framework/core/managing-schemas/migrations/index.md

@@ -66,6 +66,7 @@ At this point you can have EF create your database and create your schema from t
 ```dotnetcli
 dotnet ef database update
 ```
+
 #### [Visual Studio](#tab/vs)
 
 ```powershell
@@ -116,6 +117,7 @@ You can now apply your migration as before:
 ```dotnetcli
 dotnet ef database update
 ```
+
 #### [Visual Studio](#tab/vs)
 
 ```powershell

entity-framework/core/miscellaneous/events/simple-logging.md

@@ -196,15 +196,15 @@ The default content from `LogTo` is formatted across multiple lines. The first l
 For example:
 
 ```output
-info: 10/6/2020 10:52:45.581 RelationalEventId.CommandExecuted[20101] (Microsoft.EntityFrameworkCore.Database.Command) 
+info: 10/6/2020 10:52:45.581 RelationalEventId.CommandExecuted[20101] (Microsoft.EntityFrameworkCore.Database.Command)
       Executed DbCommand (0ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
       CREATE TABLE "Blogs" (
           "Id" INTEGER NOT NULL CONSTRAINT "PK_Blogs" PRIMARY KEY AUTOINCREMENT,
           "Name" INTEGER NOT NULL
       );
-dbug: 10/6/2020 10:52:45.582 RelationalEventId.TransactionCommitting[20210] (Microsoft.EntityFrameworkCore.Database.Transaction) 
+dbug: 10/6/2020 10:52:45.582 RelationalEventId.TransactionCommitting[20210] (Microsoft.EntityFrameworkCore.Database.Transaction)
       Committing transaction.
-dbug: 10/6/2020 10:52:45.585 RelationalEventId.TransactionCommitted[20202] (Microsoft.EntityFrameworkCore.Database.Transaction) 
+dbug: 10/6/2020 10:52:45.585 RelationalEventId.TransactionCommitted[20202] (Microsoft.EntityFrameworkCore.Database.Transaction)
       Committed transaction.
 ```
 
@@ -229,15 +229,15 @@ By default, timestamnps are designed for local consumption while debugging. Use
 This example results in the following log formatting:
 
 ```output
-info: 2020-10-06T17:55:39.0333701Z RelationalEventId.CommandExecuted[20101] (Microsoft.EntityFrameworkCore.Database.Command) 
+info: 2020-10-06T17:55:39.0333701Z RelationalEventId.CommandExecuted[20101] (Microsoft.EntityFrameworkCore.Database.Command)
       Executed DbCommand (0ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
       CREATE TABLE "Blogs" (
           "Id" INTEGER NOT NULL CONSTRAINT "PK_Blogs" PRIMARY KEY AUTOINCREMENT,
           "Name" INTEGER NOT NULL
       );
-dbug: 2020-10-06T17:55:39.0333892Z RelationalEventId.TransactionCommitting[20210] (Microsoft.EntityFrameworkCore.Database.Transaction) 
+dbug: 2020-10-06T17:55:39.0333892Z RelationalEventId.TransactionCommitting[20210] (Microsoft.EntityFrameworkCore.Database.Transaction)
       Committing transaction.
-dbug: 2020-10-06T17:55:39.0351684Z RelationalEventId.TransactionCommitted[20202] (Microsoft.EntityFrameworkCore.Database.Transaction) 
+dbug: 2020-10-06T17:55:39.0351684Z RelationalEventId.TransactionCommitted[20202] (Microsoft.EntityFrameworkCore.Database.Transaction)
       Committed transaction.
 ```
 

entity-framework/core/miscellaneous/testing/in-memory.md

@@ -15,9 +15,10 @@ uid: core/miscellaneous/testing/in-memory
 > [!TIP]
 > SQLite is a relational provider and can also use in-memory databases.
 > Consider using this for testing to more closely match common relational database behaviors.
-> This is covered in [Using SQLite to test an EF Core application](xref:core/miscellaneous/testing/sqlite).   
+> This is covered in [Using SQLite to test an EF Core application](xref:core/miscellaneous/testing/sqlite).
 
 The information on this page now lives in other locations:
+
 * See [Testing code that uses EF Core](xref:core/miscellaneous/testing/index) for general information on testing with the EF in-memory database.
 * See [Sample showing how to test applications that use EF Core](xref:core/miscellaneous/testing/testing-sample) for a sample using the EF in-memory database.
 * See [The EF in-memory database provider](xref:core/providers/in-memory/index) for general information about the EF in-memory database.

entity-framework/core/miscellaneous/testing/sharing-databases.md

@@ -21,6 +21,7 @@ This allows a single SQL Server database to be created and seeded only once for
 It's not difficult to write multiple tests against the same database.
 The trick is doing it in a way that the tests don't trip over each other as they run.
 This requires understanding:
+
 * How to safely share objects between tests
 * When the test framework runs tests in parallel
 * How to keep the database in a clean state for every test  
@@ -39,8 +40,9 @@ Here's what it looks like:
 [!code-csharp[SharedDatabaseFixture](../../../../samples/core/Miscellaneous/Testing/ItemsWebApi/SharedDatabaseTests/SharedDatabaseFixture.cs?name=SharedDatabaseFixture)]
 
 For now, notice how the constructor:
+
 * Creates a single database connection for the lifetime of the fixture
-* Creates and seeds that database by calling the `Seed` method 
+* Creates and seeds that database by calling the `Seed` method
 
 Ignore the locking for now; we will come back to it later.
 
@@ -86,7 +88,7 @@ For example:
 Notice that the transaction is created as the test starts and disposed when it is finished.
 Disposing the transaction causes it to be rolled back, so none of the changes will be seen by other tests.
 
-The helper method for creating a context (see the fixture code above) accepts this transaction and opts the DbContext into using it. 
+The helper method for creating a context (see the fixture code above) accepts this transaction and opts the DbContext into using it.
 
 ## Sharing the fixture