In the Add Application Insights to an Existing ASP.NET Core Application post from last week, we got Application Insights up and running. This week my plan was to show off some of the features of Application Insights. It turns out this is hard to do in a meaningful way when your application isn’t getting any usage. While I have next to no data for most of the screenshots I still want to point out some of the areas of Application Insights that seem like they would be very useful.
For the most part, the post linked above is a good starting point with the exception of instead of using a React application I switched out for a Razor Pages application. The following is the command to create a Razor Page application with auth using the .NET CLI.
dotnet new webapp --auth Individual
The reason for this change was to get more items in App Insights since Razor Pages makes a request to the server per page.
The first item I recommend you check out is the Application Dashboard. On the Azure Portal select your App Insights resource and at the top click Application Dashboard.
This link will drop you on a page that will let you see how your application is doing at a glance. This includes everything from Unique sessions and Failed requests to Average I/O rate and Average available memory.
Live Metrics Stream
From your application dashboard or the App Insights menu you if you select Live Metrics Stream you will see real-time information about Incoming Requests, Outgoing Request, Overall Health, and a list of servers your application is running on and some stats about your usage on those servers.
As a developer, a lot of the items in the Investigate menu jump out to me as being really helpful.
For example, Failures will give you a graph of failures over your selected timeframe with a list of the failed operations and a summary of the top 3 failed response codes, exception types, and dependency failures. The following screenshot is what it looks like, but my sample application doesn’t have any failures so it may not be super helpful.
The other option I want to point out is Performance which will give you a great summary of how your application is performing with break down by operation. This operation level view is a great place to spot areas in your application that may need some perf work.
This post covered a small fraction of the value provided by Application Insights. I encourage you to give the service a try especially if you are running a .NET application and most of the value can be provided without having to make any code changes.
I have found some time to play around with some of the features coming with ASP.NET Core 3 and I needed a place to host some of the applications I’m playing around with. Azure App Services has always been a great place for this type of thing, but as you will see in the details below it doesn’t support ASP.NET Core 3 by default currently.
This post is going to walk through creating a new ASP.NET Core 3 React application and publishing it to a new App Service with the default setting and then show you what to change to get the application to run.
I used the following .NET CLI command to create a new ASP.NET Core application using React for its front end.
dotnet new react
After the creation process is complete open the project in Visual Studio. I highly recommend using the Visual Studio 2019 preview release when working with any .NET Core 3 applications.
Publish to App Service
In Visual Studio’s Solution Explorer right click on the project file and select Publish.
Select App Service for the publish target. Here we are creating a new app service. Next, click Publish.
The next dialog if the information about the new App Service that will be created. I took the defaults for the most part. I did create a new resource group for this application to make the resources easier to clean up in the future. I also changed the hosting plan to the free tier. Click Create to continue.
The Error and the Warning
As part of the publishing process, a browser will be opened to the address of the application. When this happens you will see an error about ANCM In-Process Handler Load Failure (if you are using IIS In-Process Hosting).
If you look back at Visual Studio you will see the following warning that your application requires the .NET Core runtime 3.0 and App Service only supports up to 2.2.
After dismissing the dialog above you will see a summary of the publish profile we created above. Click the Pincel next to the Framework-Dependent value for Deployment Mode.
In the dialog that pops up set the Deployment Mode to Self-Contained and select an appropriate Target Runtime for your App Service. In the case of this sample which is deployed to a Windows App Service, we are using win-x86.
Back on the publish profile summary screen click the Publish button to redeploy the application to App Service with the new settings. When the process finishes this time you should see a browser load with your application running properly.
This is a great example of the power of being able to do self-contained deployments. If this option didn’t exist then we would have no option for running .NET Core 3 applications on App Service.
In this post, we will be adding access to user profiles using Azure B2C. We will be building on the setup used in the ASP.NET Core with Azure B2C Auth post so make sure and check it out if something in this post isn’t clear. The following is the full list of post from what has turned in to a series on Azure B2C.
The first step to enabling profile access is to add the Profile editing user flow. From the menu for your Azure B2C resource select User flows.
At the top of the list of user flows click the New user flow button. This will display a list of recommended flows to add. From the list click Profile editing.
On the Create page enter a Name for your flow, select which Identity providers can use the flow, select which User attributes to collect/display, and then create the Create button. The user attributes you select will control which fields show when the user is editing their profile. Also, notice the Show more link which will give you a full list of the user attributes available on your account.
Back in the sample application in the appsettings.json file enter the name of the profile editing user flow from above for the EditProfilePolicyId.
Run the application and after login, the user’s name will be a link which will take them to a page where they can edit their profile information.
The following is a sample of what the profile page looks like.
Tweaking the Layout
From the screenshot, you will notice that the order of the fields wouldn’t make a lot of sense to a user. Thankfully B2C provides a way to customize the order of files, labels, control types, etc. without doing a full custom page which is also an option if you need to match an existing application’s look and feel.
From the B2C menu, select User flows and click on your profile flow. Once in your profile flow select Page layouts and then in the details select Profile edit page.
You will see something similar to the following screenshot. As you can see it allows reordering of fields, label changes, etc.
If the built-in user attributes don’t cover all your needs B2C does allow you to add your own attributes. From the main menu of B2C click on User attributes and you will see a list of your current attributes as well as an Add button if you need a custom attribute.
Enabling profile access was a pretty easy process and the flexibility provided with the built-in customizations is nice. I’m betting that most people will end up using a custom layout to give users a consistent experience. If you need help getting started with a custom layout check out my Azure B2C: Customize Layouts post.
This post is going to cover enabling a social login for a site using Azure B2C for authentication. If you are new to this set of posts you can find the initial setup of the sample application in the ASP.NET Core with Azure B2C Auth post. I would also recommend checking out the Azure B2C: Customize Layouts to learn how to change the provided UI to provide your users with a consistent look and feel that matches the rest of your application.
Social Login Provider Setup
Azure B2C supports most of the login provides you would expect such as Google, Facebook, Twitter, Microsoft, etc. as well as any provider that supports OpendID Connect. No matter which option you pick you will have to register/signup your application with the provider. Unfortunately, Azure B2C doesn’t provide links to the registration pages of the services it supports so it is up to you to find those yourself.
For this example, I’m going to be walking through the process using Google. You can get all the details of Google’s OpenID Connect offering in their docs. To get started we need to set up our application in the developer console. The link will take you to the dashboard where you will see a message about selecting or creating a new project. Click the Create link. In the next page enter the Project name and click Create.
After the creation process finishes click Credentials from the navigation menu on the left.
On the top of the screen select OAuth consent screen. On this page, you will need to at least enter an Application name and an Authorized domain of b2clogin.com (not shown in the screenshot, but still required) and click the Save button at the bottom of the page.
Next, select the Credentials tab and click the Create credentials button and select the OAuth client ID option.
After clicking create you will see a dialog with your client ID and client secret make note of these as they will be needed when we add the login provider in Azure B2C.
Azure B2C Changes
Now that we have the Google side setup head over to Azure and find your Azure B2C resource. Select Identity provides from the navigation menu and click the Add button.
Enter a Name, I’m just using the name of the provider. Then, click on Identity provider type which will trigger the Select social identity provider selection to show. Click Google and then click OK.
Next, click Setup this identity provider which will show a fly out where you will need to enter your Client ID and Client secret provided by Google. After entering your values click OK.
Next, click the Create button at the bottom of the Add identity provider screen. When this process is done we will have two identity providers for this B2C resource email and Google. Next, we need to enable our new Google provider for our sign up/sign in user flow. From the menu select User flows and then click the flow you have set up for Sign up and sign in.
Next, select Identity providers, this will show a list of providers available for the selected flow. Check any additional providers the flow should use, Google, in our case. Finally, click Save.
Try it out
With all the above change attempt a login with your application and you will see Google as a sign in option.
Hopefully the above will give you a jump start on adding support for social logins to your applications. Adding other providers will really close to what we did for Google from the Azure B2C prospective, of course the sign up process will vary by provider.
In the post ASP.NET Core with Azure B2C Auth we did a walkthrough of setting up the basics of Azure B2C and creating a new application that used our new B2C setup for auth. This post is going to be using that same setup to show how to replace the Microsoft provided pages for sign up/sign in with your own custom pages.
Custom Page Hosting
Our custom page needs to be hosted somewhere public with CORS enabled. If the test application was hosted somewhere public we could just us it, but since it is running on localhost that isn’t currently an option. We are going to use Azure Blob storage for hosting in this example.
Next, on the Create storage account page, I used a new resource group and tried storage accounts names until I found an unused one. For the rest of the fields, I took the defaults and then clicked Review + create.
On the review + create page it takes a few seconds for the account to be validated. After validation click the Create button.
After the storage deployment is complete click the Go to resource button.
Setup Blob storage
The above will land you on the Overview page for the new storage account. Select CORS from the menu.
Since this is just a test I’m allowing everything under the Blob service, for a real deploy I would recommend only allowing the values you expect requests from. After setting your values click the Save button.
Back on the storage menu on the right side of the screen select Blobs.
Click the + Container button to create a new blob storage container.
In the new container, page enter a name and select your public access level. I’m going with the most permissive access level, for a production system you will need to evaluate the appropriate access level for your use case. Click OK when done.
When done you will be returned to your list of containers. Click on the container that was just created to view the details.
Create a custom page
Now that we have our blob storage we need to create the HTML page that we want to to use instead of the default. The following is the code for the page I’m going to use. It is going to be super ugly as I’m not going to use any styling.
You can make this page look however you want, but it will always need the div with the ID of API as this is where Azure will inject the elements that actually handle the signup/sign in. Save your page.
Upload custom page to blob storage
Back in Azure click the Upload button and then select your file and click the Upload button.
After upload, you will be returned to the list of items in your current container. Click the item you just created. In the details copy the URL as we are going to need it to give B2C the location of our custom page.
B2C use custom page
In your portal head back to your Azure AD B2C page and select User flows.
Select the flow you want to use the custom page for. In our case, we are going to be using the flow for Sign up and sign in.
In the Customize section select Page layouts.
In the bottom of the page select Yes for Use custom page content and past the link to your blob from above into the Custome page URI field and click Save.
Try it out
With all of the above setup you can now go back to the application using B2C and hit your sign in link and you will see your custom page. Here is what the one in the sample looks like.
Obviously, this example is really ugly and isn’t something you would do to your users, but it gives you the basic idea of how to use a custom page.
Hopefully the above will help you get started with customizing you B2C related pages to give your users a more consistent look and feel. The above only uploaded an HTML page to blob storage, but you could also upload a CSS file or any other assets you need. Also, don’t forget if your site is publicly accessible the assets can be stored with the rest of your application in that is appropriate, just remember to configure CORS to allow requests from Azure.
If you want more information on this topic check out the official docs from Microsoft on the subject.
I ran into a previous co-work a while back and they were talking about using Azure’s B2C for authentication on their apps. It sounded like a good solution. This blog post is going to cover getting the Azure B2C setup and will cover creating a sample application that will use B2C for authorization.
Create Azure Active Directory B2C
This all assumes you already have an Azure account. If you don’t you can sign up for a free trial (not an affiliate link). After you are signed up head to the Azure Portal.
Note: you can skip this section if you want to use the default Active Directory that is on your Azure account.
In the upper left click the Create a resource link.
In the search box look for Azure Active Directory B2C.
After selecting Azure Active Directory B2C more information will load to the right in a new panel. Click the Create button to continue.
Next, select if you want to create a new B2C tenant or use an existing one. I don’t have an existing one so the following flow will be for creating a new tenant.
On the next panel, you will need to enter an organization name and initial domain name. After entering valid values click the create button.
Switch Active Directory
Now that the new directory has been created we need to switch to the new directory in the Azure Portal. In the left panel click Azure Active Directory.
Click the Switch directory link.
A new panel will show on the right side of the screen with a list of directories you have available. Select the one you created in the steps above or an existing one you would like to use.
Using the search box in the top middle of the portal find Azure AD B2C.
Before moving forward on the Azure side we are going to create our sample client application. This little detour will make it easier for me to point out what values in Azure need to go where in the application configuration.
To create a new web application already set up to use Azure B2C use the following .NET CLI command from a command prompt. There is also a Visual Studio template if you prefer that route.
dotnet new webapp --auth IndividualB2C
In the resulting application, your appsettings.json will have the following section for AzureAdB2C.
Back to the Azure portal and the Azure AD B2C service page. In the Overview page, the first thing we need to make note of and use to set some configuration values in our application for is the Domain name.
In your appsettings.json file use this value for your Domain value.
The subdomain is also used to build the Instance like the following.
On the panel that loads hit the Add button. On the new Application panel, we need to give the application a Name, select the type of clients which is Web App / Web API in our case. Next, is the Reply URL which with default setup is your base url/sigin-oidc. I messed this value up in the beginning and got some really strange errors. Finally hit the Create button.
After the creation process is complete copy the value in the Application ID field and use it as ClientId in your appsettings.json file.
Back in Azure select the User flows (policies) option.
At the top of the panel that loads click the New user flow button. The next panel shows a selection of flows that can be added. The application we are making will use both the Sign up and sign in flow and the Password rest flow. I’m only going to walk through the first one, but the second one is very smiliar. Click on the Sign up and sign in like.
In the creation process you will need to set a Name for the flow and select the Identity providers that are valid for the flow. You also have the choice of fields to collect with this flow and which ones should be returned with the claim. After those options are set click the Create button.
The Name form this screen will need to be entered in your appsettings.json file for the SignUpSignInPolicyId value. Here is what I ended up with in my settings file with the Sign Up and Reset Password policies.
Does this automatically detect branches? From your screenshot, you’re building master. If you copy to feature-A, does a new pipeline automatically get created and built?
When I initially answered this question I didn’t go deep enough. The answer to does a new pipeline automatically get created and built is no as I replied, but I think the intent of the question is do I have to go set up a new pipeline every time I create a new branch and the answer to that is also no. The existing pipeline will be triggered when any change is checked in on any branch by default. Do note that it won’t be triggered when the branch is created only when a change is checked in.
There are a couple of ways to control what branches trigger continuous integration builds. The first is by making edits to the azure-pipeline.yml file in the repo and the second is via an override in the Azure Pipeline.
The official Build pipeline triggers docs are really good, but I will cover the basic here for including branches and excluding branches. Check for docs for information on path includes/excludes as well as how to control PR validation. As an example here is the yaml file used to define a build in this repo.
In order to control what branches get built, we need to add a trigger section. The smilest example is to list the branches you want to build. Ending wildcards are allowed. See the following example (trigger section taken from the official docs).
This would build master and everything in under releases that does not start with old. Really go read the official docs on this one to see all the ins and outs.
To override the CI build from Azure DevOp go to the build in question and click Edit.
Next, select Triggers and Continuous integration and check Override YAML.
After checking the override you will see a lot more options light up. As you can see in the following screenshot the same include and exclude options are available with the same options for wildcards.
As you can see Azure Pipelines provides a lot of flex ability in how a build gets triggered. On top of what I covered here, there are also options for setting up scheduled builds as well as trigging a build with another build is completed. If you hit a scenario that couldn’t be covered I would love to hear about it in the comments.
After last week’s post on Azure Pipelines: Release to Azure App Service I came across a much easier way to get started using Azure DevOps and Azure App Servies. This post is going to walk through this process which is started from the Azure Portal side instead of Azure DevOps.
The names here are going to be a bit confusing. When I say Azure DevOps I am talking about the rebrand of Visual Studio Team Services which includes services for boards, repos, pipeline, etc. When I say Azure DevOps Project, or just DevOps Project, I am referring to the project type this post is going to be using from the Azure Portal side.
For me, DevOps Project was in the list of popular items. If you don’t see it list you can use the search at the top to find it. Click on the DevOps Project to start the process.
On the next page, you have options to start a new application with a lot of different languages or to deploy an existing application. For this example, we are going to select .NET and click the Next button. This screen is a great example of how Microsoft is working hard to support more than just .NET.
For .NET the next choice is ASP.NET or ASP.NET Core. No surprise I’m sure that we are going to go with ASP.NET Core. There is also an option for adding a database, but we aren’t going to use it for this example. Click Next to continue.
The next step is to select which Azure Service the new application should run on. We are going to use a Linux Web App to match what last week’s sample was running on. Click Next to continue.
There are quite a few settings on this next screen, but they are all pretty clear. The first group of settings is for the Azure DevOps project and you can either use an existing account or the process will create one for you. A Project name is required.
The next group of settings is for the Azure App Service that will be created. Subscription should default in if you only have one. Web app name is going to control the URL Azure provides as well as play in the naming of the resources that are created. Click Done to start the creation process.
After clicking down above the deployment of all the need resources will start. This process takes awhile. The portal will redirect you to a status page similar to the following while deployment is in progress. It took a little over 4 minutes for mine to complete.
When the deployment is complete click the Go to resource button.
The Overview page for the project gives a great summary of the whole CI/CD pipeline that was created with links to the associated Azure DevOps pages to manage each step. The Azure resources section will have the URL you can use to access the running application.
The resulting application should look similar to the following.
This process is a much easier way to get started if you are going all in with Azure. If you read last week’s post you know there is a lot that goes into creating something close to this setup manually and even then it was missing the nice overview provided by this setup.
This post is going to use the same Azure DevOps project used in last week’s Azure Repos and Azure Pipelines post which had a build pipeline and add a release pipeline that deploys to an Azure App Service.
This walkthrough is going to assume you have an Azure account already set up using the same email address as Azure DevOps. If you don’t have an Azure account one signup for an Azure Free Account.
The build set up in last week’s post proved that the code built, but it didn’t actually do anything with the results of that build. In order to use the results of the build, we need to publish the resulting files. This will be needed later when setting up the release pipeline.
In order to get the results we are looking for a few steps must be added to our build. All the changes are being made in the azure-pipelines.yml. The following is my full yaml file with the new tasks.
As you can see in the above yaml this build now has three different steps. The build (this is equivalent to what the post from last week was doing) and publish (this gets all the files in the right places) tasks are both handled using the [email protected] task. Finally, the [email protected] takes the results of the publish and zips them to the artifact staging directory where they can be used in a release pipeline.
Create an Azure App Service
Feel free to skip this section if you have an existing App Service to use. To create a new App Service open the Azure Portal and select App Services from the left navigation.
Next, click the Add button.
On the next page, we are going to select Web App.
Now hit the Create button.
The next page you will need to enter an App name, select the OS, and Runtime Stack before hitting the Create button. The OS and Runtime Stack should match the target of your application.
Create a Release Pipeline
On your project from the left navigation select Pipelines > Releases and then click the New pipeline button. If you already have a release pipeline setup this page will look different.
The next page has a list of template you can select from. In this example, we will be selecting Azure App Service deployment and then click the Apply button.
Artifact Set Up
After clicking Apply you will hit the pipeline overview page with to sets of information. The first is the Artifacts which for us is going to be the results of the build pipeline we set up in last week’s post. Click the Add an artifact box.
The Add an artifact dialog is where you will select where the release will get its build artifact form. We will be using the source type of build and selecting our existing build pipeline.
Once you select your build pipeline as the Source a few more controls will show up. I took the defaults on all of them. Take note of the box highlighted in the screenshot as it will give you a warning if you build is missing artifacts. Click the Add button to complete.
Above we selected the Azure App Service template which is now in our pipeline as Stage 1. Notice the red exclamation, which means the stage has some issues that need to be addressed before it can be used. Click on the stage box to open it.
As you can see in the following screenshot the settings that are missing are highlighted in red on the Deploy Azure App Service task. On Stage 1 click the Unlink all button and confirm. Doing this means there is more setup on the Deploy Azure App Service task, but this is the only way to use .NET Core 2.1 at the time of this writing. For some reason, the highest version available at the Stage level for Linux is .NET Core 2.0.
After clicking unlink all the options other than the name of the stage will be removed. Next, click on Deploy Azure App Service task which handles the bulk to the work will place for this pipeline. There are a lot of setting on this task. Here is a screenshot of my setup and I will call out the important bits after.
First, select your Azure subscription. You may be required to Authorize your account so if you see an Authorize button click it and go through the sign in steps for your Azure account.
Take special note of App type. In this sample, we are using Linux so it is important to select Linux App from the drop down instead of the just using Web App.
With your Azure subscription and App type selected the App Service name drop-down should only let you select Linux based App Services that exist on your subscription.
For Image Source, I went with the Built-in Image, but it does have the option to enter use a container from a registry if the built-in doesn’t meet your needs.
For Package or folder, the default should work if you only have a single project. Since this, I have two projects I used the file browser (the … button) to select the specific zip file I want to deploy.
Runtime Stack needs to to be .NET Core 2.1 for this application.
Startup command needs to be set up to tell the .NET CLI to run the assembly that is the entry point for the application. In the example, this works out to be dotnet EfSqlite.dll.
After all the settings have been entered hit the Save button in the top right of the screen.
Execute Release Pipeline
Navigate back to Pipelines > Release and select the release you want to run. Then click the Create a release button.
On the next page, all you have to do is select the Artifact you want to deploy and then click the Create button.
Create will start the release process and send you back to the main release page. There will be a link at the top of the release page that you can click to see the status of the release.
The following is the results of my release after it has completed.
I took me more trial and error to get this setup going that I would have hoped, but once all the pieces are get up the results are awesome. At the very minimum, I recommend taking the time to at least set up a build that is triggered when code is checked into your repos. Having the feedback that a build is broken as soon as the code hits the repo versus finding out when you need a deliverable will do wonders for your peace of mind.
Last week’s post looked at using GitHub with Azure Pipelines. This week I’m going to take the same project and walk through adding it to Azure Repos and setting a build up using Azure Pipelines. I will be using the code from this GitHub repo minus the azure-pipelines.yml file that was added in last weeks post.
Creating a Project
I’m not going to walk you through the sign-up process, but if you don’t have an account you can sign up for Azure DevOps here. Click the Create project button in the upper right corner.
On the dialog that shows enter a project name. I’m using the same name that was on the GitHub repo that the code came from. Click Create to continue.
Adding to the Repo
After the project finishes the creation process use the menu on the left and select Repos.
Since the project doesn’t currently have any files the Repos page lists a number of options for getting files added. I’m going to use the Clone in VS Code option and then copy the files from my GitHub repo. If I weren’t trying to avoid including the pipeline yaml file an easier option would be to use the Import function and clone the repo directly.
I’m not going to go through the details of using one of the above methods to get the sample code into Azure Repos. It is a git based repo and the options for getting code uploaded are outlined on the page above.
Set up a build
Now that we have code in a repo you should see the view change to something close to the following screenshot. Hit the Set up build to start the process of creating a build pipeline for the new repo. This should be pretty close to the last half of last week’s post, but I want to include it here so this post can stand alone.
On the next page select Azure Repos as the source of code.
Next, select the repo that needs to be built for the new pipeline.
Template selection is next. Based on your code a template will be suggested, but don’t just take the default. For whatever reason, it suggested a .NET Desktop template for my sample which is actually ASP.NET Core based. Select your template to move on to the next step.
The next screen will show you the YAML that will be used to build your code. My repo contains two projects so I had to tweak the YAML to tell it which project to build, but otherwise, the default would have worked. After you have made any changes that your project needs click Save and run.
The last step before the actual build is to commit the build YAML file to your Azure Repo. Make any changes you need on the dialog and then click Save and run to start the first build of your project.
The next page will show you the status of the build in real time. When the build is complete you should see something like the following with the results.
As expected using Azure Repos with Azure Pipelines works great. If you haven’t yet give Azure DevOps a try. Microsoft has a vast offering with this set of products that are consistently getting better and better.