May the Source Be With You
The source code for the NuGet Gallery, the same code that runs http://nuget.org/, is hosted on GitHub at https://github.com/nuget/nugetgallery/. To obtain the source code on your machine, read the instructions in the README on that page.
These instructions are geared towards those who have some basic knowledge of Git and plan to contribute to the NuGet Gallery project. If you simply want to see the source code without futzing around with Git, you can also download a zip file: https://github.com/NuGet/NuGetGallery/zipball/master.
Once you have the source code on your machine, makesure you have Visual Studio 2010 SP1 and the other prerequisites mentioned in the README (Azure SDK and NuGet) installed. Run the PowerShell script .Build-Solution.ps1 to verify that your development environment is set up correctly. The script builds the solution and runs all the unit tests. If it succeeds, you're good to go.
When you open the solution in Visual Studio, you'll notice that there are only two projects, as shown in Figure 16.1.
The Facts project contains all the unit tests for the project.
The Website project contains the ASP.NET MVC project. “But wait,” you ask. “Where is the Models project? And where is the NuGetGallery.Core project? How can this be a real-world application unless it contains a bajillion projects?”
Many ASP.NET MVC applications prematurely split the solution into multiple different class libraries. One reason this happens is a holdover from the very first version of ASP.NET, where a website could not be referenced from a unit test project. People typically created a class library containing all the core logic and referenced that one from the unit test.
This ignores the fact that an ASP.NET MVC project is a class library! It's possible to reference the project from a unit test project just as the Facts project does.
But what about the other reason to separate a solution into multiple projects, separation of concerns? Splitting a solution into multiple projects before the need arises doesn't magically separate concerns. Concerns are separated by paying attention to class responsibilities, not by simply splitting code into more assemblies.
The NuGet team figured that most of the code for the project would be specific to this project and not generally reusable. In cases where we did write code that was more broadly reusable, we placed that code into its own NuGet package and installed the package into this project. The WebBackgrounder library and package is one great example of this.
Expand the Website project and you'll see there are a lot of folders, as shown in Figure 16.2. Each folder represents either a distinct set of functionalities or a type of functionality. For example, the Migrations folder contains all the database migrations (covered later in this chapter).
There's a lot of functionality in there, and that doesn't even include all the third-party libraries the project uses. To get a sense of all the various technologies in use, open the packages.config file in the root of the Website project. At the time I write this, 33 NuGet packages are installed. That isn't an accurate number of separate products in use since some products are split into multiple NuGet packages, but it gives an idea that there's a lot of third-party libraries in use. Covering all this would require an entire book, so I'll pick a few notable areas to cover. These are all concerns a real-world application typically needs to deal with, but it is not necessarily a comprehensive list.