Blog Feed

Logging Net Core App to Debug window

Reading time: 3 minutes


In this post I will explain how to setup logging so that output messages shows in one of the debug windows i.e. Output.

What is required

  • Visual Studio
  • Net Core Web App

Let’s start by creating a Net Core App

Open Visual Studio and choose ASP.NET Core Web Application.

Then add the name and specify the location.

As for template select Web Api.

Next step is to edit Program.cs file

We need to edit a code that builds a host object. In essence it is a place where everything gets set up i.e. DI, Logging, Configuration, IHostedService implementations.

For this tutorial we are interested in Logging only.

public static IHostBuilder CreateHostBuilder(string[] args) =>
                .ConfigureLogging(logging =>
                    // override the default set of logging providers added by Host.CreateDefaultBuilder

                    // add the required logging providers
                .ConfigureWebHostDefaults(webBuilder =>

Below is how your Program.cs should look like.

Next step is to edit a logger code

Open up generated controller file. Make sure you got ILogger injected through a constructor. Then add the logger LogInformation method to the controller Get method.

As part of this step let’s add am Output window. Go to View -> Output and this should show an Output Tab.

Next thing is to Debug this app

Make sure you got Debug Configuration selected. Then either click F5 or Click the IIS Express button. Also for convenience sake untick Enable SSL for this web project in project Properties.

As you can see in the image the Output window shows our logger message.


Since Net Core SDK has a default Logging provider it is very easy to log stuff.

Logging is a powerful tool when dealing with development issues. Moreover it is a friend to a programmer. Because with the correctly used logging approach you have more information regarding running processes in your application.

Normally after analyzing logs you can get a hint as to where to look for bugs. It could be a real time saver.

Logging Net Core App to Azure App Service logs Filesystem

Reading time: 8 minutes


In this post I will explain how to setup logging for Net Core Web App with logging messages to be monitored on Azure App Service.

What is required

  • Azure Subscription
  • Visual Studio
  • Net Core Web App

Let’s start by creating a Net Core App

Open Visual Studio and choose ASP.NET Core Web Application.

Then add the name and specify the location.

You can select whatever web application template you want. To keep the habit of using a modern framework for frontend I will select an Angular template.

Next thing is to add Nuget package for Azure App Service Logging

Right click on the project and select Manage Nuget Packages. In that tab search for Microsoft.Extensions.Logging.AzureAppServices

Next we need to modify Program.cs file

By doing so we are adding logging to our application that would be monitored with Azure App Service for this application.

public static IHostBuilder CreateHostBuilder(string[] args) =>
                .ConfigureLogging(logging =>
                      // To override the default set of logging providers added 
                      // by Host.CreateDefaultBuilder, call ClearProviders
                      // add the required logging providers
                .ConfigureWebHostDefaults(webBuilder =>

This is how the Program.cs file should look like.

What you need to decide is the Log level that you will be logging. One of the main things with logging is making sure you are logging the appropriate information. For instance Debug level would be too much for production. Moreover it can expose some sensitive information. The amount of logging in production should only be necessary information which would not affect the performance of the application. More information here.

For this case let’s leave default settings in place. This means Information log level will be logged.

Let’s modify an existing controller that was created for us. Make sure you got ILogger injected to your constuctor. ILogger comes with Net Core SDK and this is a minimum you need to do.

Next step is to Publish this application to Azure App Service

Same as when you added Nuget package in the previous step right click on the web application project and select Publish.

On the next screen select Azure.

Then select Azure App Service (Windows).

On the next screen select the appropriate subscription. After that click on Create a new Azure App Service.

On newly opened pop out select your subscription. For the Resource group and Hosting Plan add new ones. In my case since I am on a Free Subscription I will choose a free tier plan.

After you click Create the pop out will close and you will get back to the App Service details window with the new Resource group selected. Click Finish.

On the Publish tab you need to find the Publish button and click it. This will actually trigger the Publish process. You are also provided with a URL for this app. Once the app is published you will be able to see your active app.

You can monitor publish progress in Visual Studio Output window.

Next step is to activate logging on Azure

Go to azure portal home and select App Services.

On the next page select the name of your newly created App Service. In my case it will be NetCoreAzureLogging20200601230511

On that page scroll to the Monitoring section and select App Service logs.

Use the toggle button and move toggle to option On. For Level choose Information. Click Save.

Alright let’s manually test what we made here. Since it’s a HttpGet Api method we can use any browser. Enter web app URL into address bar with controller name prefix. It should read yourAppServiceUrl/yourControllerName. In my case it is

If we go back to the Azure portal to your App Service. Scroll to Monitoring and select Log Stream.

Once you are there you should see a line with Information Log level with the message we added to the controller.


As you can see setting up Azure logging is quite simple. What is more important is to think what level to log, where to store it and what exactly is required for each environment.

Logging is one of those things that can help you and on the other hand be a culprit of slower application.

It is certainly useful to have with every application as this would be an additional assistance for any case that requires monitoring. So please use it with caution.

Create, clone, commit to GitHub repository

Reading time: 5 minutes


In this post I will explain how to create a repository using Sourcetree and upload it to GitHub. As part of this process I will also create a Net Core Web App that would be committed to a remote GitHub repository.

What is required

  • GitHub Account
  • Visual Studio
  • Sourcetree GUI for Git

Let’s start by creating a local repository using Sourcetree

Open Sourcetree and add new tab. On new tab click on Create.

On the next screen we should specify where to create a folder that will hold the repository files. Also an important bit is to tick Create Repository On Account. This way we are creating a connection between your local repository and remote repository that will be created after you confirm details by clicking Create.

If you got to your GitHub account you should see the newly created repository.

You can see that the repository folder together with the Git folder have been created at the location you previously specified.

Next step is to open Visual Studio and create a Net Core Web App.

Make sure you use the app name we used to Create repository since Git is tracking that location.

If you go to the location where you placed your repository. You should see the next picture.

Moreover Git tracked these changes. If you go to Sourcetree this is what you should see.

So let’s click on Stage All, add a commit message and click Commit.

Next step is to push your local changes to remote repository.

And if you got to GitHub again you would see all these changes.


Git is a distributed version control system. In order to become an efficient software engineer/developer you need to understand how it works. This way you can track your changes, always have a copy at a remote location. Which is useful if you need to share this repository with a peer engineer or in case you have lost your local machine copy.

As long as you have initiated the repository you are all set up with version control. Then it’s a case of personal preference. Instead of remembering the location of the repository folder on your machine for creation of the application using Visual Studio. You can simply create an application at one local location and copy over to the folder where you established the repository.

Create, clone, commit to Azure DevOps repository

Reading time: 8 minutes


In this post I will explain how to create a repository on Azure DevOps. Clone this very same repository to your local machine and finally commit changes from your local version of repository to remote repository on Azure DevOps.

What is required

  • Azure Subscription
  • Net Core Web App
  • Repository/Repo on Azure DevOps
  • GUI for Git

Azure offers a free subscription plan for personal use. It’s easy to subscribe and practice for your own development or upskilling for a job.

Let’s start by creating a project that will contain your repository

Once you have created a subscription we can then go to Azure DevOps home to create a project.

Enter the project name that would be used throughout this tutorial. Project is like a root folder that would contain all your applications that are related to this project.

For example you can have a project with name TestProject that contains Net Core web api as a backend and Angular application as a frontend. Then you have another project with name FileProcessing that contains some backend code. These two i.e. TestProject and FileProcessing are two different projects with their own domains. These serve for different purposes. Therefore as a good practice should be placed into separate projects.

Next thing we need to select Repos from the left pane. On the right section of the page it should show you the next view.

In there let’s choose an option to Initialize with a README or gitignore.

And for our benefit let’s add both. This is a good practice and both of these files should be added to every project. README serves as an initial documentation that caughts developers first attention. Gitignore is like a safeguard for committing file types that should be left out from pushing it to a remote copy repository.

After we click Initialize it should redirect us to this repo page. From there we can edit details and perform some useful actions.

One of them which is important for this tutorial is action called Clone. The name speaks for itself. In other words we are taking original remote code and cloning it to our local machine. This way we are creating an exact copy of code at that moment of time. Whatever you do, this code/branch on your local machine would not affect the remote code until the moment you use any of these three main commands: commit/push/merge. There are other useful commands but for them you can perform your personal research and see the effect of them on your code.

Clone repository

Once you are at the main page for your repo click the Clone button.

On the slide out click Copy button.

We need this URL (uniform source locator) in order to clone this repository to our local location on our machine.

For this tutorial I will use Sourcetree as a GUI for Git. In Sourcetree add a new tab or under the File menu option choose Clone / New…

On the new tab choose Clone or if you used the File menu option it shows you the required interface.

Paste in the repository URL into the first field. In the second field select the location where you want this repository code to live. By adding \DummyAzureRepo we are creating a root folder for this repository on the fly. Click

When we click Clone the master branch is cloned to our local machine. As you can see this branch contains only two files that we specified during initialization.

If you edit any of the files from the location where you cloned this repository Git should detect these changes.

Let’s create Net Core App to show how Git detects changes

Create Net Core App

Open up Visual Studio and select ASP .NET Core Web Application with Angular template.

On configuration screen type in the name of our repository and add the location where you cloned it but without the root folder name since it was already created in previous steps when we clone the repo.

This is how the root folder of this repo looks before.

After you click Create on the next screen you can specify a web application template if you need one. For this tutorial let’s choose Angular.

And this is how it should look like after you clicked Create.

Now if you go to Sourcetree you should see these changes.

Click on Stage All, write Commit description and click Commit.

At this point these changes are still only on your local machine. For it to be sent to a remote location you need to use the Push command.

Make sure you ticked the right branch. For your Remote branch you can choose any you like. For this time we will keep it as it is. If you are happy with what you see then click Push.

Once you have clicked Push Git sends these changes to the remote repository.


Being able to use Git is essential for being a successful software developer/engineer. Additionally it helps you to keep track of what has changed in terms of code. Another important point is that you got a copy of your code in the cloud. Centralized location that you or your team member can access from anywhere in the world where you got an internet connection.

Continuous Deployment of Net Core Web App to Azure App Service

Reading time: 15 minutes


In this post I will explain how to setup continuous deployment of Net Core Web App with Azure DevOps for the app that is hosted with Azure App Service.

What is required

  • Azure Subscription
  • Net Core Web App
  • Repository/Repo on Azure DevOps

Let’s start with initiating a repository on Azure DevOps

Prerequisite: you need a project on Azure DevOps. Go to your Azure DevOps main page.

Once you have clicked Create you should see similar screen.

We are interested in Repos section.

Look at the top section of the page where it says Initialize with README or gitignore. In my opinion it is a good practice to have both of these files with every repository you are creating.

With README you are deemed at some point to add some description of your app. This serves as an initial documentation. Whereas gitignore will prevent you from commiting unnecessary files to your repository. In a production environment this save your builds and time in case one or few files has slipped through.

At the end of the day you can always delete them or edit them according to your requirements.

Clone repository

Next thing is to Clone this newly created repository to your machine.

You can use any GUI for Git to do it or even Git Bash if you prefer command line type of application.

For this case I will use Sourcetree . It’s relatively easy to use. Gitextensions is similar in touch and feel. It also nicely connects with various comparison/diff and merge tools.

The main thing for us is to memorize the destination where we clone our reposity.

Create Net Core App

Let’s create Net Core web app with Visual Studio.

Since we already created a solution folder when we cloned the repository to our machine make sure in Location field we target the folder that contains the solution folder named NetCoreWebApp. Visual studio clever enough to place web app files into this folder.

Then we select ASP .Net Core 3.1 with Angular template.

The final folder structure should looke like so.

NetCoreWebApp inside has this structure.

Alternatively you can always create web application at one destination and then simply copy or move it over to the repository location.

In either way the result that we aiming for is for Git to track the changes to the repository.

As you can see Sourcetree on top of Git picked up the changes to your repository.

Steps that you need to do next are:

  • Good practice is to Build the solution but in this case it can be optional since it’s a pre-made template
  • Stage All
  • Write commit message
  • Commit
  • Push it to the remote server.

Once all of these steps are performed you would be able to see your changes on your repository at Azure DevOps.

Build pipeline

Select Pipelines from left menu and Use the classic editor.

Then select the repository you wish to setup the build pipeline.

Then you need to choose ASP.NET Core template.

The next screen should look like this.

The only thing that needs changing is on the Triggers tab.

This way we enable Continuous integration. Which means every time you commit changes to this branch it would trigger the build pipeline. As a result you would be able to see whether your changes integrate into the code of remote copy of the branch. In our case it’s master. Normally you would have build pipeline on develop branch before merging and building it on master branch.

Next step is to click on Save & queue. Then we need to add comment, check the branch and click Save and Run.

Next screen should look like this.

Next we need to create an App Service

For this we need to go to Azure Portal.

There we need to select Create Resource.

Then select Web and Web App.

Things to fill in on the next screen:

  • Resource Group -> Create new, choose whatever name you like since by it you will distonguish resource group that is related to particular project.
  • Name – which would be part of web app url
  • Way of publish – Code
  • Runtime stack that your app would use to run
  • Operating system – Windows
  • Region – whatever you like. Mind since we are using free subscription you need to make sure it is available in that region.
  • Windows Plan -> Create new
  • Free F1 tier which is part of free subscription from Azure for individual developers that want to research this platform

If you go to your newly created resource and there select App Service. From there you can check the app if it’s ok and running fine by clicking on it’s url.

Let’s go back to Azure DevOps and create Release pipeline.

…before getting into final part I think it’s a good time for a cup of beverage of your choice 😉

Create Release pipeline

Click on Releases from left pane menu. Then click on New pipeline in the area on the right.

Search for Azure app in the search box for templates. Click Apply.

From there you can edit stage details like name and owner. This could be develop stage with one of the testers being the owner. However in our case we will leave these as they are.

We are more interested in editing job/task section. So let’s click on section that is underneath Stage 1 in Stages on the left side.

In here we need to select our Subscription and App service name that we created at Azure portal.

Once we selected and Authorized our subscription we can then see our available App services.

Let’s go back to tab Pipeline and add an Artifact that was created by the build pipeline. Click on Add an artifact.

Select appropriate build pipeline Source. Check alias and edit it if needed. Click Add.

Last bit of setup. The Continuous deployment trigger.

Save and click Create release.

Select the Stage and build version that you want to release.

Once you are happy click Create.

Go to Releases on the left pane. In the right section click on Releases.

You would need to deploy the first release manually. On the next screen click Deploy and off it goes!

You can monitor the process in the next screen.

To check your newly released web app select Deploy Azure App Service.

For this purpose use App Service Application url.

Let’s check out the result! Our Hello, world app! Classic 🙂


Hope you enjoyed this post.

As you have noticed with Azure it is quite straight forward to deploy an app. From creating an App service in portal to creating build pipeline with Azure DevOps. When you have done it once or twice it makes sense. You can easily connect the dots to get the whole picture of modern deployment processes.

Stay tuned and have fun coding.

Continuous Deployment of Angular SPA to Azure App Service

Reading time: 15 minutes


In this post I will explain how to setup continuous deployment with Azure DevOps. This post will also contain instructions of how to host it using Azure App Service.

What is required

  • Azure Subscription
  • Angular App
  • Repository/Repo at AzureDevOps

What is continuous deployment?

Continuous deployment is the final stage of CI/CD development approach. It is responsible for deploying code to different environments. For example, develop, staging and production. Deployment happens automatically in comparison to Continuous Delivery. With continuous delivery the only difference is that the release to production happens manually. It involves someone from the engineering team or someone from product team or even management to click a button.

In a nutshell CI/CD is a practice that is followed by an engineer or a group of engineers that work on a common code of any application that is under constant development and which requires to be build, tested and released as soon as the code is being pushed to a git a branch that is responsible for kicking this process off. Normally it is a develop branch.

Main benefit of CI/CD approach is that the code is in deployable state at all times. Of course, this is in theory but in practice this could be more or less true because in order for this approach to be effective team have to be disciplined and implement whatever is required for it. There are a lot of resources online for different situations. This would all depend on the current team approach, requirements and objectives.

Let’s roll up our sleeves and get stuff done

Setup local environment and workspace for Angular app

Install Visual Studio Code on your machine. Please use the below link.

Then you need to install appropriate Node.js version that is compatible with your version of Angular.

Create Angular app

It is a straight forward task once your local environment and workspace is set up.

  • Open VS code
  • Go to Terminal > New Terminal
  • Install the latest Angular version globally with this command > npm install -g @angular/cli
  • type in > ng new my-app
  • use this command to go to code > cd my-app
  • make sure it works fine by opening the app using this command > ng serve -o

Create repository on Azure DevOps

Prerequisite: you need a project on Azure DevOps. Go to your Azure DevOps main page. The url should look similar to the below one.

Next thing is to initialize a repository. Select Repos from left panel. If you don’t have any repos in there then you should see similar page.

You need to initialize a repo for it be able to clone to your machine. Once it is cloned you need to copy files your previously created angular app into location where you have cloned the repo to. This way source control app on top of Git will detect changes. By the way you need Git installed on your machine.

*In case you got other repos on the project you can simply add another one like so.

Make sure you give a descriptive repository name. If you want to avoid complications then it should be without spaces. Also select at least README. Alternatively, you can add .gitignore. You can always delete them or replace them. This way your repository won’t be empty and you can check it out with no issues.

Create Azure App Service

Select App Services at Azure portal home screen.

On next screen select Add.

Then select suitable subscription that is available on your account. For this task Free Trial subscription would be sufficient.

Next create New Resource Group.

Resource group serves as a container for related projects of your application that you host on Azure. More information at Microsoft documentation following this link

Next fill in Instance details section.

Name is App name plus it constructs part of the URL.

In our case the app code will be published, so let’s leave Code as selected option.

Runtime stack relates to this particular instance of app running on an Azure server. Whatever you choose it should be applicable to your application. In other words, your app should be able to run on this stack. Different runtime stack would behave differently, would have different DLLs running and so on.

For our case we need to run Angular app on .NET V4.7 because angular app needs a server to run the app. This will provide us with an option to run the app on IIS which comes with the framework. Alternatively, you can choose .NET Core. This might need some tweaking but in theory it has IIS server too, so should run with no issues. More information and here

As for operating system select Windows.

Depending on the Region you can have different App service plans. For example, since we are using Free Subscription not all regions will have a Free F1 plan and sometimes you need to pick the right one for your needs.

Finally, it should look similar to below image.

Confirm your app settings by clicking Review + create. All done!

Let’s go back to AzureDevops to implement continuous deployment

Create build pipeline

Select Pipelines from the left menu and then click on ‘Use the classic editor’ in the section on the right.

Next select our previously created repository and click Continue.

For our purpose we need an Empty Job where we can customize all the steps and processes for this build pipeline. Other options are premade templates that can speed up pipeline setup.

Next screen should give you different options to structure this pipeline. What we need is to add a task to an Agent Job.

First task would be the Node.js tool installer. You would need to choose an appropriate version to run with your angular app. For example, I will pick version 12.x for Angular 9 app.

Then we need to follow the same pattern and add a npm task.

We need to replace default field content with custom values. In our case we are making sure the pipeline has latest angular installed.

Then we need add another npm task where we explicitly say to install all the packages and dependencies for our Angular app. Here we leave a default field content.

Now we need to add a production build task. Again, we will use npm task.

When app is build using ‘build –prod’ command it creates ‘dist’ folder with app name folder inside. In this folder you got app build files that would be used on the server to run your app.

As you can see on the image below inside we got a folder with app name containing transpiled and minified JS files plus other files required for app to run.

Next step is to archive files into particular location on the server. Let’s search pre-set tasks for an archive task.

Change root folder to System.DefaultWorkingDirectory. It is the place where your source code files are downloaded. More details

And also untick ‘Prepend root folder name to archive paths’.

Last task to add will be to publish build artifacts.

There is nothing that we need to change.

So, the final set of tasks for build pipeline should look like this.

To make it so that every time there is a change to the branch it would trigger a new build we need to select ‘Enable continuous integration’ flag in Triggers section. By doing so we are achieving continuous integration of code.

This looks like it. Now we need to click Save & queue, add save comment and click Save and run.

This will start the build pipeline. During the build all the tasks that we established would be done sequentially.

Create release pipeline

Select Releases under Pipelines in the left side navigation menu.

If you do not have any pipelines you can add a new pipeline by clicking on New Pipeline.

In case you have existing pipelines, you can add new release pipeline by using dropdown as you can see on the image below.

Next thing to add is Azure App Service deployment task.

After that you need to click Tasks tab and select your subscription with app service for this web application.

Once this is done we need to go back to Pipeline tab and select our artifact that we published in the build pipeline.

We keep everything as it is after we choose Source build.

To enable continuous deployment, we need to activate the continuous deployment trigger. Once you have added a build artifact you can click on continuous deployment trigger icon. In the side pop out window you need to set toggle to Enabled.

Additionally, if you got a requirement to set this trigger on particular branch e.g. master, develop etc you can easily do so in the same window. This way the release pipeline will listen to a build on particular branch e.g. develop, yourtestbranch etc

Click Save, then Create release.

Go to Releases on the left pane. In the right section click on your Release created in the previous step.

You would need to deploy the first release manually. Click Deploy

That is it.

Oh, wait one more thing. Go back to Azure portal and find our previously created App Service. Select Configuration from Settings in the left side menu option. Move to the right side and select Path mappings tab. On that tab edit Physical Path under Virtual applications and directories, so that it reads site\wwwroot\dist\ng-app\

This will make sure you are able to access your web application.


This tutorial shows you how to setup CI/CD using Azure portal and Azure DevOps. These two work hand in hand. Since it is all under one Microsoft account it becomes really easy to connect everything together and see results straight away.

CI/CD pipelines serve as handy and straight forward mechanims that can greatly improve the performance of the team. It can also increase the output by automating a lot of processes related to building, testing and deploying of your application.

What up!? ;-)

You have reached a tech blog with posts that some might think contain too much detail. In my opinion more detail is better than trying to put together a puzzle following instructions that have some missing words.

I am a full stack software engineer with 7+ years of professional experience.

My journey started during my school years. As part of IT lessons one of the tasks were to develop basic websites. I really enjoyed doing it and as a result become more and more quicker in production of a working website from scratch. It was a gradual process during which I would be able to fully immerse into the moment. Some people would call it being in the flow. Actually, I remember that from early ages I was into puzzles, maths and everything related to science. I think suitable word would be inquisitive.

After finishing school and entering university for a degree of Computer Science and Electronics I have started to become more aware of other aspects of IT and software engineering e.g. development methodologies, user experience, computer languages, software development ethnics, data protection etc

My time at university was a period where I have received the fundamental knowledge of system development and software engineering in general. Study program at that time was mainly around Microsoft technologies. My course also included UX, design of the system architecture, feasibility study, project management, coding practicals and plenty of other stuff. Really smart stuff. Which I thought I would be struggle to grasp. But hard work, other people support and believe in myself helped me with this.

Further into my studies I have researched other technologies. This gave me a better understanding of what was happening in computer technology world at that time.

It was a great time during which I was exposed to different technologies and techniques of software engineering. Also, this was the time when I realized how great it is to work with other people. The best part was the process. The time where you exchange ideas, share challenges and support each other.

Being curious about all the technology stuff in my final year project I have chosen to develop an Android app. Going through all of the stages of development process by myself has developed an interest in working as a full stack software engineer.

After graduation I have worked in a few places with different approaches. To be honest I started to value team work even more. In the real-world day to day development process feels similar to uni days. However, it has its own interesting points. The best part is that you always learn something new. Whether it is technology related or human relationships. It is definitely worth the time.

Drink coffee responsibly. Stay hydrated. Keep smiling and talking to that rubber duck. Quack-quack-quack