Why Entity Framework is releasing on NuGet only

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.)

Managing dependencies

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.



44 comments on “Why Entity Framework is releasing on NuGet only

  1. matthidinger says:

    Good reasoning for a solid decision. I’m starting to make my open source projects NuGet-only as well, and find that it encourages me to release more frequently — hopefully the same will be said for EF vNext :)

  2. Zhu Coder says:

    As part of our products deployment, we document EF 4.1 Update 1 or latest as pre-requisite; but how do we tell our msi package to check if it’s actually installed before proceeding? Having an msi or a redist would be great. I may be be missing something, so feedback welcome!

    • The short answer is that you don’t install it, you include it with your product. Let’s say your app is simple and consists of one assembly–MyApp.dll. If your app uses EntityFramework.dll, then distribute MyApp.dll and EntityFramework.dll together. If it uses other NuGet packages, then include the assemblies from those packages as well. You then ensure that the app always has the correct version of EntityFramework.dll available and won’t have conflicts with other apps on the machine, and you don’t need to check for it being installed because it isn’t installed, it’s just always there with your app.

      • Zhu Coder says:

        Thx++ for your prompt reply! Very much appreciated :)
        Proceeding as you described is great, but what if 56 big services are shipping? will each ship with one version of the dll, even though it’s the same version? My belief has been that redundancy can be eliminated with the GAC help. True, installers may be instructed to GAC a given assembly, but which one will do so if you ship 56 different services in 56 or less installers?

      • Disk space is cheap. If you had 56 services all using the same EF assembly and that assembly is about 1MB, then you would save 55MB of disk space. So don’t do it to space disk space on a server. That being said, if you are in control of the system and are very disiplined about what gets installed on it, then you can GAC the assembly. Just be aware of the problems this can cause if anything else on the system needs to use a slightly different version. For example, if some app depends on a bug fix included in 4.3.1 (when available) but then 4.3.0 is GAC’ed, then the app will fail.

      • Zhu Coder says:

        Thanks again for your prompt feedback. Few more Q please:

        0. Assuming that co-existance is not an issue for us, can post 4.1 Update 1 entity framework assembly be GAC’d by our installer, even if not done via MS?

        1. my understanding is that it’ll eventually be part of the .NET Framework. Please correct me if wrong.


      • 0. Yes.
        1. It is extremely unlikely that EntityFramework.dll will ever be part of the .NET Framework.

  3. Zhu Coder says:

    Thx++ for taking time to respond. Much appreciated, no more concerns for now :) Thanks again and have a great one!

  4. Andrew Walsh says:

    I have a set of projects in a solution. One of them is our DAL and another implements it. When I tell the package manager to install EF 4.3 in our DAL project, it keeps putting the packages folder under the implementation instead.

  5. Ady says:

    How do I get the latest design-time tools for EF? Also via NuGet or there is a separate msi for that?

  6. I guess MS have missed the really obvious point that it is critical when developing software to have complete control of the development and deployment environment and any components used. Now that you cannot download an installer you can never guarantee to be able to build or develop your software. MS and NuGet can sabotage any organisation by removing a component from installability. Also, needing to give your live and build servers access to the net in order to complete an installation is a security risk and factor that is no longer in the developer hands. If you don’t believe me just check. EntityFramework 4.3.1 is already no longer available, which means you cannot setup a new development PC without upgrading your projects. MS, you have been throwing your market share away in this sort of way for years now. When will you do the right thing and make me a senior manager so that I can put you back on a competitve “road map”.

    • @John I’ll try to address your points one at a time:
      – “MS and NuGet can sabotage any organisation by removing a component from installability”
      Once you download the NuGet package it’s in your hands in the same way that an .msi installer would be. You can keep it around, setup a local feed, extract the .dll from it, etc.

      – “give your live and build servers access to the net in order to complete an installation”
      NuGet doesn’t work like this. Your servers should never be accessing NuGet in order to install packages. The packages are downloaded during development and then the assembly is deployed along with the rest of your application. NuGet is never involved post-development. Even for development, you don’t need your dev PC to be connected to the Internet. Setting up a local feed is trivial.

      – “EntityFramework 4.3.1 is already no longer available”
      I just downloaded it so it is definately still available. What is more, all previous versions of EntityFramework that have been released on NuGet are also still available and easy to access. You can see the list here: http://nuget.org/packages/EntityFramework/4.3.1 Click on a link for any version and copy-and-paste the line into the NuGet package manager to install an older version.

      • Blop says:

        +1 for security reasons in big company with high security level you cannot make nuget working, thus you cannot download entity framework package and cannot develop anything. Where is the point to not provide a download link like http://packages.nuget.org/v1/package/download/entityframework/4.3.1 .

        About “local feed is trivial” the answer of nuget is “there is no download link because NuGet provides a faster better way to incorporate a library into your project.”
        In a perfect world peraphs…

  7. kaplandani says:

    I prefer the MSI Installer.
    You don’t get this when using the MSI:
    Install-Package EntityFramework -Version 4.3.1
    Install-Package : The element ‘metadata’ in namespace ‘http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd’ has invalid child element ‘frameworkAssemblies’ in namespace ‘http://schemas.microsoft.com/packaging/2010/07/
    nuspec.xsd’. List of possible elements expected: ‘iconUrl, dependencies, title, tags’ in namespace ‘http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd’.
    At line:1 char:16
    + Install-Package <<<< EntityFramework -Version 4.3.1
    + CategoryInfo : NotSpecified: (:) [Install-Package], InvalidOperationException
    + FullyQualifiedErrorId : NuGet.VisualStudio.Cmdlets.InstallPackageCmdlet

  8. Brian says:

    Hi Arthur – Looking into using EF to replace Linq to Sql but I am uncertain about how the NuGet only setup will work in our environment. In our team setup, we use a separate folder to hold DLLs from third party vendors. We would reference this folder from our VS projects. If I can only get EF through NuGet, how can I make it work with our setup? Would I just copy my version of the EntityFramework.dll to this folder? This setup works well for us and our automated deployment process. I don’t want to tell my fellow devs that everytime they use a project that has EF they would have to NuGet it into that solution. Not sure if my understanding is off either…. Thanks!

  9. @Brian I think NuGet probably fits your needs quite well. The idea of NuGet is to download external dependencies and drop the assemblies into a lib folder. The only thing that might not be ideal is that the lib folder NuGet wants to use is probably different from the one you are using. You might want to request a feature from the NuGet team to let this folder be configured. Still, you should be able to copy the assemblies manually into your folder and have everything work.

  10. Brian says:

    Arthur – Thank you for your response. So, would I be able to do the following: Use NuGet to get 4.3.1. I would then copy the DLL from the solution’s packages folder to our own folder. In the application, I would then remove the reference to that EF DLL and set a reference to the DLL in my folder. Would this work? Do I have to remove the solution’s packages folder? Thanks again!

  11. Tim says:

    Understood. However, this does not bode well for large teams of developers using TFS. Yes, I understand that each dev’s bin folder will not be uploaded to TFS, however, the “libs” folder that NuGet manages for each project will.
    What we do in TFS is have a separate “Common” or “Core” project which houses all current versions of 3rd party libs. This allows us to have one location for referencing binaries. That way, it’s only downloaded and referenced once and in one-central location.
    The big advantage to this is that another developer can open your project and immediately build and run it without having to worry what needs to be installed and why there are missing references and how to install them. I have used this methodology in TFS, SVN, GIT and it all works very well. This also reduces the amount of space binaries take up in a Source Control system.

  12. Sreeni says:

    What if I have earlier version of EF installed and get latest version from NUGet? Older version(MSI install) would have gaced dlls & used registry entries etc., Is VS smart enough to look first at packages directory prior to looking at MSI install locations while generating EF components?

    • In most cases there shouldn’t be any issue. If you have EF 4.1 installed from an MSI then you may have issues if you try to use a different EF 4.1 from NuGet. (This was before we were using semantic versioning.) If you use 4.2 or above from NuGet the there won’t be issues. Make sure that all your projects are referencing the same version of EF.

      The only other thing is that if you have the EF June 2011 CTP installed then you should uninstall it. This CTP has been superseded by EF5 and the VS 2012 RC.

  13. microproducer says:

    Hi Aurther,
    When I try to install NuGet 1.8 from VS / Tools /extenstion manager, I get the Exception from HRESULT: 0x80070035: “Network Path Not Found” error. I don’t appear to have a nuget extension installed yet for VS 2010 SP1, and… I am able to install other VS extensions. Please assist

  14. Thanks, but I have had no success with codeplex. I also had heard (from a user on codeplex) that NuGet was automatically included in VS 2011. Well, I installed the beta version, and this is not the case. I want a ‘database first’ approach, with with EF 4.x, and I am unable to use the DBContext class generators until I tackle this NuGet nonsense.

    • NuGet 1.8 is included with VS 2012 RC. An earlier version (I think 1.6 but not sure) was included with the beta. With VS 2010 SP1 you can install it from Tools|Extension Manager… in the Online Gallery. I just this a minute ago and didn’t run into any issues. I’m sorry if you are having problems with this. If you filed a bug against NuGet on CodePlex then let me know the bug ID and I’ll ping the NuGet team about it.

  15. Måns Tånneryd says:

    I have included the EF 5 prerelease using NuGet in my VS2012 solution. The EntityFramework.dll is nicely copied to the output directory of the project referencing it (project A). But, my main project (project B) that references A ends up without the EntityFramework.dll in its output directory. This is confusing to me since I have other similar references that do work as expected. Any ideas?


    • This sounds like the correct behavior to me. As in, this is the way Visual Studio handles assembly dependencies for assemblies that are not GAC’ed or referenced from some other installed location. If B references A and A needs EntityFramework.dll, then B needs EntityFramework.dll, so it is copied to the output directory.

      • Måns Tånneryd says:

        But it is NOT copied to the output directory of project B. It is only copied to the output directory of project A. So, when I try to run my main program (B) there is no EntityFramework.dll in that directory.


      • An easy fix for this is to install the NuGet package into both projects. This will not download the package twice but will add a reference to it in both projects.

  16. ioannidisat says:

    Though I really like the whole nuget concept and I can play around while at home, it is really frustrating while at work.

    1) My dev machine has no internet access, and also I am not allowed to install anything. I am not admin.

    2) We have an \”Internet Server\” which is practically a machine only to open a browser and connect to internet. Almost nothing is installed on this machine and it is really painful to do so since we also don\’t have admin rights.

    3) After trying, for HOURS, to do the simplest of the simplest things (download a *.zip with the EF 4.3 dll which I needed, from a website), I saw this blog. I managed to download nuget.exe to the Internet Server .I had to rename it into a zip first because we are not allowed to save even exe\’s here. Then, after I saved it as a zip, i renamed it into an exe again, and then I had to unblock it. After all this hassle I was really excited that I could DOWNLOAD something, eventually… But… no… this nuget.exe needs .NET 4.0 installed. And f course internet server does not have .net 4 installed and it won\’t have it… i tried every machine with .NET 4.0 installed but none of them had internet connection… :( :(

    I can really understand that you don\’t want to maintain many installers. That\’s ok. MSI would not work for me probably, unless it doesn\’t need admin rights.

    But why, OH WHY, have I to be punished like that?? Is it so hard to have a SIMPLE link to a zip file, somewhere so that I can \”RIGHT+CLICK n SAVE AS\”, then extract the dlls from the zip and reference them in my project?? What\’s so wrong and evil about it, that it shouldn\’t happen?? People could download things from the browser since the dawn of time, WHY not anymore??

    • There are arguments against providing a download link, one of them being that experience shows some people will blindly download the file and then have no idea what to do with it causing a lot of confusion. That being said I agree that in situations like yours (which frankly boggles my mind!) it would be useful. A colleague snooped a bit and found that currently you can use this link to download the package: http://nuget.org/api/v2/package/EntityFramework/4.3.1 This may not always work if NuGet changes its API but hopefully it gives you what you need for now.


      • Update: It appears that if you login to NuGet.org and browse to the package then there is now a download link. However, it’s only visible if you login.


  17. xborland says:

    My Corporate IT department has a firewall policy that all binary downloads must be approved, or come from whitelisted domains such as microsoft.com. They won’t whitelist nuget, because it contains all sorts of projects from all sorts of publishers, not just “trusted” ones like microsoft. While I realise that brainded internal IT policies like mine aren’t the best reason for you guys to release a .zip or .msi download, It really would help me out :-)

    • If you login to NuGet.org and browse to the package then you will see a download link for the zip file. The link is only visible after you login. We don’t have any plans to move this link to a different domain. All the binaries are, of course, signed.


  18. Burak TARHANLI says:

    Thank you so much for explanation. I was looking for this.

  19. mikanke says:


    we have developed a simple application that connects to Oracle and uses EntityFramework 5.

    In the develop machine, with oracle 32 bits drivers installed, all runs ok.

    But when i deploy to the server (WS 2012 R2 with 64 bit Oracle drivers) it doesn’t find the oracle drivers.

    The entityFramework.dll is deployed in the bin application folder.

    The doubt that i have, is if the entityframework.dll is in 32 or 64 bit, and if i can connect with that dll with 64 bit oracle.

    I’ve tried to install 32 bit oracle in the server, and it runs…¿how i can adquire a 64 bit compatible dll?



  20. Kyle says:

    Nuget is not the right method for our corporate environment. We have servers we are trying to install EntityFramework on and we do not allow them internet access. From our PC side we are restricted from running certain exes (nuget.exe) included. In our case not having an MSI to install is going to most likely force us to not use EntityFramework because it is extremely cumbersome to go through the process to download without internet or nuget. I am not sure if this is an oversight or on purpose, but pretty horrible decision in my mind.

    • @Kyle EF should not be installed on a machine. EF should be distributed as part of an application that is then installed on the machine. Therefore, the server should never need to access NuGet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s