Visual Studio, .NET Core, Amazon AWS CLOUD Development Project, JavaScript Date, Multiple Time Zones – Using Docker Desktop Locally To Simulate Cloud GMT UTC +0000 Deployment (Fixes Date Zone Shift)

Like many in larger companies, my current project is embracing the use of a cloud service to cut costs. As a natural consequence, projects which will make use of a cloud service will need to keep several new considerations at the forefront of design. This project is no exception, as our system will need to use a cross-platform run time to utilize both windows and Linux containers, will be used across 4 different time-zones (and allow for overriding browser display/input of dates for any one of those four) and must support multiple browsers on multiple devices (laptops and tablets).

I wrote this article to pass along my experience in testing locally our back-end API. As our back-end API (ASP.Net Core) and database (MySQL) will both be running in the cloud via Amazon AWS containers (whose system time will be UTC-0), running our API locally was problematic as dates would shift according to their JavaScript Date Offset, where this would NOT happen when hosted in an environment at UTC-0. Further, it was impractical to set my local system’s region to UTC-0 which would itself introduce a host of new problems such as errors/warnings when connecting to our cloud GIT repository.

The solution is to run a VM OR use a container-system such as Docker. My client has the option for developers to use their licensed Docker Desktop product, which also has integration into Visual Studio 2019, so this was the path I chose.

Naturally, you will want to install Docker Desktop to your machine first. You can install the free version of Docker from this link:
https://www.docker.com/products/docker-desktop
You will then need to install the Windows Subsystem for Linux Containers (WSL 2) for Windows which is a separate installation you get from Microsoft here:
https://docs.microsoft.com/en-us/windows/wsl/install#update-to-wsl-2

With Docker Desktop and the Linux Containers for Windows installed, you can now add Docker as a build-and-deploy option to your solution. Microsoft has a document on how to install Docker Support into your Visual Studio .Net CORE project:
https://docs.microsoft.com/en-us/dotnet/architecture/containerized-lifecycle/design-develop-containerized-apps/build-aspnet-core-applications-linux-containers-aks-kubernetes

The process is pretty simple and basically entails navigating Visual Studio’s Solution Explorer to the main project of your solution, right-clicking it to trigger the context menu and selecting ADD > Docker Support:

Adding Docker Support to an Existing ASP.Net CORE Main Project is as Simple as a Few Clicks

You will now see Docker as a selectable option along with IIS for build/run:

Visual Studio RUN Toolbar Option Will Now Include Docker Option

There is still a little more you will need to do in order for your Docker Container to run correctly. By default, your container will NOT have network access. Also by default, your Docker Container will dynamically assign a random external host port each time it is launched and map it to itself (example 45727:443 for SSL). Additionally, the automatic browser launch will be directed to the root URL of your API which usually provides no return value to determine if it successfully connected and is running properly. I will show you how to fix all three of these issues.

If your container image needs to access any detached network resource (not integrated/local) such as a standalone database or standalone API, you will need your container to have access to the host network. This is accomplished by editing the newly added Docker section of your application’s LAUNCHER.JSON file:

Many Options Exist For Configuring How Visual Studio Will Run Your Image In A Docker Container

For our purposes, all three aforementioned issues (network access, port mapping, browser launch url) can be resolved right here in this configuration file:

  1. To connect your container to the network for external DB access, add “–net=host” to the commandLineArgs entry
  2. To map a fixed host listening port(s) to your container, add those options and ports to their respective entries: “sslPort”: 44354 [and] “httpPort”:44355
  3. To direct the initial browser launch to a useful URL that provides feedback of successful run, simply add the additional route to the end of the launchURL entry:
    “launchUrl”: “{Scheme}://{ServiceHost}:{ServicePort}/YourRoute/YourPrameter

With these settings in place, your Visual Studio ASP.Net CORE project should now successfully launch your code in a container with its own default UTC+0 system date/time allowing for true replicated code testing!


This entry was posted in Uncategorized and tagged , , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s