Introduction
When talking about continuous implementation, we refer to the following definition:
"Continuous deployment is the ability to bring new changes of any kind (features, configurations, fixes, and experiments) to production or into the hands of the user, safely and quickly." - Jez Humble.
This definition means that we have several advantages when making use of continuous implementation, among these:
- Automation of the software publishing process.
- Improve development productivity.
- Find and fix bugs faster.
- Deliver updates to users faster.
To apply these concepts, we'll do the process in two ways: the first through a direct deployment of a web application with DotVVM and .NET Core from Visual Studio 2019; and as a second way, associate the same project with a repository on GitHub and with that repository perform continuous deployment to Azure App Service.
Finally, we'll look at some important aspects, including the database associated with the project, continuous deployment with .NET Core 3.X, DotVVM projects with Business Pack, and build errors that can occur with web applications developed with DotVVM.
The DotVVM Solution Environment
Generally, a solution for building web applications with .NET Core and DotVVM contains the following projects:
-
DAL (Data Access Layer): to manage the connection and access to the database.
-
BL (Business Layer): for the management of services and logic of the application domain.
-
APP - App presentation layer. This section is where we have the Views and Viewmodels for designing web pages with DotVVM.
The solution in Visual Studio 2019 looks like this:
Direct deployment of the DotVVM application to Azure from Visual Studio 2019
To perform direct deployment from Visual Studio to Azure, we need to go to the project .APP and in the options section select Publish (or from the main options menu: Build > Publish),
Later, we'll have the option to configure the publishing target. For our case, the destination of interest will be to select App Service to create a new profile:
In this section, we must select Publish. Then, the Create Application Service dialog box will appear to us. Here, we need to sign in with an Azure account, if necessary; and then provide the information needed to create the App Service resource in Azure.
In this process of creating an App Service resource, Visual Studio provides us with the functionality to create other Azure services for handling our app information. For example, in this case, it allows us to create an Azure SQL Database for further handling of information in the cloud.
Finally, after you create the resource with these steps, Visual Studio will deploy the app to Azure App Service and the web app will be loaded into the browser. The Publish project properties pane displays the site URL and other details.
After this process, the direct deployment result between Visual Studio 2019 and Azure is as follows:
Continuous deployment of the DotVVM web application from GitHub to Azure
For the continuous implementation of our project, we have two small steps to perform:
- Associate our project with a repository on GitHub.
- Associate the GitHub repository with Azure App Service for continuous deployment.
Part 1 - Associate the project with GitHub
The first thing to do is to verify that we have the GitHub extension for Visual Studio 2019 installed. In any case, the extension can be downloaded at the following address:
https://visualstudio.github.com/.
To add the extension, Visual Studio must be closed before you can install GitHub because they are changes to the Microsoft IDE that are made during installation.
All right, we now proceed to associate with the solution that contains the three projects (.APP, .BL and .DAL) to a repository on GitHub, to do this we right-click on the solution in Visual Studio and select to add a solution to the source control:
Then, we go to the Team Explorer view and then to the Synchronization section:
Next, we select Publish to GitHub and continue with the instructions presented for creating a new repository.
A short time later, our project will be associated with the repository we just created. We can check this directly from GitHub:
Note
Whenever we need to save the changes made, we can save them from the Changes section in Team Explorer.
And in the Synchronize section, you need to confirm the output changes:
With these first steps, our DotVVM application in Visual Studio 2019 is already associated with a specific GitHub repository.
Part 2 - Associate Azure App Service with the GitHub repository
At this point, we need to have an App Service in Azure, for this, we can create it from the Azure portal in case we don't have an app set up or if you follow Part 1 of this article, you can use the App Service resource created Previously.
That said, our first task will be to target the App Service resource in the Azure portal. On the application page, we need to select the Deployment Center option from the menu on the left.
On the Deployment Center page, select GitHub, and then sign in and select Authorize.
For GitHub, on the page to build the provider, select App Service build service, and then select Continue.
Then on the settings page:
Deploy the menu and select the organization, repository, and branch that you want to deploy continuously.
After configuring the build provider, we need to review the settings on the summary page and select Finish.
From now on, new repository and selected branch commits are continuously deployed to the App Service-hosted application. On the Deployment Center page, you can also track commits and deployments.
Particular cases
Up to this point, we've learned generally how to host DotVVM applications directly from Visual Studio 2019 or continuously through a repository on GitHub. Next, we'll look at some very particular cases about errors that can happen along the way, particular configurations, and also about .NET Core versions for DotVVM applications.
Disable continuous deployment between GitHub and Azure
To disable continuous deployment, we must select Disconnect at the top of the Deployment Center page of the app's App Service resource.
To continue continuous deployment in the future, we need to repeat the process of associating with the GitHub repository from the Deployment Center page of your application.
Other repository sources
Additional to GitHub, with Azure Web App we can also perform continuous deployment from the following sources:
- Bitbucket
- Local Git
- OneDrive
- Dropbox
- External
- FTP
What happens to the web app during publishing to Azure?
All Azure Web App deployment methods make changes to files in the application's /home/site/wwwroot folder in Azure. These files are the same files that run in production. In this sense, there are particular cases in which deployment errors of the DotVVM application in Azure can occur. Here are some common bugs and how to learn more about these errors.
Detect web application failures in production in Azure
On many occasions when we work with the development of online web applications, we can find errors like this:
This particular error, 500 - Internal Server Error, is a very general HTTP status code that means that something has gone wrong on the website server (in this case, Azure), but the server cannot be more specific about what the exact problem is.
In this case, the first thing we can review is the Error Log within Azure App Service. To get the details of this log, we need to go to the web.config file and make a modification.
Note: To access the files and directories in the Azure App Service resource, we can use the Advanced Tools option in the resource menu from the Azure portal to access the web.config file located in the path D:\home\site\wwwroot>. In the following two images we can see this sequence.
On the resource from the Azure portal:
From Kudu:
Once this file is located, we must modify in the following statement the parameter stdoutLogEnabled with the value true, which, will allow us to generate a log file, where errors generated in the execution of the web page can be revealed in Production. The file will be located at the address specified in the attribute: stdoutLogFile.
<aspNetCoreprocessPath="dotnet"arguments=".\EXE.dll"stdoutLogEnabled="true"stdoutLogFile="\\?\%home%\LogFiles\stdout"/>
When we make the changes, we'll have something like this:
When saving the web.config file, reloading the web page and encountering HTTP 500 - Internal Server Error, we go to the address specified for generating logs files, and open the last generated file:
In this case, we find an error that says:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 52 - Unable to locate a Local Database Runtime installation. Verify that SQL Server Express is properly installed and that the Local Database Runtime feature is enabled.)
This error is due to a problem with the database connection. In this case, intentionally, the connection to the database in the DAL is referencing an on-premises database, so the Azure App Service server will not be able to find the database server, thus generating this failure in production.
Web applications that are in production can often fail under this context. In this case, analyzing the logs files can save us hours of work when trying to find the possible error that is occurring in the web application.
Detect failures in continuous deployment to Azure from GitHub
Azure performs continuous deployment automatically when there are changes to the associated GitHub repository, the final status that we can result in are two: Success, which means that everything went well; or, Failed, that something went wrong. When deployment errors exist, this usually happens for a variety of reasons.
Like in the previous case, the best thing we can do is review the deployment logs to analyze the possible errors that are occurring. To do this, in the deployment attempt, we can click on the icon shown in the following image to access these logs:
For this particular case, in the log file, we can find the following:
Here, we could directly highlight the following implementation error: The current .NET SDK does not support targeting .NET Core 3.0. Either target .NET Core 2.2 or lower, or use a version of the .NET SDK that supports .NET Core 3.0.
In this particular error, there are not many additional explanations that can be said. The .NET Core SDK is not yet available in the Azure App Service resource region. This specific case will be reviewed in the next section.
As we see, there are a variety of errors that can occur during the deployment of our applications to Azure. Thanks to these tips we can keep in mind that this is the first thing we need to do to detect these errors, which, in general, is advisable to review the application logs.
DotVVM applications with .NET Core 3.X
As we saw in this article, the status of .NET Core 3.X in Azure is partially current. What does this mean? This means that the runtime and frameworks are there, but the .NET 3.X SDK is missing. Simply put, we can run 3.X, but not compile 3.X.
However, according to the
ASPnetCoreON web page, which allows us to check the availability of ASP.NET Core for deploying applications to Azure App Service, .NET Core availability based on Azure region, and version. NET tells us the following,
There are Azure regions with .NET integration with a status of Partially Current, in which we can run .NET Core 3.X, but not build .NET Core 3.X.
Also, the West US 2 region and North Central US region are in the state Current, that is, we can create .NET Core 3.1 applications in Azure and run .NET Core 3.1 applications in this region. (February 2020).
If we analyze this information in detail, in the two regions mentioned above, we find the following:
This means that we can continuously deploy our DotVVM applications from GitHub with .NET Core 3.1, 2.2, 2.1, and 1.1.
One very important thing to mention is that DotVVM since its version 2.4 already allows us to work with .NET Core 3.1
Released DotVVM 2.4.
To change the version in our solution, you will need to change the target platform versions in the projects.APP, .BL and .DAL from Visual Studio 2019,
An additional alternative (February 2020) is to consider working with .NET Core 2.2, a version that so far has no problem in any of the regions for continuous application deployment in Azure.
An additional mistake
One error whose solution was not easy to find is shown in the following:
This error was generated at the time of direct deployment between Visual Studio and Azure, and the error is also generated when performing continuous deployment from GitHub.
.NET Core and DotVVM specifically use static files to use CCS styles, Javascript components, images, among other files, through the wwwroot folder (other than the one used by Azure App Service - There is no name relationship Azure wwwroot and DotVVM's wwwroot).
Within DotVVM, StartUp.cs specifies the path that will contain the aforementioned static files through the Configure( ... ) in the app statement. UseStaticFiles(...). In case the wwwroot folder is empty (without any files), Azure Web Service generates conflicts with this and presents the error of the previous image.
To fix this error, the folder wwwroot in the DotVVM .APP project must not be empty. While it is true this answer from a technical point does not have much explanation, but it is a possible solution to this problem that could save a lot of time (a considerable amount of time) in the search to solve this problem.
DotVVM and Business Pack
Does your DotVVM project use Business Pack to manage PRO controls? In this case, the deployment to Azure will not be affected, as all DotVVM Business Pack NuGet packages will also be deployed to Azure with the other packages that the project references.
Plus: Database connection in the project. DAL with Azure SQL Database
To work with our cloud web application, it is necessary that the database associated with the project is also in the cloud, for this, in the DBContext of the project .DAL, you need to implement the OnConfiguring method of the DbContext class, as shown below,
protectedoverridevoidOnConfiguring(DbContextOptionsBuilderoptionsBuilder){optionsBuilder.UseSqlServer("Connection string");}
This will allow us to establish the connection to the cloud database, taking into account the relationship that must exist between the Database Entities and the classes in the project .DAL.
Thank you!
With this article, we've learned everything we need to know (at least most) for deploying DotVVM applications with .NET Core on Azure.
Do you want to practice what you have learned in this article? To do this you can see the following tutorial about
CRUD Operations on DotVVM, access the source code, and practice this knowledge.
If you have any concerns, do not hesitate to write to me.
Join the conversation! Your thoughts help the community grow.