So, what does our Startup class actually look like? Well, in a similar fashion to the way we have been developing with TypeScript, C# starts with the class definition:

public class Startup
{
}

Unlike JavaScript, C# does not have a special constructor keyword. Instead, C# uses the name of the class to represent the constructor. Note that, just like JavaScript when we create our constructor, we don't give it a return type (we'll see how C# deals with return types shortly). Our constructor is going to receive a configuration entry to allow us to read the configuration. We expose this as a C# property using the following get; property:

public Startup(IConfiguration configuration)
{
  Configuration = configuration;
}
public IConfiguration Configuration { get; }

When the runtime starts up our host process, the ConfigureServices method is called. This is the point where we would hook in any services that we need; in this code, I've added an IDiscogsClient/DiscogsClient registration, which adds this particular combination to the IoC container so that we can inject it into other classes later on. We have already seen an example of the dependency injection happening in this class with the configuration being supplied to the constructor.

Don't worry that we haven't seen IDiscogsClient and DiscogsClient yet. We will soon be adding the class and interface to our code. Here, we are registering them with the service collection so that they can be injected into classes automatically. As you may remember from what we said earlier in this book, a singleton will only give one instance of a class, regardless of where it is used. This is very similar to when we generated services in Angular, where we were registering the services as singletons:

public void ConfigureServices(IServiceCollection services)
{
  services.Configure<CookiePolicyOptions>(options =>
  {
    options.CheckConsentNeeded = context => true;
    options.MinimumSameSitePolicy = SameSiteMode.None;
  });

  services.AddHttpClient();
  services.AddSingleton<IDiscogsClient, DiscogsClient>();
  services.AddMvc().SetCompatibilityVersion(
    CompatibilityVersion.Version_2_1);
}

The syntax on AddSingleton shows that C# also supports generics, so the syntax should not be scary to us. While there is a lot of parity in the language, TypeScript has some interesting differences here in that there aren't dedicated any or never types, for instance. If we wanted our C# type to do something similar to any, it would have to use the object type instead.

Now that the underlying services have been configured, the last step for this class is to configure the HTTP request pipeline. This simply means that this tells the application how to respond to HTTP requests. In this code, we can see that we already have support for static files enabled. This is very important for us because we are going to rely on static file support to hook our TypeScript (well, the compiled JavaScript version) so that it coexists with our C# application. We can also see that routing has been set up for our requests:

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
  if (env.IsDevelopment())
  {
    app.UseDeveloperExceptionPage();
  }
  else
  {
    app.UseExceptionHandler("/Home/Error");
    app.UseHsts();
  }

  app.UseHttpsRedirection();
  app.UseStaticFiles();
  app.UseCookiePolicy();

  app.UseMvc(routes =>
  {
    routes.MapRoute(
              name: "default",
              template: "{controller=Home}/{action=Index}/{id?}");
  });
}

It's all very well creating the C# infrastructure to fire up our application, but if we don't have anything to display, then we are wasting our time. It is time for us to look at the base files that are going to be served up.