I installed EF with NuGet and the project's dependencies folder shows warning that EF may not be compatible. Which package do I install to use EF from the standard library?
I installed this EF:
Here is the assembly used in another project of the solution:
That's because you added the package for EF 6.2, which only targets the Full framework. It won't work on the .NET Core Runtime.
You need to use Entity Framework Core. This is was fully rewritten to target .NET Standard and fix many of the problems people had with the older Entity Framework.
Since it targets .NET Standard, it can be used in all runtimes - .NET Core, Full framework and UWP projects.
Its new features make it a great choice for the Full framework as well. For example, EF Core 2.2 added spatial types support, by using the open source NetTopologySuite package. Even EF 6.2 never had spatial type support.
Entity Framework Core is broken into various packages which enables you to add only the drivers/features you need to your project. Even the SQL Server provider is available as a separate package. A list of providers is available here
Luckily, each provider brings in all other required dependencies so all you need to do is include a provider to bring in all other required packages as transitive dependencies. That means, they don't appear as dependencies in Visual Studio or the csproj file. No more 50 package references that we don't know what to do about!
For SQL Server, you need to include Microsoft.EntityFrameworkCore.SqlServer, eg with
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
You need to add Microsoft.EntityFrameworkCore.Tools if you want to use database migration commands. If not, just don't add the package. You can always add it later.
Do add Microsoft.EntityFrameworkCore.Analyzers. It's a Roslyn analyzer that checks for common EF Core errors, especially when you use the RawSql method. It's way too easy to get this wrong.
Consider adding Microsoft.EntityFrameworkCore.InMemory in your test projects. It's a simple in-memory provider that can be used to test EF code without connecting to a database as shown here
Which package do I install to use EF from the standard library?
Just as Panagiotis pointed out, you should use Microsoft.EntityFrameworkCore instead of EntityFramework.
If you download those two packages from nuget.org, EntityFramework, Microsoft.EntityFrameworkCore, then open it with NuGet Package Explorer(You can get it from Microsoft Store.):
So, if you want to use EF from the standard library, you should install the nuget package Microsoft.EntityFrameworkCore.
Hope this helps.
Related
We use Visual Studio to write and maintain native Windows apps. We are looking into using NuGet to handle our dependencies, which consist of native static libs.
After some research, I've managed to use NuGet, package.config and the CoApp PowerShell scripts to create and consume NuGet packages with native libs in them. The issue we're facing right now is that we need to have Snapshot support.
The rollover PreRelease mechanism (with * for version rollover) that NuGet 3 and onwards supports looks great, however, it seems to only work with project.json and not with package.config. Project.json, however, doesn't seem to work with native packages, as they don't get installed in the local solution folder so the build can't find the headers and libs.
The question boils down to:
Is there a way to use project.json and NuGet 3 with native static libs?
If not, then, what alternatives are out there to support this use case? (The use case being build-time dependency distribution for native, unmanaged Windows static libraries).
EDIT:
At the end, we decided to use Maven for dependency management since NuGet doesn't seem to support our use case. I filed an issue about two weeks ago but it hasn't received any response. However, if we had decided to force NuGet into our use case, the solution proposed by Wendy would probably be the way to go, so I'm accepting it.
There are two ways could add content files into project that uses project.json file. One is "contentFiles" node and another is "files" node in nuspec file. Detailed steps please refer to:
http://blog.nuget.org/20160126/nuget-contentFiles-demystified.html
But please note, these ways only support UWP and Portable class libraries.
This feature is only for packages that will be installed to projects that are managed using a project.json file. Currently only two projects types are managed by a project.json.
1.UWP apps
2.Portable class libraries
The contentFiles option is not available for other project types
If you are using .NET Core application or other type project that use project.json, the content files in nuget package is not supported added into project at present.
We have several different teams building C# applications with Visual Studio. When we want to share libraries across teams, we create nuget packages for the libraries and add them to a local nuget feed.
The process we use to package our libraries is very simple: we create a .nuspec for the library, and then run nuget on the project .csproj to create the package.
This results in a package that is specific to the .Net version (4.0, 4.5, 4.5.1) selected for the .csproj for the project. We've pretty much standardized on 4.5 to deal with this.
Many publicly available nuget packages provide simultaneous support for different library versions, and we'd like our packages to do the same to make it easy for each of our teams to select .Net versions appropriate for them. I know in principle how to build a package this way-- but it involves moving files around to different folders and invoking the nuget packager at a lower-level. I don't know of a way to automate this in a way that could be picked up easily across our teams.
So my question is: is there an easy/standard way of setting up a library project in Visual Studio so it produces a cross-version-compatible Nuget package?
Not a direct answer to your question, I know this, but...
Why target multiple versions of the framework at all?
When NuGet installs a package that has multiple assembly versions, it
tries to match the framework name of the assembly with the target
framework of the project. If a match is not found, NuGet copies the
assembly that's for the highest version that is less than or equal to
the project's target framework.
Matching assembly version to the target framework of a project
What we've done is figure out what our lowest common denominator is, both for our libraries and our organization. In our case, we have some older apps still running on the 3.5 framework, so any NuGet packages we have that need to be available to any/all projects also target the 3.5 framework. However, we also have a few libraries that are only needed by some newer apps, these target 4.5 (both the projects and the libraries). This lets us leverage newer features.
If we find ourselves in a situation where an older app needs to reference a package that must reference the newest version to work, we bite the bullet and upgrade the project. However, for our libraries/packages, we always target the oldest version possible. Basically, the split is where we want/need to leverage Async/Await.
TL;DR: Don't target multiple frameworks. Target the lowest common denominator. It provides motivation to upgrade those apps lagging behind on 3.5 or 4. (Or, God forbid, 2.0...)
If you really need to support different framework versions, you will first have to create different configurations for each framework version (in your .csproj files), utilizing the configuration manager. Similar to the standard configurations "Debug" and "Release", or "x86_Debug" etc. you can add configurations by yourself like Release_Fw_40, Release_Fw_45, Release_Fw_451.
When packaging with Nuget, you can use the parameter
-Prop Configuration=Release_Fw_40
to choose which configuration you want to build, as described in the Nuget docs. There are also some hints how to automate the package builds, including support of different configurations.
Note that this will impose some additional effort for your library maintainers to manage those many configurations. It should be obvious that even if you provide a "Fw 4.5.1" version of your lib, you can only use Fw 4.0 features in the source code as long as you want to support a Fw 4.0 configuration. So make sure what you are trying is really worth the hassle.
I know in principle how to build a package this way-- but it involves moving files around to different folders and invoking the nuget packager at a lower-level. I don't know of a way to automate this in a way that could be picked up easily across our teams
I am not sure what you meant by this sentence, maybe I am telling you only things you already knew. But "moving files around to different folders" and "invoking the nuget packager at a lower-level" are things which can be very easily scripted. For such tasks, you can use simple Windows shell scripting or Powershell scripting, whatever you prefer.
What is the difference between a NuGet package, a Reference (is reference similar to a tool?), and a template in Visual Studio?
Why do we need them?
What is done / changed in our project when we install each one of them?
Are they dependent on each other in some way? Which one(s) of them are global installs, and which one(s) need to be installed in every project?
Before any comments or misunderstandings: this answer is NOT composed by me, but it was accepted as an answer here, so for the sake of the users trying to find an answer to this, I am literally Copying the answer to your question in this place.
What is the difference between a NuGet package, a Reference (is reference similar to a tool?), and a template in Visual Studio?
References are used to pull additional libraries into your project. For example, your colleague develop a library which implement some functions that you wanted. You needn't write it by yourself, just add the dll into your project through add reference. Of course you can add any libraries not it come from third part or from Microsoft. But it won't notice you when the libraries changed or updated.
NuGet package is the package manager for the Microsoft development platform including .NET. It will help you manage your packages which installed on your project. When the package has new version released, it will notice you to update it. The NuGet client is a tool provide the ability to produce and consume packages.
Template is similar to a sample project which provides the frameworks based on different type of project. You just need to add your content/functions into this frameworks to implement your requirement. For example, if create a WinForms project, it will reference System.Windows.Forms automatically which contains all stuffs you needed in WinForms project.
Why do we need them?
NuGet package and Reference can help us invoke some functions which have been implemented by others or some have been encapsulated by Microsoft. And the Template can help us create a project without build framework by our self. All of them help us save a lot of time when developing a project.
What is done / changed in our project when we install each one of them?
Add references in your project, it will let you invoke the functions in these references in your project.
Install NuGet packages will add the package reference into your project automatically and then you can use the functions the package provided.
The template will be installed when you install Visual Studio. Most of common templates will be installed. Then you can create a new project through these templates quickly.
Are they dependent on each other in some way? Which one(s) of them are global installs, and which one(s) need to be installed in every project?
Reference and NuGet packages need to referenced/installed on a project. But this project can be create through the templates or can be create by customer self. So in some way, reference and NuGet package are dependent on project.
Templates is global installs and NuGet packages and reference need to be install in every project.
I'm trying to make a very simple Xamarin.Forms test application to explore some features of the System.Data.SQLite package (namely encryption). However, I can't seem to get Visual Studio 2012 to add a reference to the package to the project.
Here are the steps I am taking:
Created a new Xamarin.Forms Portable blank app.
Right-click on TestApp (core project) and select Manage NuGet Packages
Search for "sqlite"
Install the "System.Data.SQLite (x86/x64)" package. (This package is version 1.0.97.0 and it is described as "the official SQLite database engine for both x86 and x64 along with the ADO.NET provider.")
According to NuGet, the package was successfully installed.
However, I cannot see the reference added under my project's "References" folder, and I also cannot write "using System.Data.SQLite" without errors ("cannot resolve symbol 'Data'"). Does anyone have any idea why this is happening?
On a side note, I can follow the exact same process described above except instead of creating a Xamarin.Forms Portable blank app, I choose a regular C# console app. This allows me to install the NuGet package fine and it shows up in references as expected.
Posting an update to share what I've learned.
So as Jason sort of alluded to in his answer, the reason I was not able to reference the package in my Xamarin.Forms project is because Xamarin.Forms is, by definition, a PCL project. It's meant to work on all platforms. The package I was referring to in my question is not a PCL, which means that anything in the package that is platform dependent is inaccessable (which is basically the entire package). The SQLite.Net-PCL package is basically the same thing as System.Data.SQLite, but in PCL form, which means it is compatible for use in a Xamarin.Forms project.
Following this logic, it makes sense that I was able to access System.Data.SQLite from a console project, since a console project is not a PCL project and it targets a specific platform.
For PCL projects, use SQLite.Net-PCL.
I don't get it - can someone please explain to me why I should use NuGet rather than installing a bunch of libraries via a setup.exe or MSI? What advantage is there?
For example is it better to install Entity Framework 4.3 via NuGet rather than downloading the setup? Also, if I install entity framework via NuGet then is it available to any new solutions or projects that I create (bit confused here).
Basically what does NuGet do that a normal install doesn't do (or vice versa!)
Besides making it simple to add a package to your project, I think NuGet's biggest advantage is dependency management.
NuGet allows project owners to package their libraries as packages. Before, if they depended on other libraries like log4net, they would include those assemblies in their setup/zip file and upload to their web site.
With NuGet, they simply add a reference to these external packages in the .nuspec file. When NuGet installs the package, it will see that there are dependencies and will automatically download and install those packages as well. It also supports conflict management so that if 2 packages depends on different versions, it will figure out the correct one to install.
I think the best way to determine if NuGet will work for you is to actually try using it. I'm sure that once you do, you'll realize that it has many benefits.
Nuget provides several additional benefits:
it automatically configures your projects by adding references to the necessary assemblies, creating and adding project files (e.g. configuration), etc.
it provides package updates
it does all of this very conveniently
What advantage is there?
Nuget simplifies third libraries incorporation : With a single command line (Install-Package EntityFramework) you make your package available for your project. Instead of googling-find the package-download-setup-reference the package in your project...
Auto-Update is not mandatory, Nuget configuration file let you specify the version, or the range of version, that your application is compatible with.
Also, if I install entity framework via Nuget then is it available to any new solutions or projects that I create
Once you installed a package, dlls are copied in a directory at solution level, you can then reference them from there in others projects of your solution.
For each new solutions, re-installing packages is a better solution. As it is very easy with nuget, it won't be a problem.
Nuget contributes to creating a DLL hell and makes the solution go out of control very quickly, especially when different versions of so called "packages" come into play. Apart from assembly versioning, there are now nuget package versions. Nuget is just adding another wrapper over DLLs and does nothing that would make developers' life easier.