Xamarin References Update (#4938)

* Xamarin References Update

* Remove extra blank line

Author: wadepickett

entity-framework/core/cli/dotnet.md

@@ -89,6 +89,9 @@ It's also possible to [put migrations code in a class library separate from the
 
 The CLI tools work with .NET Core projects and .NET Framework projects. Apps that have the EF Core model in a .NET Standard class library might not have a .NET Core or .NET Framework project. For example, this is true of Xamarin and Universal Windows Platform apps. In such cases, you can create a .NET Core console app project whose only purpose is to act as startup project for the tools. The project can be a dummy project with no real code — it is only needed to provide a target for the tooling.
 
+> [!IMPORTANT]
+> Xamarin.Android, Xamarin.iOS, Xamarin.Mac are now integrated directly into .NET (starting with .NET 6) as .NET for Android, .NET for iOS, and .NET for macOS. If you're building with these project types today, they should be upgraded to .NET SDK-style projects for continued support. For more information about upgrading Xamarin projects to .NET, see the [Upgrade from Xamarin to .NET & .NET MAUI](/dotnet/maui/migration) documentation.
+
 Why is a dummy project required? As mentioned earlier, the tools have to execute application code at design time. To do that, they need to use the .NET Core runtime. When the EF Core model is in a project that targets .NET Core or .NET Framework, the EF Core tools borrow the runtime from the project. They can't do that if the EF Core model is in a .NET Standard class library. The .NET Standard is not an actual .NET implementation; it's a specification of a set of APIs that .NET implementations must support. Therefore .NET Standard is not sufficient for the EF Core tools to execute application code. The dummy project you create to use as startup project provides a concrete target platform into which the tools can load the .NET Standard class library.
 
 ### ASP.NET Core environment

entity-framework/core/cli/powershell.md

@@ -82,6 +82,9 @@ It's also possible to [put migrations code in a class library separate from the
 
 The Package Manager Console tools work with .NET Core or .NET Framework projects. Apps that have the EF Core model in a .NET Standard class library might not have a .NET Core or .NET Framework project. For example, this is true of Xamarin and Universal Windows Platform apps. In such cases, you can create a .NET Core or .NET Framework console app project whose only purpose is to act as startup project for the tools. The project can be a dummy project with no real code — it is only needed to provide a target for the tooling.
 
+> [!IMPORTANT]
+> Xamarin.Android, Xamarin.iOS, Xamarin.Mac are now integrated directly into .NET (starting with .NET 6) as .NET for Android, .NET for iOS, and .NET for macOS. If you're building with these project types today, they should be upgraded to .NET SDK-style projects for continued support. For more information about upgrading Xamarin projects to .NET, see the [Upgrade from Xamarin to .NET & .NET MAUI](/dotnet/maui/migration) documentation.
+
 Why is a dummy project required? As mentioned earlier, the tools have to execute application code at design time. To do that, they need to use the .NET Core or .NET Framework runtime. When the EF Core model is in a project that targets .NET Core or .NET Framework, the EF Core tools borrow the runtime from the project. They can't do that if the EF Core model is in a .NET Standard class library. The .NET Standard is not an actual .NET implementation; it's a specification of a set of APIs that .NET implementations must support. Therefore .NET Standard is not sufficient for the EF Core tools to execute application code. The dummy project you create to use as startup project provides a concrete target platform into which the tools can load the .NET Standard class library.
 
 ### ASP.NET Core environment

entity-framework/core/learn-more/community-standups.md

@@ -1693,7 +1693,6 @@ Links:
 - Video: [The Intersection of Microservices, Domain-Driven Design and Entity Framework Core](https://www.youtube.com/watch?v=DG8Qe7TJiIE)
 - GitHub: [julielerman/dotnetconfms2020](https://github.com/julielerman/dotnetconfms2020)
 - Blog: [How to call stored procedures with OUTPUT parameters with FromSqlRaw in EF Core](https://erikej.github.io/efcore/2020/08/03/ef-core-call-stored-procedures-out-parameters.html)
-- Docs: [Getting Started with EF Core and Xamarin](xref:core/get-started/xamarin)
 - Docs: [Getting Started with WPF](xref:core/get-started/wpf)
 - Docs: [EF Core daily builds](https://aka.ms/ef-daily-builds)
 

entity-framework/core/miscellaneous/platforms.md

@@ -41,7 +41,7 @@ The last version of EF Core that supported .NET Framework was version 3.1. We re
 
 ## Xamarin
 
-The last version of EF Core that supported Xamarin was version 5.0. We recommend using .NET and [.NET MAUI](/dotnet/maui/) instead. .NET supports multiple platforms including Android, iOS, macOS, and Windows. .NET MAUI is an evolution of the Xamarin.Forms UI framework.
+The last version of EF Core that supported Xamarin was version 5.0. We recommend using .NET and [.NET MAUI](/dotnet/maui/) instead. .NET supports multiple platforms including Android, iOS, macOS, and Windows. .NET MAUI is an evolution of the Xamarin.Forms UI framework. Xamarin.Android, Xamarin.iOS, Xamarin.Mac are now integrated directly into .NET (starting with .NET 6) as .NET for Android, .NET for iOS, and .NET for macOS. If you're building with these project types today, they should be upgraded to .NET SDK-style projects for continued support. For more information about upgrading Xamarin projects to .NET, see the [Upgrade from Xamarin to .NET & .NET MAUI](/dotnet/maui/migration) documentation.
 
 ## Universal Windows Platform
 

entity-framework/core/what-is-new/ef-core-5.0/plan.md

@@ -192,6 +192,9 @@ Status: Scope/Done
 
 Scoping: Platform guidance and samples are published for Blazor, Xamarin, WinForms, and WPF. Xamarin and other AOT/linker work is now planned for EF Core 6.0.
 
+> [!IMPORTANT]
+> Xamarin.Android, Xamarin.iOS, Xamarin.Mac are now integrated directly into .NET (starting with .NET 6) as .NET for Android, .NET for iOS, and .NET for macOS. If you're building with these project types today, they should be upgraded to .NET SDK-style projects for continued support. For more information about upgrading Xamarin projects to .NET, see the [Upgrade from Xamarin to .NET & .NET MAUI](/dotnet/maui/migration) documentation.
+
 We have good guidance for using EF Core in traditional MVC-like web applications. Guidance for other platforms and application models is either missing or out-of-date. For EF Core 5.0, we plan to investigate, improve, and document the experience of using EF Core with:
 
 * Blazor

entity-framework/core/what-is-new/ef-core-6.0/plan.md

@@ -126,7 +126,7 @@ Status: Scoped/Complete
 
 T-shirt size: Medium
 
-EF Core performs large amounts of runtime code generation. This is challenging for app models that depend on linker tree shaking, such as Xamarin and Blazor, and platforms that don't allow dynamic compilation, such as iOS. We will continue investigating in this space as part of EF Core 6.0 and make targeted improvements as we can. However, we do not expect to fully close the gap in the 6.0 time frame.
+EF Core performs large amounts of runtime code generation. This is challenging for app models that depend on linker tree shaking, such as .NET MAUI and Blazor, and platforms that don't allow dynamic compilation, such as iOS. We will continue investigating in this space as part of EF Core 6.0 and make targeted improvements as we can. However, we do not expect to fully close the gap in the 6.0 time frame.
 
 ## Migrations and deployment
 

entity-framework/core/what-is-new/ef-core-7.0/plan.md

@@ -219,7 +219,7 @@ Tracked by [Issue #21894: Improve trimming support for EF Core apps to reduce ap
 
 Value proposition: Smaller applications that can be efficiently AOT compiled.
 
-EF Core performs large amounts of runtime code generation. This is challenging for app models that depend on linker tree shaking, such as Xamarin and Blazor, and platforms that don't allow dynamic compilation, such as iOS. We plan to greatly improve trimming of unused code in EF7. This will facilitate smaller assembly sizes when using EF Core, thus helping deployment and making ahead-of-time (AOT) compilation more efficient.
+EF Core performs large amounts of runtime code generation. This is challenging for app models that depend on linker tree shaking, such as .NET MAUI and Blazor, and platforms that don't allow dynamic compilation, such as iOS. We plan to greatly improve trimming of unused code in EF7. This will facilitate smaller assembly sizes when using EF Core, thus helping deployment and making ahead-of-time (AOT) compilation more efficient.
 
 #### Evolve System.Linq.Expression
 

entity-framework/index.yml

@@ -63,8 +63,6 @@ additionalContent:
             text: "WPF .NET Core app accessing SQLite with EF Core"
           - url: core/get-started/winforms.md
             text: "Windows Forms .NET Core app accessing SQLite with EF Core"
-          - url: core/get-started/xamarin.md
-            text: "Xamarin mobile app accessing SQLite with EF Core"
       # Card
       - title: Supported databases
         links:
@@ -101,8 +99,6 @@ additionalContent:
             text: "Windows Presentation Foundation (WPF)"
           - url: core/get-started/winforms.md
             text: "Windows Forms (WinForms)"
-          - url: core/get-started/xamarin.md
-            text: "Xamarin"
       # Card
       - title: Fundamentals
         links:

entity-framework/toc.yml

@@ -55,9 +55,6 @@
         href: core/get-started/wpf.md
       - name: Windows Forms tutorial
         href: core/get-started/winforms.md
-      - name: Xamarin tutorial
-        href: core/get-started/xamarin.md
-
     - name: "Releases and planning (roadmap)"
       items:
       - name: Current and planned releases