EF 4.2 and 4.3 were released via NuGet only—there are no MSI installers. The up-coming EF 5.0 release will continue this pattern. But why NuGet and why only NuGet? It’s not because NuGet is awesome, even though it is, or because it’s the hot new thing, even though it is. It’s because it is a great match for delivering the EF runtime. This match comes from four things that NuGet does really well: setting up apps for bin-deployment, managing dependencies, providing easy project-level and PowerShell integration, and helping developers know about and get the latest version.
In simple terms, bin-deployment means “installing” your application by taking it and its dependencies and simply copying everything to the place where it will be run. It doesn’t involve setting registry entries, putting assemblies in the GAC, or otherwise messing with the deployment machine. This makes it ideal for deployment to machines you don’t own, like a web server. However, it’s also great for other kinds of applications—if everything works without having to mess with machine configuration, then that’s a good thing.
Because bin-deployment doesn’t require messing with the deployment machine it means that releases of EF can happen frequently and you don’t need to wait for these releases to be installed on your deployment machine. For example, you don’t have to wait for your web hoster to get around to installing the new EF on all machines. Instead you just copy the EntityFramework assembly to the machine along with your application.
Bin-deployment also means that each EF app “installed” on a machine is independent of others. If you have a 4.1 app up and running and then bin-deploy a 4.3 app to the same machine it will not impact the 4.1 app. The 4.1 app will continue to use 4.1 so even if there was a breaking change between 4.1 and 4.3 it won’t be affected. (As an aside, you shouldn’t GAC EntityFramework.dll. It doesn’t need to be GACed and is designed to not be GACed.)
NuGet is designed to set things up for bin-deployment. The assemblies downloaded in NuGet packages are co-located with your application so they are ready to be copied along with your application.
(Right now it’s true that some of the EF core libraries are not bin-deployable. We’re working to make more of EF bin-deployable in the future.)
What if you want to use some library that itself uses (depends on) EF? How do you know where to get it and what version to get? NuGet makes this kind of thing easy since it’s a package manager and this is what package managers do. ‘Nuff said.
Project-level and PowerShell integration
When EF is installed into a Visual Studio project is may need to set things up in that project or take actions based on information in that project. For example, EF Migrations (released in EF 4.3) integrates with PowerShell in the Package Manager Console to provide a PowerShell experience for migrations fully integrated with your project. In EF 5.0 the NuGet install will also do some manipulation of config files at install time.
Would it be possible to do all this with a traditional MSI installer? I’m sure it would, but it would be harder, more fragile, and more opaque. Because NuGet puts you right in the project and integrated with PowerShell at install time it makes doing this kind of thing easy and clean.
Getting the latest version
NuGet is the place to go to get the latest version of EF—if you want to know what version of EF is the latest, then look in NuGet. NuGet also helps ensure that developers automatically get the latest version and helps with updates of an existing app to a new version. Again, this is what package managers do, and NuGet does it well.
What if I can’t use NuGet?
What if you can’t connect to the Internet from your development machine. Or what if you are not allowed to install NuGet on your machine. Don’t worry; all is not lost.
First you need to get the NuGet package. For this you do need to be able to connect to the Internet from some machine—but it doesn’t have to be your development machine. You’re reading this so presumably you’re not completely off-the-grid. :-)
You can get the package by using NuGet in Visual Studio on a machine connected to the Internet in the normal way—just install the package you want into a dummy project. After installing the package you can find the .nupkg file either in the dummy project folder or by browsing the Package Cache from the Package Manager Settings menu option.
You can also get the package without Visual Studio by using NuGet.exe.
If you are able to install NuGet on your development machine then do so and setup a local feed. This may sound daunting but it’s really easy. Copy the .nupkg file to your local feed and then use NuGet to install it in the normal way—with no connection to the Internet required.
If you can’t install NuGet on your development machine then take the .nupkg file and rename it to .zip—yep, it’s a zip file. You can now extract EntityFramework.dll from the zip file and use it as you would any other assembly. Note that you will not get any of the automatic project-level integration I mentioned above, so you may have to do more manual configuration of your project.
What if none of this works for me?
Then we would like to hear from you to understand what we can improve or do differently. If there is enough demand to release an MSI then we will consider it, but we would rather spend time implementing new features rather than maintaining two forms of installer, especially since the MSI installer is not really a good match for EF. Right now it seems to us that the number of people who can’t use NuGet in some form to get the package is very small. If we’re wrong about that then let us know and provide some details as to why it doesn’t work for you.