The NuGet package manager is handy for finding DLLs and supporting modules when you want to get something up and running fast. I like the search capability and the fact that the package knows what to install to make it work. However, I don’t like the fact that the package manager downloads every .Net version of the package plus every conceivable support file. I understand why it operates the way it operates, and I’ve seen the NuGet manager update packages when I change the .Net version of projects, etc. etc. In this post, I’m going to show how to unload the NuGet baggage and strip your application to what is needed. This will reduce the size of your installation and/or deployment package.
The NuGet Package Manager
You can add DLLs to your project by going to the Tools -> NuGet Package Manager -> Manage NuGet Packages for Solution (or you can use the console). Then select a package and hit the “Install” button. Some projects have packages already installed. One such project is the MVC4 project. If you open Visual Studio (I’m currently using VS 2012) and select “New Project”, then inside the “Web” projects, select “ASP.Net MVC4 Web Application”, then select the “Empty” application. Once the project is completed, you’ll see a file in your project called “packages.config”. Open that file (it’s an XML file, just double-click on it). Listed in this file are all the DLLs in the NuGet package. This will be your key to untangling the needed components.
In my sample, I have this in my packages.config file:
<?xml version=”1.0” encoding=”utf-8“?>
<package id=”Microsoft.AspNet.Mvc” version=”4.0.20710.0” targetFramework=”net45” />
<package id=”Microsoft.AspNet.Mvc.FixedDisplayModes” version=”1.0.0” targetFramework=”net45” />
<package id=”Microsoft.AspNet.Razor” version=”2.0.20715.0” targetFramework=”net45” />
<package id=”Microsoft.AspNet.WebApi” version=”4.0.20710.0” targetFramework=”net45” />
<package id=”Microsoft.AspNet.WebApi.Client” version=”4.0.20710.0” targetFramework=”net45” />
<package id=”Microsoft.AspNet.WebApi.Core” version=”4.0.20710.0” targetFramework=”net45” />
<package id=”Microsoft.AspNet.WebApi.WebHost” version=”4.0.20710.0” targetFramework=”net45” />
<package id=”Microsoft.AspNet.WebPages” version=”2.0.20710.0” targetFramework=”net45” />
<package id=”Microsoft.Net.Http” version=”2.0.20710.0” targetFramework=”net45” />
<package id=”Microsoft.Web.Infrastructure” version=”18.104.22.168” targetFramework=”net45” />
<package id=”Newtonsoft.Json” version=”4.5.11” targetFramework=”net45” />
First create a directory in your project, or you can create a directory in your solution to contain the DLLs that you’ll be using. I usually name it “3rdPartyDLLs”. If you have a lot of projects that use the same DLLs, you can create a shared directory. I prefer to keep the DLLs with the project, so I know the versions match the project when it was designed. Next, you’ll need to open the “References” directory of your project. Look at the first DLL that is listed in the xml file and match the name with the DLL listed in the References. If the DLL is in the References, then navigate to the solution folder and find the “packages” folder. Open that folder, drill down to find the matching DLL. If there are two or more .Net folders, then check the version in the XML file (most of the above are .Net 4, but some are 2). Drill into the .Net folder and copy the dll and xml (if it exists) files into your “3rdPartyDLLs” folder (just drag the files into your project folder of visual studio, a copy will be made).
Next, delete the reference in your “References” folder. Then “add reference” by right-clicking on the “References” folder and selecting “add reference”. Use the browse button to navigate to your project’s “3rdPartyDLLs” folder and select the DLL file that you just removed from the “References” folder.
Last, delete the entry from the packages.config file. Rebuild your project to make sure it still builds. If it does not build, you might need to make the reference DLL copy local (click on the DLL in the “References” folder and you’ll see in the properties window a “Copy Local” flag. Change that to “Yes”).
Now repeat this process until you have an empty packages.config file.
The final cleanup involves deleting the packages.config file in your project. Then delete the entire “packages” folder in your solution folder (you may have difficulty deleting the whole thing at once because Windows thinks that those files are opened someplace. I usually drill down into sub directories and delete the stubborn dlls first. Then back-out and delete the whole thing).
Now make sure you rebuild your project and fix any errors.
You can verify that you removed all NuGet package components when your packages.config file doesn’t re-appear and you can click on each DLL in your “References” folder and make sure the Path to each file doesn’t point to a package folder.