Skip to content
Webslice Containers & Webslice Serverless Documentation

Working With .NET Core Web Containers

This article show you how to customize a .NET Core + SDK container to run an example application.

The first step is to create a container running the .NET Core + SDK web image. When you do, create an SSH/SFTP User as well.

Method 1: Build, Test, and Debug on the Container

Then the overall process is:

  1. Connect to the Container and build a .NET Core project.
  2. Publish the web application.
  3. Adjust the Container configuration to start the application on boot.
  4. Test the application.

Creating and Building the App

We’re going to mostly follow Microsoft’s get started with ASP.NET Core MVC documentation, and adapt to Webslice Containers as we go.

  1. SSH into the Container.
  2. Create a project using the mvc template.
  3. Remove the existing example application.
  4. Publish the project into the /container/application directory.

The example code below uses the project name “CustomApp”. A directory with that name is created, and project files should be under ~/CustomApp. The published application files should reside in the /container/application/ directory.

# ssh myuser@123.123.123.123
$ dotnet new mvc --no-https --exclude-launch-settings -f net6.0 -o CustomApp
$ rm -rf /container/application/*
$ dotnet publish -c release --no-restore CustomApp/ -o /container/application/

Configuring the Container

Once the application is published, you can configure Supervisor to start the application up on boot. The supervisord.conf configuration file has a section named [program:dotnetapp] that you can can use as a reference.

$ nano /container/config/supervisord.conf

You can comment out the line and replace the default command for this program to start the application that you just created. Here is what the configuration file should look like:

[program:dotnetapp]
directory=/container/application/
;command=/usr/bin/dotnet ExampleApp.dll
command=/usr/bin/dotnet CustomApp.dll
stdout_logfile=/container/logs/supervisor/%(program_name)s-stdout.log
stderr_logfile=/container/logs/supervisor/%(program_name)s-stderr.log

To apply your configuration changes, reboot the Container.

Test Your Changes and Debug

After your Container has restarted, check the website on a browser. If it is not working as expected, follow the dotnetapp program logs and debug through your SSH session.

tail -f /container/logs/supervisor/dotnetapp-std*

After every change to the project files you want to deploy, you must publish the application and reboot the Container again. Unless you change the project name, you won’t need to update the Supervisor configuration.

Method 2: Build and test Locally, Then Deploy to Your Container

To avoid putting an unnecessary load on your Webslice Containers server, you can store application project files on your workstation. By building and testing locally on aan Integrated Development Environment (IDE) you don’t involve your Container or its server until you’re ready to publish.

Webslice Containers are based on Linux, so once your application is developed and tested, ensure that it’s published to run on Linux. Read more in Microsoft’s’ dotnet publish documentation.

dotnet publish -c release --runtime linux-x64

After publishing your application, SSH into your Container’s and upload it to the /container/application/ directory. on the Container. Then make any required changes to the supervisord.conf configuration file (see “Configuring the Container” above). As always, reboot the Container to apply your changes.