Skip to content

Latest commit

 

History

History

Tgstation.Server.Host

Tgstation.Server.Host

This assembly is the primary TGS executable and does basically everything.

Before going forward, note that there (usually) is a one-to-one mapping of interface/implementation when it comes to classes. This is for ease of unit testing and facilitating saner dependency injection.

Server startup can be a bit complicated so here's a walkthrough

  1. The Main method in Program.cs is called.
  2. The default IServerFactory instance is created via a static method in the Application class.
    • The Application class is what's called the composition root. A good article on this principle can be found here.
  3. CreateServer() is called on the IServerFactory to get the IServer instance.
    • The factory pattern is used throughout TGS to construct implementations where the composition root is not sufficient. ServerFactory is somewhat of an exception to this because it exists outside of the dependency injection umbrella.
  4. Inside CreateServer() we run the setup code if need be.
    • This is implemented as a separate dotnet host to the main server.
  5. Still inside CreateServer() we configure the main dotnet host (IHostBuilder) using the application Application class as the Startup class.
  6. The IHostBuilder is used to construct the return Server implementation.
  7. Run() is called on the IServer instance.
  8. The DI container is built using the Application class.
  9. The component services are started.
  10. The web server is started.

Here's a breakdown of things in this directory

  • .config contains the dotnet-tools.json. At the time of writing, this is only used to set the version of the dotnet ef tools used to create database migrations.
  • ClientApp contains scripts to build and deploy the web control panel with TGS.
  • Components is where the bulk of the TGS implementation lives.
  • Configuration contains classes that partly make up the configuration yaml files (i.e. appsettings.yml).
  • Controllers is where HTTP API code lives and bridges it with component code.
  • Core contains Application.cs and other classes related to the overrarching server process.
  • Database contains all database related code.
  • Extensions contains helper functions implemented as C# extension methods.
  • IO contains classes related to interacting with the filesystem.
  • Jobs contains the job manager code.
  • Models contains ORM models used to interact with the database.
  • Properties contains some assembly metadata, mainly used to expose internals to the testing suite.
  • Security contains all the security related classes.
  • Setup contains code to initiate and run the setup wizard.
  • Swarm contains code relating to grouping multiple TGS processes on different machines in a cohesive cluster.
  • System contains various OS related functions.
  • Utils contains various helpers that don't belong anywhere else.

As a final note, all project configuration is of course in the Tgstation.Server.Host.csproj file. This contains package references that are pulled in on build, as well as other things like global warning supressions, and specialized build scripts.