When you create a publish profile in Visual Studio, the password for accessing the target Azure service is also stored. However, if this password changes in Azure or if you retrieve the publish profile from source control so that there is no valid password stored in your copy of Visual Studio, you must enter the password during publishing. Where can you find the valid password and how can you store it again in Visual Studio?
Posts about Azure
GitHub Actions can be a good choice for deploying an ASP.NET Core application to an Azure Web App Service if you have the code in a GitHub repository. You can even generate the GitHub Actions workflow directly from the Azure Portal. However, if your solution is not very simple, the generated workflow may not work correctly.
Automatic updates are configured by default for each Azure SQL database, allowing you to perform a point-in-time restore of the database to any point within the configured retention period. Although the restore process is documented, I still had some doubts when replacing the existing database with the one from the backup, so I am documenting the steps I took for future reference.
To make blobs in Azure storage publicly accessible, in addition to the account level setting each container also must have its access level set accordingly. My approach to copying content between accounts didn't preserve this property. This meant I had to find a way to set it efficiently for all containers in the account.
There's no functionality in Azure Portal to migrate contents of an Azure Storage account to another one. But there is a command-line tool that can do it - AzCopy. Recursively copying all blobs between two storage accounts is one among the many operations it supports.
It was Global Azure Bootcamp time again last Saturday and for the third time in a row I was attending the Slovenian one as a speaker. This time, my session was not about a specific technology or tool. Instead, I dived into application architecture. The microservices hype has been my pet peeve for a while and I wanted to share my opinion about it with the attendees.
It's April again and last Saturday it was time for the annual Global Azure Bootcamp event. The Slovenian one was taking place at the local Microsoft offices. In my session, I explained how to configure Visual Studio Code to improve the experience of .NET Core development as much as possible.
When I wanted to replace my local TeamCity based deployment setup for my blog with a hosted one, I chose CircleCI based on its good support for private repositories in BitBucket and an abundant free offering. The migration process went surprisingly smooth, even though I had to change the technique I used for deploying to Azure since there's no Web Deploy on Linux.
On Saturday the fifth annual Global Azure Bootcamp event was taking place all around the globe. In Slovenia the event was organized in Ljubljana at the premises of the local Microsoft subsidiary. I showcased the Visual Studio integrations for Azure Storage, Application Insights and publishing of ASP.NET Core web applications to App Service on Windows and Linux.
Newly created classic virtual machines in Azure have dynamic public IP addresses. Although, Resource Manager is now the recommended deployment model, there are still image templates in the marketplace that requires classic deployment model. If you don't want the IP addresses of these virtual machines to change when they are stopped, you will need to reserve the IP. At the moment this can only be done using Azure PowerShell.
Having leftover Azure credit from my MSDN subscription made Azure a logical choice for hosting Docker in a Linux virtual machine. This post documents the steps I took to create a convenient working environment on my Windows workstation.
When I moved my blog to Azure, I broke the AWStats statistics, which I had configured, when I was still hosting the blog myself. Almost a month after the move it was about time to get it working again.
Although Git-based continuous deployment of my site to Azure seemed like a good idea, it turned out too unreliable. I didn't manage to get to the bottom of the issue. Instead I started exploring the alternatives. I decided to use Web Deploy, because it is reasonably easy to set up and it also supports deleting of removed files from the deployment location.
I recently deployed my new web site to an Azure web app for the first time. The site seemed to load correctly, but a closer inspection with Fiddler revealed a couple of 404 errors. Font Awesome web font files appeared to be missing, although they were present on the web server, but by default files with .woff2 and .woff extensions are not served.
In the scope of changing my blogging platform I also decided to switch from self-hosting the blog to hosting it in a Microsoft Azure web app. One of the available features, I want to take advantage of, is continuous deployment from a Git repository at one of the supported repository sites. Of course, the repository only contains the sources for the site, therefore it will need to be built every time the latest version is retrieved from the repository.