In my opinion, Azure App Services are an easy and direct way to launch your ASP.NET Core application for the outside world to access. Azure App Service offers a free tier, perfect for tinkering or getting a new project off the ground.
While you can always use an existing .NET Core project, generating a new project is always an option and one we are going to take today. Without going too far into this process, we need to have a .NET Core project and add that project to a local Git repository.
First comes the code:
Then comes the commit:
Adding a new App Service resource to your Azure account is fairly straightforward with Azure’s portal, adding a “Web App” under “Web + Mobile” in the new resource pane.
When going through the initial setup, you’ll be prompted for a few pieces of information:
- App name
- Resource Group
- App Service plan/Location
Once finalized, you’ll be able to click the “Create” button. You’ll notice a notification near the upper right-hand of the portal stating your deployment has started. Wait for your notification that the deployment was succesful, and find your App Service resource, either under “All Resources” or on your dashboard if you elected to pin it there. Most of what we’ll do from here will stem from the resource pane that appears once you click your App Service resource.
If you haven’t set up a deployment user/password on your Azure account before, Goto App Deployment > Deployment Credentials
which will require you enter the following:
- FTP/deployment username
- Confirm password
The username/password combination you’re configuring will allow you to use their FTP service and Git through HTTPS.
By default, Azure App Service resources use FTP for deployment, meaning we need to manually connect via FTP and upload a built version of our application. Git deployment simplifies this by allowing us to push our raw source code to Azure and have the build + deployment processes occur automatically. To get Git deployment enabled on our App Service, we’ll need to go to App Deployment > Deployment Options, select “Local Git Repository” for the source and confirm by clicking “Ok”.
- Choose Source -> Local Git Repository
Under Settings > Properties, copy the Git URL for your resource. We’ll use this as the remote for our local Git repository, pushing our current master branch to Azure:
Awesome. Kudu (Azure’s Git deployment engine) is detecting the project is .NET Core, but it’s using MSBuild to build the project. MSBuild apparently isn’t compatible with
project.json. Now what?
Two weeks later
After taking a break, I decided to use my brain and found this StackOverflow answer which was the key to correcting the
MSB4025 issue. The fix is to add a
global.json file to your project with a specification with the specific version of the SDK being used locally.
If generating a project with
dotnet new or
yo aspnet, you’ll need to move your project around as well to accomodate the
global.json file’s way of specifying projects:
Big take away is that your existing files need to move into a directory under
src (or whatever you choose to name it). From there, we need to add some content to
Update 03 February 2017: Moving your project files to
src does not seem to be a hard requirement. Dan Clarke pointed this out to me via Twitter, stating the following
global.json file should work as well:
This would have the benefit of not requiring a change in project structure, but if you like to keep your source and test projects separate (I do), you can keep your main project in
src and a test project in
test, ensuring that
test was added to the
projects array in the
global.json file. Either way should get the job done at the end of the day, so be sure to pick what makes most sense to you and your project.
If, like me, you have no idea which SDK your locally installed
dotnet is using, running
dotnet --version will give the exact string needed under
sdk.version in your config. Once set up, you can commit all of those changes and push them up to your app, eventually seeing the below:
Once in Azure, your application becomes accessible to all with the URL:
And don’t forget about some of the benefits of using Azure (subscription and configuration allowing):
- Managed SQL Server
- CI/CD through VSTS
- Automatic scaling
- Application Insights
So iterate on your project, incorporating Azure features when you see fit. Your release process can now be a simple
git push away thanks to Azure App Service!