With the latest changes added to our XbK on Docker repository (https://github.com/konabos/xbk-on-docker) you can now easily switch between the XbK versions.

Inside the .env file you can find now KENTICO_TEMPLATES_VERSION variable:

The default value of that variable is set to ‘latest’, which during the initialization of the project will install the latest available XbK templates and in the next steps of the process also databases and projects.

If you are willing to use one of the older versions you can simply change that value into a numerical version of XbK that you are interested in and re-initialize your project.

You will find all available versions on the changelog page: https://docs.kentico.com/changelog

Here is an example of the particular version being defined:

Whenever you change the template version you have to run the start script with the init attribute (remember to stop already running XbK containers):

The installation process has been also updated with other small changes:

• files of the website are removed before initialization starts (to remove published dev changes or to provide a better experience during the template type change)
• license file path is displayed (for validation purposes)
• mssql containers use root user

When you run initialization you will notice that even when you have already installed the latest templates, you can downgrade the version and XbK on Docker will use the one you selected:

With this change you can now quickly set up different versions and start using XbK on Docker for local development – without a need to apply any changes to the provided scripts.

For local development ,you may need to set up also your Visual Studio publishing profile.

Define publishing profile for folder deployment – you should deploy your files to “data\website” directory:

The other settings may look like these from the screenshot:

When you publish the changes, you may need to stop & start your containers again as Kestrel server may not restart after it. Based on this knowledge we can assume that a publishing profile can be used in case when you do not want to run your full development setup and you want to use a fully containerized environment.

When you think about regular development, you can still use ‘dotnet watch’ command that will start a local (not containerized) kestrel server connecting to the containerized database.

As a result you will see two separate kestrel servers available on the localhost domain but with different ports:

As you can see, XbK on Docker gives you many options that you pick from and adjust if needed.

Mover your developer’s experience to the next level and start using Docker.