diff --git a/aspnetcore/blazor/fundamentals/logging.md b/aspnetcore/blazor/fundamentals/logging.md index 7ba5de33d1..7caa2e3d18 100644 --- a/aspnetcore/blazor/fundamentals/logging.md +++ b/aspnetcore/blazor/fundamentals/logging.md @@ -860,6 +860,5 @@ Use ***either*** of the following approaches: * [Implement a custom logging provider in .NET](/dotnet/core/extensions/custom-logging-provider) * Browser developer tools documentation: * [Chrome DevTools](https://developer.chrome.com/docs/devtools/) - * [Firefox Developer Tools](https://firefox-source-docs.mozilla.org/devtools-user/index.html) * [Microsoft Edge Developer Tools overview](/microsoft-edge/devtools-guide-chromium/) * [Blazor samples GitHub repository (`dotnet/blazor-samples`)](https://github.com/dotnet/blazor-samples) ([how to download](xref:blazor/fundamentals/index#sample-apps)) diff --git a/aspnetcore/blazor/javascript-interoperability/index.md b/aspnetcore/blazor/javascript-interoperability/index.md index ebf93b8dc5..91cc2f2156 100644 --- a/aspnetcore/blazor/javascript-interoperability/index.md +++ b/aspnetcore/blazor/javascript-interoperability/index.md @@ -249,7 +249,6 @@ To disable client-side caching in browsers, developers usually adopt one of the * Disable caching when the browser's developer tools console is open. Guidance can be found in the developer tools documentation of each browser maintainer: * [Chrome DevTools](https://developer.chrome.com/docs/devtools/) - * [Firefox Developer Tools](https://firefox-source-docs.mozilla.org/devtools-user/index.html) * [Microsoft Edge Developer Tools overview](/microsoft-edge/devtools-guide-chromium/) * Perform a manual browser refresh of any webpage of the Blazor app to reload JS files from the server. ASP.NET Core's HTTP Caching Middleware always honors a valid no-cache [`Cache-Control` header](https://developer.mozilla.org/docs/Web/HTTP/Headers/Cache-Control) sent by a client. diff --git a/aspnetcore/blazor/security/server/qrcodes-for-authenticator-apps.md b/aspnetcore/blazor/security/server/qrcodes-for-authenticator-apps.md index e42e38eda3..28f954723e 100644 --- a/aspnetcore/blazor/security/server/qrcodes-for-authenticator-apps.md +++ b/aspnetcore/blazor/security/server/qrcodes-for-authenticator-apps.md @@ -15,7 +15,7 @@ For an introduction to two-factor authentication (2FA) with authenticator apps u ## Scaffold the Enable Authenticator component into the app -Follow the guidance in to scaffold `Pages\Manage\EnableAuthenticator` into the app. +Follow the guidance in to scaffold `Pages\Manage\EnableAuthenticator` into the app. diff --git a/aspnetcore/blazor/security/webassembly/standalone-with-identity.md b/aspnetcore/blazor/security/webassembly/standalone-with-identity.md index bdb6a57b23..3befb4855d 100644 --- a/aspnetcore/blazor/security/webassembly/standalone-with-identity.md +++ b/aspnetcore/blazor/security/webassembly/standalone-with-identity.md @@ -129,7 +129,12 @@ The following setup and configuration is found in the app's [`Program` file](htt User identity with cookie authentication is added by calling and . Services for authorization checks are added by a call to . -Only recommended for demonstrations, the app uses the [EF Core in-memory database provider](/ef/core/providers/in-memory/) for the database context registration (). The in-memory database provider makes it easy to restart the app and test the registration and login user flows. Each run starts with a fresh database, but the app includes [test user seeding demonstration code](#test-user-seeding-demonstration), which is described later in this article. If the database is changed to SQLite, users are saved between sessions, but the database must be created through [migrations](/ef/core/managing-schemas/migrations/), as shown in the [EF Core getting started tutorial](/ef/core/get-started/overview/first-app). You can use other relational providers such as SQL Server for your production code. +Only recommended for demonstrations, the app uses the [EF Core in-memory database provider](/ef/core/providers/in-memory/) for the database context registration (). The in-memory database provider makes it easy to restart the app and test the registration and login user flows. Each run starts with a fresh database, but the app includes [test user seeding demonstration code](#test-user-seeding-demonstration), which is described later in this article. If the database is changed to SQLite, users are saved between sessions, but the database must be created through [migrations](/ef/core/managing-schemas/migrations/), as shown in the [EF Core getting started tutorial](/ef/core/get-started/overview/first-app)†. You can use other relational providers such as SQL Server for your production code. + +> [!NOTE] +> †The EF Core getting started tutorial uses PowerShell commands to execute database migrations when using Visual Studio. An alternative approach in Visual Studio is to use the Connected Services UI: +> +> In **Solution Explorer**, double-click **Connected Services**. In **Service Dependencies** > **SQL Server Express LocalDB**, select the ellipsis (`...`) followed by either **Add migration** to create a migration or **Update database** to update the database. Configure Identity to use the EF Core database and expose the Identity endpoints via the calls to , , and .