.NET uses a program called NuGet to fetch dependencies.

It has a programmatic interface.

Several files (e.g. .aspx files) are written in a template language. They come a corresponding .cs file which contain some C# code. That code is dynamically compiled (and cached) when someone requests the page. This .cs file is where events and behaviour go.

It's designed that way so that designers and coders can work separately. In practice, meh.

Web.config

this is like a pom.xml. Tell us what compilers we're using, what libraries we depend on, and what .NET version we're using. Corresponds to an App.config in non-web .NET development. Can have sub-versions which override specific properties.

packages.config

dependencies are written here. NuGet uses it to fetch dependencies.

global.asax

lets you respond to events from outside, including Application_Start.

App_Start/BundleConfig.cs

registers some ScriptBundle objects, which are lists of JavaScript files.

Bundle.config

points to some static reosurces like css files.

App_Start/RouteConfig.cs

provides RegisterRoutes method, which modifies a RouteCollection.

something.aspx

a Page.

Site.Master

a MasterPage. This is an HTML template with a placeholder. It's for headers and footers and so-on.

something.ascx

this is a User Control.

something.asmx

this is a Web Service.

something.ashx

this is an IHTTPHandler.

The simpliest way to make a webservice is be implementing your own IHTTPHandler.

If you use asmx, you get a load of XML junk which you don't want.

Web API is based on ASP.NET MVC.

The controllers inherit from ApiController.

It takes a fairly strict view of REST, providing the following methods:

Get

list things of that type

Get(id)

show that thing

Post(string)

create a thing from this string

Put(id, string)

relpace the thing for that id using this string

Delete(id)

delete that thing

It's pretty clear, but probably a bit limited in its use.