We Keep Coding

How to manage nuget packages globally for all projects in a solution using Visual Studio 2022?

I have a solution created in .NET 6.0 using Visual Studio 2022 which has many projects.
Each project has so many nuget package references in the .csproj file as below.
Is it possible to manage all nuget packages in a single location / globally in the solution (instead of for each project)?
This will make sure all projects in the solution are using the same version of the package (no more version conflicts between the projects for the same nuget package).
Updating the package once at the central location will ensure all projects are referring to the same updated version. No need to update the package for every project.
Thanks for your help.
<ItemGroup>
<PackageReference Include="MediatR.Extensions.Microsoft.DependencyInjection" Version="10.0.1" />
<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.20.0" />
<PackageReference Include="Microsoft.ApplicationInsights.Kubernetes" Version="2.0.2" />
<PackageReference Include="Microsoft.ApplicationInsights.Kubernetes.HostingStartup" Version="2.0.2" />
<PackageReference Include="Microsoft.AspNetCore.Authentication.OpenIdConnect" Version="6.0.1" />
<PackageReference Include="Microsoft.Azure.ServiceBus" Version="5.2.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="6.0.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="6.0.1">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>
<PackageReference Include="Microsoft.Extensions.Configuration.UserSecrets" Version="6.0.0" />
<PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="6.0.0" />
<PackageReference Include="Microsoft.VisualStudio.Azure.Containers.Tools.Targets" Version="1.14.0" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="6.0.1" />
<PackageReference Include="System.Collections" Version="4.3.0" />
<PackageReference Include="System.Runtime" Version="4.3.1" />
</ItemGroup>

There's a few approaches to doing this. Currently (at the time of this edit), only NuGet's Central Package Version Management supports managing transitive package dependencies.
Manually, with a .targets file
Have a .targets file with all the packages you reference but use <PackageReference Update= instead of Include=. Include this in your Directory.Build.targets file, so that it will be applied at the end of each project file.
The biggest downside to this is that any time a new PackageReference is added to any project, you'll need to also remember to update the .targets file to include an entry to update that package version.
This will ensure that all of your <PackageReference> entries will unify to the same versions. However, it does not impact transitive references, i.e. if you have Project1 -> Package1 -> Package2, but only have a PackageReference to Package1, you won't be able to affect the referenced version of Package2. This may create conflicts if Project2 -> Package2 at a different version than what Package1 references.
Use the Central Package Versions MSBuild SDK (CPV)
The manual process can be error-prone, so there's a 3rd party SDK to help make the process smoother. You can find it at Central Package Versions. This also provides enforcement that users do not specify a version in the project (because they should be using the central one instead!) so it will be more consistent than using the manual technique.
This also does not resolve transitive dependency issues in any way.
Use Nuget Central Package Version Management (CPVM)
This is the NuGet team's solution to the issue. It's explained in this blog post, or you can find the original documentation at Centrally managing NuGet package versions.
Have a file named Directory.Packages.props in your root folder, and enable the feature by adding:
<PropertyGroup>
<ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
</PropertyGroup>
Now, similar to the CPV SDK, you should remove all versions from the <PackageReference> elements, and put them in <PackageVersion> elements in your Directory.Packages.props files. If you need to override a version there are two methods:
On the <PackageReference> item, add a VersionOveride=1.2.3.4 attribute.
In the .csproj add <PackageVersion Update="PackageName" Version="DifferentVersion" /> (this is because Directory.Packages.props is imported via the .NET SDKs .props file, which is before the content of the .csproj is evaluated).
This by itself does not help with transitive references. You can additionally add <CentralPackageTransitivePinningEnabled>true</CentralPackageTransitivePinningEnabled> to enable pinning for transitive packages. What this basically does is to determine if any of your direct or indirect (transitive) PackageReferences has a matching PackageVersion, and if so it promotes that as though it were a direct reference (meaning anything that depends on it will also get the pinned version). Transitive pinning support requires at least NuGet 6.2, VS 2022 17.2, or the .NET SDK 6.0.300.

The new CPM feature was mentioned, but I thought I'd include a full example too.
You could use nuget's new "Central Package Management" feature.
Example problem:
Suppose you have monorepo (i.e. VS "solution" or VSCode "workspace") with multiple projects.
ProjectA.csproj:
<ItemGroup>
<PackageReference Include="Foo.Bar.Baz" Version="1.0.0" />
<PackageReference Include="Spam.Ham.Eggs" Version="4.0.0" />
</ItemGroup>
ProjectB.csproj:
<ItemGroup>
<PackageReference Include="Foo.Bar.Qux" Version="1.2.3" />
<PackageReference Include="Spam.Ham.Eggs" Version="4.5.6" />
</ItemGroup>
Some items are the same whereas others differ. And you need to remember to keep the versions in sync - the example shows that you forgot to do that!
Step 1: remove the versions
ProjectA.csproj:
<ItemGroup>
<PackageReference Include="Foo.Bar.Baz" />
<PackageReference Include="Spam.Ham.Eggs" />
</ItemGroup>
ProjectB.csproj:
<ItemGroup>
<PackageReference Include="Foo.Bar.Qux" />
<PackageReference Include="Spam.Ham.Eggs" Version="4.0.0" /> <!-- note version override for this project -->
</ItemGroup>
Step 2: add file named Directory.Packages.props to your repo's root
<Project>
<PropertyGroup>
<ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
</PropertyGroup>
<ItemGroup>
<!-- use 'PackageVersion' rather than 'PackageReference' -->
<PackageVersion Include="Foo.Bar.Baz" Version="1.2.3" />
<PackageVersion Include="Foo.Bar.Qux" Version="1.2.3" />
<PackageVersion Include="Spam.Ham.Eggs" Version="4.5.6" />
</ItemGroup>
</Project>
Step 3: restore
For each project:
clear build output: dotnet clean
restore packages: dotnet restore
All your projects will now use the versions you've specified in the config file.
There are more options, like version overrides, and transitive dependency pinining - read the docs for more.

Web Job: Library not found

We have a continuous WebJob that is written in .NET Core 2.x and has been running fine for the past few weeks. Recently someone made some changes to this WebJob and brought in a 3rd party NuGet package. Now, I am unable to start the WebJob because it is unable to locate one of the 3rd Party libraries dependencies.
This is the error message:
D:\local\Temp\jobs\continuous\Temp1\oitdncff.sfg>dotnet Temp1.dll
Error:
An assembly specified in the application dependencies manifest (Temp1.deps.json) was not found:
package: 'System.Drawing.Common', version: '4.5.0-preview1-25914-04'
path: 'runtimes/win/lib/netcoreapp2.0/System.Drawing.Common.dll'
I have tried several things I found whilst Googling this problem. Here is the PropertyGroup and ItemGroup (NuGet packages) from the csproj file:
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<ApplicationIcon />
<StartupObject>Temp1.Program</StartupObject>
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
<LangVersion>latest</LangVersion>
<Version>1.0.0.0</Version>
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" />
<PackageReference Include="AsyncEnumerator" Version="2.1.0" />
<PackageReference Include="EPPlus.Core" Version="1.5.4" />
<PackageReference Include="Microsoft.ApplicationInsights" Version="2.5.1" />
<PackageReference Include="Microsoft.ApplicationInsights.DependencyCollector" Version="2.5.1" />
<PackageReference Include="Microsoft.Azure.ServiceBus" Version="2.0.0" />
<PackageReference Include="Microsoft.Azure.WebJobs" Version="3.0.0-beta4" />
<PackageReference Include="Microsoft.Azure.WebJobs.Logging.ApplicationInsights" Version="3.0.0-beta4" />
<PackageReference Include="Microsoft.Azure.WebJobs.ServiceBus" Version="3.0.0-beta4" />
<PackageReference Include="Microsoft.Extensions.Configuration" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.Configuration.EnvironmentVariables" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.Configuration.FileExtensions" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.Configuration.Json" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.Logging" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.Logging.Configuration" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.Logging.Console" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="2.0.0" />
<PackageReference Include="Newtonsoft.Json" Version="10.0.3" />
</ItemGroup>
Per suggestions online, I added the line
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
and
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" />
The package in question that has the dependency is EPPlus.Core
I have confirmed that the library System.Drawing.Common does exist in the app folder on our Azure Web App but the when the WebJob starts up, it is ignoring that the file is there and looking in the runtimes (GAC) and failing.
UPDATE:
I realized that the EPPlus.core package was not official so switched over to the official package hoping this would resolve the error. Same error but a new version of the System.Drawing.Common version: 4.5.0-preview1-26216-02
I have manually added the NuGet package for System.Drawing.Common version: 4.5.0-preview2-26406-04 to the project, this removed the original error but then I started getting an error that Microsoft.Win32.SystemEvents version: 4.5.0-preview2-26406-04 could not be found. This library is a dependent of System.Drawing.Common.
I attempted to do the same thing I did above and added the NuGet package for Microsoft.Win32.SystemEvents version: 4.5.0-preview2-26406-04 directly to the project but this time the error is not going away.
FURTHER UPDATE:
After searching more, I came across a posting here that talked about publishing and then zipping up the published directory and uploading the zip. This did actually work, the error in question was gone but this is not really a solution. We are using VSTS as our repo system and our CI/CD. I have the build configration set to do a publish and then copy the files up. The WebJob throws the error when its deployed via this process.

First, I would like to state that as of today, to my knowledge, .NET Core is not 100% supported with Azure WebJobs (feel free to correct me if I am wrong) but there are lots of articles and posts on how to make them work.
Below is the solution I did to get around the above issue I was having and whilst I do not feel this is elegant, I do feel that Microsoft has done something odd that most developers would not think is the correct path.
The reason I was having issues was that when I built (in debug or release) the manifest file was always pointing to the runtimes (GAC). Running locally on my box was never an issue because the files could be found. The oddity is when building in release mode, all files were copied to the bin folder yet the manifest still told the program to look in the runtimes and not to use the local copies. When this was pushed out to the WebJob itself, these files did not exist in the runtime so the WebJob would throw exceptions.
The workaround I had to do is as follows:
dotnet build (Solution - Release Configuration)
dotnet publish (WebJobs Only - Do Not Zip)
dotnet publish (Web Project Only - Do Not Zip)
Copy WebJob Data from Publish to the Web Project directory \App_Data\jobs\continuous\ directory
Zip Up Web Project Published Directory (this is what gets deployed)
My honest opinion is, when I build a webjob project in release mode, the process should transform the manifest to look for any referenced libraries locally before attempting to look for them in the runtimes.

System.Data.SqlClient is not supported on this platform

I'm using ASP.NET Core 2 with Entity Framework Core 2.0.2. I created a context and Add-Migrations command in Package Manager Controller works fine.
However when Update-Database command is used, I get an error:
System.Data.SqlClient is not supported on this platform
I can't figure out where the problem is. Can you help me? Thanks.
My .csproj file:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
<DebugType>portable</DebugType>
<PreserveCompilationContext>true</PreserveCompilationContext>
<DockerComposeProjectPath>..\docker-compose.dcproj</DockerComposeProjectPath>
</PropertyGroup>
<ItemGroup>
<Folder Include="wwwroot\" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Autofac.Extensions.DependencyInjection" Version="4.2.1" />
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.6" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.0.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="2.0.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.0.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.0.2" />
<PackageReference Include="Swashbuckle.AspNetCore" Version="2.3.0" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.2" />
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.2" />
</ItemGroup>
</Project>

I ran into the same issue a couple of days ago - I'm not sure what the underlying issue is, but reverting some of the EntityFrameworkCore nuget packages back to 2.0.0 seems to have resolved the issue for me. These are the packages I downgraded:
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="2.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.0.0" />

Same problem here but for me it is a failure on the part of System.Data.SqlClient to load dynamically as part of a plugin. Our plugin dlls are loaded dynamically via Autofac and a controlling service selects the correct one at run time. Unfortunately System.Data.SqlClient will not load dynamically like this, result in the above error message. So I had to load it when the controlling service starts up. This is obviously not ideal but for now it is a usable workaround as all our plugins are still under our control.
I'll be more specific, following a question in comments.
A service selects plug-ins at run time. The plug-ins register their own dependencies via Autofac and if that dependency is a Nuget package they will also include the package as a normal Nuget dependency.
The controlling service registers the plug-in dlls on start up and the first time they are used the plug-in dependencies are also loaded. When System.Data.SqlClient load is attempted following a call to the plug-in that uses SqlClient the "not supported" error results.
Setting System.Data.SqlClient as a Nuget dependency in the controlling service works OK and the library is loaded correctly without error. However, this is not ideal because the the SqlClient library always has to be loaded by the controlling service even if the plug-in selected to run it does not need it.
In other words the SqlClient library is always loaded at service start up occupying resources, etc when it may not even be needed. But at least it works.

I ran into this issue recently with .net standard 2.0 classes being consumed by a regular .net framework app. (.net 4.7.x). The only thing that ultimately fixed my issue was migrating from packages.config to PackageReference on the regular .net app.

Just in case somebody lands here who is trying to run System.Data.SqlClient on net50/netstandard on rid freebsd-x64: Microsoft.Data.SqlClient worked for me.
Maybe this works on every portable option and/or for all System.[...] ->Microsoft.[...] dll.

I spent a couple of hours on this but managed to resolve it. Posting here in case it helps someone else save some time.
In my .csproj files I had
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
Removing this solved my problem. Some information can be found here. Setting the value to true causes all dependencies to be copied to the output folder and for me, maybe when loading the application, it was getting confused about which System.Data.SqlClient.dll to load.

I had this exact same issue with a .NET 5.0 console application i was deploying. I discovered that when i published the application the publish profiles target framework was set to 3.1 instead of 5.0 and that is what caused this error for me. After re-publishing with the correct target framework everything worked as expected.

String connectionString, String contextType)
at Microsoft.EntityFrameworkCore.Design.OperationExecutor.UpdateDatabaseImpl(String targetMigration, String connectionString, String contextType)
at Microsoft.EntityFrameworkCore.Design.OperationExecutor.UpdateDatabase.<>c__DisplayClass0_0.<.ctor>b__0()
at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.Execute(Action action)
Microsoft.Data.SqlClient is not supported on this platform."
go to manage nugget packages and do a downgrade. Hope it works for you

Change the framework to .NetCore 3.x or .NetFramework 4.x...

Issue with creating initial migration in ASP.Net Core

I've been working on the basics of an ASP.Net Core MVC Project and I'm wondering why I can't create my initial Migration.
I go into the project folder and run "dotnet ef" in CMD and get an error of "No executable found matching command dotnet-ef".
I figure that this is odd, so I try to build my application in VS2017 and I get this error:
Severity Code Description Project File Line Suppression State
Error NU1605 Detected package downgrade: Microsoft.NETCore.App from 2.0.6
to 2.0.0. Reference the package directly from the project to select a
different version.
FiberLocator -> Microsoft.EntityFrameworkCore.Tools.DotNet 2.0.2 ->
Microsoft.NETCore.App (>= 2.0.6)
FiberLocator -> Microsoft.NETCore.App (>= 2.0.0) FiberLocator
C:\Users\user\Google Drive\ASP.Net Core
Projects\FiberLocator\FiberLocator.csproj 1
My .csproj file looks like this.
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Folder Include="Data\Migrations\" />
<Folder Include="wwwroot\" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.6" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.0.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="2.0.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="2.0.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.0.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.0.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.2" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.0.3" />
</ItemGroup>
</Project>
From what i understand, the ..Tools.DotNet is the package that gets me the ability to use "dotnet ef". I even tried setting the version to the latest at this time of writing (a preview build even) and it still wouldn't work, giving me the "unknown command" error from above.
How can I change my NETCore.App package to 2.0.0, or allow the Tools.DotNet package to be compatible? There isn't a later version than 2.0.2 on the NuGet site, so I have no idea what to do here.
Any help is appreciated.
Thanks

Microsoft.EntityFrameworkCore.Tools.DotNet is dotnet-ef command line tool. In order to use it in your project change the element referencing it in your csproj from PackageReference to DotNetCliToolReference. Like so:
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.2" />
Version 2.0.2 requires Microsoft.NETCore.App (>= 2.0.6). So you should be ok. For more versions and dependencies have a look at: nuget.org
Microsoft.EntityFrameworkCore.Tools contains equivalent tools, but for Nuget's Package Manager Console in Visual Studio

EntityFrameworkCore does not exist in the namespace Microsoft

I am trying to walk through this tutorial here.
https://learn.microsoft.com/en-us/aspnet/core/data/ef-mvc/intro
However after successfully installing EntityFrameworkCore in the package manager console using the command:
Install-Package Microsoft.EntityFrameworkCore.SqlServer
then running a dotnet restore successfully in the cmd, the project does not register EntityFrameworkCore. In the .csproj file you can see the line
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="1.1.1" />
Unfortunately whenever I add a using statement with Microsoft.EntityFrameworkCore in a file I get the error mentioned in the title. Any idea why this might be happening?

I solved this problem by:
(1) Right clicking the project in the Solution Explorer
(2) Clicking unload project
(3) Click edit the .csproj and check if there is a Package Reference to EF
(4) Right clicking the project again in the Solution Explorer
(5) Then clicked reload project
Now it recognizes EntityFrameworkCore and there are no more build errors

In Visual Code:
Ctrl + Shift + P => Restart OmniSharp

Go to NuGet browser and install Microsoft.EntityFrameworkCore!

You missed a required Nuget Package, according to microsoft, you will need to install 3 packages in total, but in my case, it is only required 2 packages as the following:
Microsoft.EntityFrameworkCore.SqlServer
Microsoft.EntityFrameworkCore.Tools
Hope this can solve your problem.

Copying the following code into the TodoApi.csproj from https://github.com/aspnet/Docs/tree/master/aspnetcore/tutorials/first-web-api/sample/TodoApi worked for me.
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Folder Include="wwwroot\" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
</ItemGroup>
</Project>
Microsoft.AspNetCore.All may be excessive but it includes EntityFrameworkCore etc

If using VS Code, the solution that worked for me:
In the terminal type:
dotnet add package Microsoft.EntityFrameworkCore
After adding package, Ctrl + Shift + P -> Restart OmniSharp

In visual Studio, go to -> Project -> Manage NuGet Packages.. ->
Select Microsoft Entity framework Core. The click on Add package on the bottom right corner button.

Go to Tools in your visual studio » NuGet Package Manager » Package Manager Console
type->
install-package microsoft.entityframeworkcore.sqlserver

Clean up the .csproj file so if you see something like...
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.2.4">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
</PackageReference>
Change it to :
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.2.4" />

From one of the other comments about the package.config file, double checking... Seems, my issue appeared that the targetFramework="net472" in the package.config file didn't match the project's .Net version. The project is using 4.7.2 but the package file was "471", updating the targetFramework in the package.config to "472" the problems went away :)
Seem in the past never had many issues with mixing 4.x.y, as long as 4.x were the same no troubles, as of late, sure seems .Net want 4.x.y to all match...
`<packages>
<package id="EntityFramework" version="6.2.0" targetFramework="net472" />
</packages>`

I had to lower the version of Entity Framework from 6.2 to 6.0

I am assuming this is the same issue I encountered with:
https://learn.microsoft.com/en-us/aspnet/core/tutorials/razor-pages/?view=aspnetcore-6.0
The getting started directions include a section that lead you to believe you need to add the following -
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.DependencyInjection;
using RazorPagesMovie.Data;
var builder = WebApplication.CreateBuilder(args);
// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddDbContext<RazorPagesMovieContext>(options =>
options.UseSqlServer(builder.Configuration.GetConnectionString("RazorPagesMovieContext")));
var app = builder.Build();
However I determined that if you skip this and continue the tutorial, it is handled later on...

Use the nugget packege manager on VS code and add Microsoft.EntityFrameworkCore that way and the issue will be solved it will also place it into the .csproj
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="5.0.16"/>