1.4: Overview of API Project Files

Program.cs

public class Program
{
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();
}

The void Main(string[] args) method will probably look familiar to you from building console applications.

That's because an ASP.NET Core web application is a console application!

This class builds our WebHost, passing in our Startup.cs class - which we'll be looking at next.

Startup.cs

It may look confusing at first, but we'll be working in this file a lot, so it's important to understand what's going on here. It's ok to only have a vague idea at the end of this section. By the end of the tutorial, I hope your understanding is much deeper.

There are two methods in this file.

1. ConfigureServices()

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
}

This method takes an IServiceCollection - this is our dependency injection container. This method is simply for adding services to our container. After "registering" a service here, they will be available to be "injected" elsewhere in our application. Don't worry if this is confusing to you. We'll be learning more about it as we go. Or, if you are curious - read about it more in the docs.

1. Configure()

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseMvc();
}

This method is where we configure our request-response middleware pipleline (using IApplicationBuilder).

Right now, this is fairly small, but we will build it out as we progress.

So far, it checks if the environment is set to Development - if it is, it displays developer exception pages ("yellow screen of death"). The second tells the application to use MVC.

The request comes in and runs these in order to build the response. Read more about middleware in ASP.NET Core if you'd like.

EFConnect.API.csproj

This is a XAML file that is primarily used for the package dependencies for our project.

One key thing to notice here is that we are adding a package reference to Microsoft.AspNetCore.All. This is a "metapackage" holding all of the packages of ASP.NET Core, Entity Framework Core, and all 3rd party dependencies. Wow! That might seem unnecessary -why are we importing all packages? Won't that make our project bloated with stuff we don't necessarily need?

What is happening is that all of these packages are installed on your local machine. You should be able to access them at C:\Program Files\dotnet\store\x64\store. ASP.NET Core will "borrow" these files when your application needs them. Very cool - makes for fewer imports and it makes for much less overwhelming XAML.

appsettings.json and appsettings.Development.json

These are two json files that will hold our configuration settings. This is where we will add things like our Connection String, app secrets, and other configuration information. We aren't going to add anything to it right now - but, you probably already prefer it to web.config from MVC 5!

wwwroot folder

This folder is where static files like HTML, CSS, and images go. Right now it is empty - and, for this project, it will stay that way until we are ready to deploy.

Controllers folder

This folder should be pretty familiar from MVC 5. Project creation gave us a default controller that returns values. We already used this method:

[HttpGet]
public IEnumerable<string> Get()
{
    return new string[] { "value1", "value2" };
}

That looks familiar, but one thing to note is that the ValuesController inherits from the Controller class and not the ApiController class. There is no ApiController class in ASP.NET Core!