If you are looking to set the value of the cookies across all the controllers, you can use action filters and apply them on controllers. Action filters contain logic that will be implemented before or after a controller action is executed. They can be applied to an individual action method or the entire controller.

I will give you an overview of how your ActionFilterAttribute class could look like and explain each step along the way. You can find screenshot examples below.

Overview of an ActionFilterAttribute Class

1. Create a public class named UserCookieFilter that inherits from ActionFilterAttribute
2. Override the OnActionExecuting method
   • OnActionExecuting method is one of the four overload methods in the ActionFilterAttribute that will be called “before” the controller is called. It takes an ActionExecutingContext as its parameter.
3. Pass that filter context into the base OnActionExecuting method
4. Set the default value of the cookie
5. Create conditions to modify the value of the cookies accordingly
6. Add the value of the cookie to the filter context
7. Apply the filter to the controller

You can now apply the UserCookieFilter attribute to the controller and your cookies will be passed along to the view.

You can use the hidden input value if you need the value of the cookie to render some parts of the view using JavaScript.

<input type="hidden" id="buttonInfo" value="@Response.Cookies["adminAccess"].Value" />

<script>
    var buttonInfo = document.getElementById('buttonInfo').value;
</script>

In this blog post, I will briefly describe the concept of rebasing and go over how it is done in Visual Studio.

Merging vs. Rebasing

When you are merging branches, you simply merge the latest dev branch into your current feature branch as shown in the diagram below.

Unlike merging, rebasing “re”-bases the feature branch with the latest dev branch.

When you rebase, the latest changes in the current branch (‘f1’ & ‘f2’) are internally saved for a moment. The latest pull from the dev branch (‘d2’ commit) in the current branch is then re-based with a ‘d4’ commit and the internally saved commits (‘f1’ and ‘f2’) are added back.

Rebasing in Visual Studio

Let’s now look at how rebasing is done in Visual Studio.

Here is an overview of the process:

1. Commit and sync the changes in the current branch.
2. Rebase the current branch onto the ‘develop’ branch.
3. Merge conflicts in the detached branch.

Let’s imagine you added the ‘f1’ and ‘f2’ features. Commit and sync the changes.

Go to the ‘Branches’ tab in the Team Explorer and rebase the current feature branch onto develop branch.

Notice how a branch ‘Detached at {id}’ is created upon rebasing. This is a detached branch created internally for us to resolve conflicts.

Accept merge and resolve any conflict that is generated.

Return to the ‘Changes’ tab in the Team Explorer and click ‘Continue’ under ‘Rebase In Progress’.

You will then notice you are back in the feature branch.

You can now push the changes to your repository!

If you are trying to build a .NET Core Web Application with React.js, there is a template that you can create your project with in Visual Studio. However, if you want to incorporate Typescript in your application, there are a few extra steps that you have to take. This blog post is possible thanks to Josh Kostal.

Create your .NET Core Web Application with the React.js template.

Once you create the project, head over to Visual Studio Code and open the folder containing the project. Right-click the ClientApp folder and delete it.

Open up a new terminal.

Step into the sub-folder by doing a ‘cd <name of your folder>’. Enter ‘npx create-react-app my-app –template typescript‘ to create your react application with typescript.

You may delete these files at your discretion:

• src/setupTests.ts
• src/App.test.tsx
• src/Index.css
• WeatherForecast.cs
• WeatherForecastController

Remove those lines that import any of the files deleted above.

Step into the react app and ‘npm install –save bootstrap to install bootstrap. Click here for a reference.

Now you can run ‘npm start’ to open up your application in your localhost!

You’d have to run the Azure SQL DacpacTask in your Release Pipeline to continuously deploy your database to Azure SQL. However, if your .dacpac file is not recognized in your build artifact during the DacpacTask, you have to manually add some lines in your Build Pipeline.

NOTE: I’d already deployed our local database to Azure SQL manually before implementing CI/CD for the database. Click here to learn how you can do that in SSMS.

First locate your .dacpac file in your project. From where your SQL project is, navigate to <name of your project>/bin/Release folder. Refer to the GIF below.

Once you have found your .dacpac file, add a CopyFiles Task with a ‘**/*.dacpac’ under its Contents key and a PublishBuildArtifact task with a PathToPublish configured to where you .dacpac file is located in relation to your .NET Framework Web Application solution.

The PathToPublish in our example here is ‘$(Build.ArtifactStagingDirectory)/4 – Database/BootTrack.Database/BootTrack.Database/bin/Release’.

Once your build runs successfully, navigate to view your build artifact. If you correctly set your path to the file, you will see the .dacpac file in your artifact as shown below!

Add the path to your .dacpac file in your Azure SQL DacpacTask.

I will be going over how you can export your local SQL Database to Azure SQL within SSMS. If you have not created your SQL server and database on Azure, here is a tutorial I found on Youtube that guides you through the process.

Open your SQL Sever Management Studio and enter the Azure SQL server name from above and the credentials you have configured for the server.

Right click the local database you want to export and select ‘Tasks’ > ‘Export Data-tier Application’.

Click next and configure where you want to save your .bacpac file.

Once the export is complete, an ‘Operation Complete’ message will appear.

Now right click the database folder of the database connected to the Azure SQL.

Browse and select the .bacpac file you created above.

Name your database and configure your Azure SQL Database settings to match that of your Azure SQL settings in your portal.

Once your import has succeeded, you will be able to see your table deployed in your query editor.

For an updated tutorial with GIFs, click here.

We are going to be continuing from where we left off in the last post. If you are trying to follow along and want to take a look at how I set up the folder structure, click here.

Overview

1. Create a SQL server database project and configure the path to the ’04 – Database’ folder (or whichever folder you want to place it in).
2. Add an existing project in the Visual Studio.
3. Add scripts and table files.

Details

1. Create a new SQL Server Database Project. This is the database where the schema and the scripts will go.

1. Name your project and configure the path to the ’04 – Database’ folder we created earlier. I will name it ‘Demo_01.Database’ in this example.

Demo_01.Database project will open up but simply close it and go back to the original Demo_01.sln file. However, you will notice that the .Database project you just created is not visible in the solution.

1. Right click the solution and Add an Existing Project. Locate the SQL server database project you created in Step 1 and click ‘Open’.

1. Drag the .sqlproj file you just opened into the “04 – Database” folder and right click that .sqlproj file to create sub-folders called “Tables” and “Scripts”.

1. Right click the Tables folder to add a Table and the Scripts folder to add a Script (Not in build) & Post Deployment Script.

• Table is where the columns will be defined.
• Scripts are where the data will be seeded (empty when you first publish the tables).
• Post deployment script will run once the tables are deployed. This script includes simple commands to allow each of the seed scripts to run and you NEED this.

Examples

Below are examples of how each of the three files would look like.

Again, the script file is empty the first time you publish it. This is how the script would appear when you need to seed the data afterwards.

Simply add ‘:r .{script name}.sql. You can ignore the red lines with the Post Deployment script file if they appear.

That is all you have to do to add the database project to your .NET MVC Web Application!

If you have a project in your repository that you want to host on the web, running the build and release pipelines on Azure is one way to go. Although configuring them is super easy, the process itself is not very intuitive especially the first time you encounter it because what each pipeline does is not self-explanatory. In this blog post, I will be going over what you need, what each of the pipeline does, and how you can configure them.

You need two things prepared in advance: 1) a project in your repository and 2) an App Service on the Azure portal. Since setting up the App Service is very straightforward, I won’t be covering that here. Here is a detailed tutorial I found on Youtube for your reference. Once we have them, we will first create the build pipeline before configuring the release pipeline to allow Continuous Deployment (CD).

So what is a Build Pipeline? You can think of a Build Pipeline as a tool to lay the groundwork for the actual deployment that would be done later in the Release pipeline. It automates everything from setting up the trigger (indicate which branch you will detect the changes in to trigger the pipeline to run) and installing the Nuget packages to building and testing the VS. As you can see in the GIF below, you configure those in the pipeline YAML (A configuration file just like an XML).

Here is where we are going to start. Open up your Azure DevOps and go the the Pipelines tab.

When you click the ‘Create Pipeline’ button and select the corresponding repository and version, all the YAML file will be configured for you.  Just one thing you have to manually add is the “Publish build artifacts” task. Build artifact is basically a compilation of the environment and the project itself that will be called in the Release Pipeline. Publishing the build artifacts is the gist of the build pipeline and you have to manually add the task by searching for the task from the assistant menu (Refer to the GIF below).

You can then save and run the YAML file. I am running the pipeline on the master branch in this example but make sure you create a new branch for your commit.

Once you save and run the pipeline, it usually takes a few minutes to complete and you will be directed to the pipeline summary page.

Once the pipeline has been built successfully, move on to the ‘Releases’ tab. The Release Pipeline allows Continuous Deployment (CD) by integrating the artifact your just published and automating all the deployments.

Refer to the GIF below and follow these steps:

1. Click the ‘New Pipeline’ button.
2. Apply the Template (‘Azure App Service Deployment’ template is used in this example but you can choose the empty template and manually add the tasks to fit your needs—refer to an example below).
3. Name your stage and configure your task.
4. Create the association with your Azure subscription and the App Service you created.
5. Save!

We can now add the artifact that we created earlier in the Build Pipeline. Return to the Pipeline tab.

1. Click ‘Add an artifact’ and choose the corresponding artifact. If you didn’t publish the build artifact as I described above, you wouldn’t be able to locate your artifact in this step.
2. Click that thunder icon and enable continuous deployment. With this enabled, the release will be made every time you run your pipeline.

Go back to your ‘Pipelines’ tab and choose the pipeline you created earlier. Run the pipeline!

Once you have successfully run the pipeline, you should be able to see your project hosted on the URL provided in your Azure App Service. If your azure website URL redirects you to a localhost, click here to see how you can resolve that issue.

Here is an example of how you can configure the tasks in your release pipeline to automate the Azure SQL and App Service deployment tasks.

In the following post, I will be going over how you can extract the .dacpac file from your project and seamlessly deploy your database to Azure SQL within your pipeline. Hope that helped!

If you are struggling to set up the web.config files upon hosting your web application, here is a solution to how you can configure your Web.Debug.config and Web.Release.config file so that your application runs dynamically on both the dev and prod environments.

Web.Config

Leave the original web.config file as it is. Make sure you have your RedirectUri configured as well. Click here to see how you can manually set that up if your hosted site directs to your localhost upon authentication.

Web.Debug.Config

Add the keys for Environment(default) and Connection String in the Web.Debug.config file.

• xdt:Locator=”Match(key)” indicates that we want to match with the key variable.
• xdt:Transforms=”SetAttributes” allows us to set the corresponding key with the value we have assigned here. You can also “Replace”, “Insert”, or “RemoveAttributes()”. Click here for more syntax.

Web.Release.Config

Same logic applies to the Web.Release.Config file. Here is where you manage your configurations for your hosted site. Set the attributes for your Environment (default), ClientId, RedirectUri, PostLogoutRedirectUri, and ConnectionString.

Where Do I Find my Client ID and Connection String?

In case you are confused on where you can retrieve your ClientId or the ConnectionString for your Azure SQL, refer below.

In your Azure Portal, go to Azure Active Directory > App Registrations > Corresponding Web App to get your ClientId for the hosted web application.

SQL databases > Connection Strings > SQL Authentication

Hope that helped!

If you have created your App Service on Azure but it redirects to a localhost instead of the Azure website URL upon authentication, there are some changes you will have to make in your Web.config file. In our example, we will be using Microsoft.Owin.Security.OpenIdConnect library for authentication (Azure AD).

We are using .NET Framework 4.7.2 in our project. Ensure that the version in the App Service aligns with that of the project.

The redirect issue is occurring because Azure Active Directory simply does not know where to send the user back to upon authentication. To resolve this issue, we simply have to manually add the RedirectUri configuration value in Web.Config and include that in the OpenIdConnectAuthenticationOptions! Note RedirectUri is different from PostLogoutRedirectUri.

Add the RedirectUri key with the azure website URL as its value.

In case you forgot, ClientID and TenantID can be found under AAD > App registrations > Corresponding Web App.

Call RedirectUri in the Startup.Auth.cs file using ConfigurationManager and store the value in the _redirectUri variable.

Add the RedirectUri to the OpenIdConnectAuthenticationOptions.

There should be many reasons why this has to be manually configured but for my case, I am assuming this happened because I already had an Active Directory set up within the project before creating the App Service. I will include a documentation from Microsoft here that helped me understand the sign-in process.

Hope that helped!

Click here for an updated post explained with GIFs.

Now that we have the database in our SQL Server Project a DbContext, how do we pass the data to the view? We can construct asynchronous methods in a provider class to call the data in the controller.

Before we move on, if you don’t have your SQL Server Project or your DbContext, click here to see how you can configure the SQL Server Project and here to learn how you can reverse engineer to generate a DbContext.

Overview

1. Create Class Libraries (.NET Framework) and folders under them
2. Add a Data Transfer Object (DTO), a replica of a model that will be used to transfer data
3. Add a Provider Class and create async methods
4. Call the async methods from the controller and pass the data to the view

Note how we are following a folder structure we created in this post.

Adding Class Libraries

Create a Class Library (.NET Framework). Configure the file path to where your .NET Framework Web Application is. I will be placing the Class Library under ’02 – Application’ folder as we created earlier here. This class library will hold the provider classes.

Create another Class Library that will hold our models (DTOs) and View Models. You could append. Domain to the project name. Again, configure the location to ’03 – Domain’ folder.

Return to the .NET Framework Web App and right click the solution to add the Class Libraries we just created (‘Add Existing Project’). Drag the added tasks into the corresponding folders. Refer to step 3 of this blog post here to learn how you can add existing project.

Right click the Class Library and add Interfaces and Providers folders  under ’02 – Application’ folder and Models and ViewModels folders under ’03 – Domain’ folder.’

Creating a DTO and a Provider Class

Add a ‘CustomerDto’ class under ’03 – Domain > Models’ folder. Add the properties (fields) with getters and setters.

In this folder structure that I am working in, notice how the CustomerDto is stored in the Models folder under ’03 – Domain’, while the actual Customer Model is stored in the Models folder under ’04 – Database’.

**Before moving on, we need to override DbContext.OnConfiguring(DbContextOptionsBuilder) method in the DatabaseContext to configure the database to be used for this context. Click here for a post explaining how you can set that up.

Now we can add a ‘CustomerProvider’ class under ’02 – Application > Providers’ folder.

• Declare the DbContext as private readonly
• Create constructors (constructor chaining is used) that will instantiate the DbContext using Dependency Injection

Add a GetCustomersAsync() method that will store data from DbContext in a list of CustomerDto using LINQ.

• Task<> represents a single operation that usually executes asynchronously.
• In our example, we are using LINQ to .Select variable (Id, Name, & Email) to store each of them in the variables of CustomerDto object. We are using .SingleOrDefaultAsync() method to return the CustomerDto object.
• .AsNoTracking() is conventionally used because entities returned will be cached in the DbContext by default, rendering errors when we are calling an entity in different places at the same time.

We can use .ToListAsync() method to return a list of objects as demonstrated below.

Along the way, you might have to install packages (Microsoft.EntityFrameworkCore) to add a reference to the DbSet.

NOTE: We will need to install couple of Nuget packages to use the Task class and SqlClient for DbContext to interact with the Sql Server. Without the installations, you might encounter errors like “Could not load file or assembly ‘System.Threading.Tasks.Extensions'” like the one shown below:

Click here to fix the “Could not load file or assembly ‘System.Threading.Tasks.Extensions’ or one of its dependencies” error and here for the “Failed to load \bin\x86\SNI.dll” error.

That is pretty much it for creating DTO and async method in the provider class. Now we can call the method from the controller and pass it to the view!

Creating a Controller and View

1) In our examples, we will be using IndexController. Create constructors to instantiate the providers. I can call .GetCustomerAsync() method that I created in the provider class and store it in a variable. We will then pass this variable to the view.

2) This is how our razor page and the view will look like!

How our Demo_01 database looks like

Hope that helped!

Welcome to Part 2 of the tutorial! Now that we have the table, scripts, and post-deployment scripts from Part 1, we are going to publish the table to our local server, reverse engineer to create the Dbcontext, and add other components like providers and models (DTOs and View Models).

Details

Publish Database and Reverse Engineer

Click here for a condensed GIF showing how you can publish the database.

Right-click Demo_01.Database (SQL Server Database Project) and select ‘Publish’ to publish the data in VS to your local machine. Click ‘Edit’ and locate the server you want to publish the database to. Browse and type ‘.’ for a local server.

Click the “Advanced…” option and select the “Always re-create database” option. With this option, Visual Studio will drop the current database and re-create the new one every time you publish tables with recent changes.

Click “Save Profile As…” and save .publish.xml file the first time you set up. You will then find this .xml file, which you can simply double-click to publish for any changes in the future.

Once you click ‘Publish,’ you will notice a table with data added to your local database in your SQL Server Management Studio (SSMS)!

Add Class Libraries and Reverse Engineer

Click here for an updated post going over how you can reverse engineer in GIFs.

Now we are going to create a Class Library (.NET Framework) that will contain the DbContext that corresponds to the tables we created in the SQL Server Database Project (Demo_01.Database).

Name it.Data (a naming convention you could follow) and set the location path to the “04 – Database” folder.

Once you create the project, head back out to the Demo_01.sln that we had been in. Repeat 10) of Part 1 of this tutorial to ‘Add Existing Project’ and drag the newly created file under the “04 – Database” folder.

At this point, the folder structure would look like this.

Before we can reverse-engineer, we need to download EF Core Power Tools. You can download it here. Right-click Demo_01.Data (Class Library) and select ‘Reverse Engineer.’

Select Demo_01.Database (SQL Server Project), check ‘Use EF Core’ and click ‘OK.’

Choose the table you created and click ‘OK.’ Name your DbContext as you wish and click ‘OK.’

You can observe how a model is automatically configured using ModelBuilder and a DbSet that mirrors the table we created earlier.

Here is the Model created for us. We can remove the Class1.cs file that was auto-generated.

That is all we need to set up the database part of our solution! Now we are going to move on to set up providers in the Application folder and models (DTOs) and view models in the Domain folder.

Add Providers and Models

Providers are where the DbContext will be called, and models (DTOs) will be populated with data from it. We will create Class Libraries for a Demo_01. Application project and a Demo_01.Domain project and place it under ’02 – Application’ and ’03 – Domain’ folders, respectively (Refer to Step 4 and 5 of this tutorial).

Create a Class Library (.NET Framework) like we did in 4) that will later hold providers. You could append. Application to the project name. Don’t forget to set your location to the ’02 – Application’ folder.

Create another Class Library that will hold our models (DTOs) and View Models. You could append. Domain to the project name. Again, configure the location to ’03 – Domain’ folder.

Return to the Demo_01.sln project and right-click the solution and add existing projects. (Refer to 10. of Part 1 of this tutorial). Drag the added tasks into the corresponding folders.

’02 – Application’ folder will contain Interfaces and Providers folders while ’03 – Domain’ holds Models and ViewModels folders.

Now that we have the entire structure constructed for the solution, it is time to populate our models with data! I will go over those in the following tutorials to come. Thank you for reading!

Click here to read an updated post explaining the folder structure setup using GIFs.

Before you begin reading, keep in mind that this tutorial is designed for beginners. As such, it covers every step without skipping parts that might be obvious to some. This tutorial is made possible thanks to Josh Kostal, who taught me majority of what is covered in this post.

The reason you have to undergo such a tedious process to create the initial folder structure is because folders created in the File Explorer will not be mirrored inside the Visual Studio. We also have to manually reconfigure the new path to the .csproj file after moving the application over to the new folder.

Overview

1. Create an ASP.NET Web Application (.NET Framework).
2. Create the folder structure in the File Explorer (01 – Presentation, 02 – Application, 03 – Domain, and 04 – Database).
3. Transfer the application created in 1) to the ’01 – Presentation’ folder.
4. Reconfigure the path for .csproj file.
5. Go into Visual Studio and create the Solution Folders that align with the folder structure in the File Explorer.
6. Drag the original project into the ’01 – Presentation’ solution folder inside the Visual Studio.

Details

Creating the Folder Structure

1) Create a new ASP.NET Web Application (.NET Framework) using the MVC template. I will name the application ‘Demo_01’ in this example.

2) Once you create the project, go to where the project is located in the File Explorer. Inside the folder that contains the .sln file, create folders that will each hold the ‘Presentation’, ‘Application’, ‘Domain’, and ‘Database’ component.

3) Drag all the items in the application folder (source > repos > Demo_01 > Demo_01 in this example) into the “01 – Presentation” folder. The image below demonstrates all the items that were dragged and dropped (or copied and pasted) into the new folder.

4) Open .sln file with a Notepad++ (Notepad works too).

5) Edit the path for .csproj file (now that you have moved the .csproj file from the original application folder to the “01 – Presentation” folder). You can change where it is highlighted in the image below.

However, when you open up the .sln file, you are going to realize how the folders you created in the File Explorer are not reflected within Visual Studio. You will have to create solution folders separately inside Visual Studio.

6) Right click the solution file and add a New Solution Folder (Note how it is NOT a regular New Folder).

7) Drag the project into the “01 – Presentation” folder and create other solution folders accordingly.

Now that we have set up the folder structure, click here to learn how you can add a SQL Server Database Project to the application here.