In this Jumpstart, we are going to see how to use SQL Server as Session store for an ASP.Net Core Application. There are multiple advantages in having a distributed cache storage (in this case it is SQL Server) acting as Session store. Sessions can be shared across multiple applications and also between multiple servers in a cluster. There are also some disadvantages around performance (in-memory is faster than SQL Server based session store) and operational overheads of maintaining additional SQL Server database.
Category: ASP.Net Core
In this tutorial, we are going to see how to configure an ASP.Net Core MVC Application to use Session state. In previous versions of ASP.Net, session management is straight forward by using HttpSessionState. But in ASP.Net Core MVC application it is not straight forward, we have to add and configure ISession Service along with an IDistributedCache implementation. In ASP.Net Core, ISession exposes new API to support saving and retrieving objects from Session state.
Program and Startup classes are breaking changes in ASP.Net 5 (although they are existed in unified Startup class, in ASP.Net Core they are diverged into separate classes) which are used to start the application and support application’s HTTP pipeline. In previous versions of ASP.Net we have Global.asax which exposes different events at application life cycle level. In this jumpstart, we are going to see what is the relevance of both classes in ASP.Net Core Application.
In this tutorial, We are going to see how to deploy an Azure WebJob which is based out of an .Net Core Console Application using PowerShell. At this point of time there is no built-in support in Visual Studio to deploy .Net Core based application as an Azure WebJob. We can either deploy the WebJob directly at Azure Portal (which is straight forward) or by using PowerShell. We are going to use combination of PowerShell and Azure Cmdlets to deploy the WebJob.
In this tutorial we are going to see how to use .Net Core Console Application as an Azure WebJob. .Net Core Console application is different from traditional .Net framework Console Application in generating the project outputs. Traditional .Net framework Console App generates executable as project output, but .Net Core Console App will generate DLL (library). We have to do little extra work to make .Net Core Console Application work as Azure WebJob.
Browser Link is a feature of Visual Studio (from 2013) which will help in refreshing web application in different browsers at once in debug mode. Browser Link uses SignalR to establish a communication channel between Visual Studio and browser. When browser link is in use, Visual Studio acts as SignalR Server and browsers will act as clients and any new changes will be propagated to browsers just with a button click in VS.
In this shot tutorial, we are going to see how to send an SMS in ASP.Net Core 1 Application using Twilio SMS Provider. Twilio is a cloud infrastructure based communications company which allows software developers to make and receive phone calls and send and receive text messages using its web service APIs. Twilio offers pay-as-you-go pricing model which makes easy to get the required services at right time. Additionally Twilio offers volume pricing for high volume requirements. Unfortunately Twilio doesn’t support .Net Core development at this point of time, but we can still use its Cloud based API to get the required functionality.
In this short tutorial, we are going to see how to send an email in ASP.Net Core 1 application using SendGrid email provider. SendGrid is a cloud-based email provider for businesses which will take away the burden of complexity in maintaining custom email infrastructure and configuration. SendGrid got different subscription plans for businesses (customization is available for high volume) which includes a free plan of 12,000 emails per month. Fortunately SendGrid supports .Net Core development through its nuget package and it is very easy to integrate.
Cross Origin Resource Sharing (CORS) is one of the important standard which will allow applications on different domains to interact with each other. Without CORS, applications are prevented by browser to make cross origin AJAX requests (cross origin means different applications hosted on different domains). Enabling CORS is helpful in scenarios where frontend UI and backend API are hosted on different domains. Fortunately in ASP.Net Core configuring CORS is a very easy task.
ASP.Net Core provides appsettings.json file through which we can maintain all the custom configuration required for the successful execution of application. This is a breaking change compared to previous versions of ASP.Net where web.config is primarily used to hold configuration. Appsettings.json is light weight configuration file where all settings are stored in json format and just like web.config we can have have different configuration files for different environments (do not mistake me this is nothing related to transformations, but rather cascading). Accessing this configuration data can be done through Options pattern and ASP.Net Core provides a default middleware to achieve this functionality. In this tutorial, we will see how to access configuration in appsettings.json file and also how to maintain different config files for different environments (staging, production etc.).
Exception handling in the key feature in making an application robust and secure. Handling exceptions at different levels is always a tricky task. In previous versions of ASP.Net, we have multiple ways (Exception filter, Global.asax, OnException at Controller etc.,) to achieve exception handling. Fortunately ASP.Net Core made developers life easy by making global exception handling available through middleware. If default middleware doesn’t meet a project’s requirement, one can always create a custom middleware to handle exceptions.
Dependency Injection is a design pattern in which dependencies are injected into a class at runtime. This software pattern ensures the system is loosely coupled and have high code reusability. So typically we have an interface which defines the signature of the whole contract, and then we have different implementations (not necessarily many, but at least one) of the same interface. Now we have Web Application which is dependent on this interface. Then using Dependency injection we can inject the right implementation (there should be mapping of interface and implementation either in configuration file or at Startup.cs) of the interface at runtime (or whenever the web application is in need of).
In this tutorial, we are going to see how to create an ASP.Net Core Web API project. We will develop a simple CRUD (Create Read Update Delete) operations API for Student object. Finally we will test the API using Postman tool (a tool to build, test and document APIs). ASP.Net Core framework follows a single and unified approach for building both MVC and Web API applications (because it share the common code base and the same HTTP pipeline). The plain pipeline (which ASP.Net Core provides) gives more control to developer to innovate through his own middleware’s (in fact MVC/Web API is a middleware too) and also a flexibility to include his own choice of 3rd party middleware’s to achieve the functionality.
In this tutorial we are going to see how to run multiple ASP.Net Core projects using Dotnet CLI’s dotnet run command. Typically dotnet run command is used to run a specific .Net Core application from source code. But there might be scenarios where we want to run multiple applications simultaneously to complete the development of a particular business workflow. For example we might have one ASP.Net Core project for MVC and another for Web API (and MVC consuming Web API), in this scenario we have to run different command line interfaces (each specific to the project which is intended to run) with dotnet run commands. In the scope of this tutorial we are going to write a simple PowerShell script through which we will automate the entire process of running multiple ASP.Net Core Applications using dotnet run.
Dotnet Run command by default host the ASP.Net Core application at port 5000. As obviously we cannot host more than one application at 5000 port, we can easily change the default port to new one.
In this tutorial, we are going to see how we can configure our development environment with the latest Dotnet CLI bits (from Dev branches builds). We will also make sure to pull relevant project dependency bits from MyGet repositories. Developers and organizations tend to maintain stable builds at Nuget repositories where as MyGet is used for nightly Dev builds (in some case unstable versions). The main objective of this tutorial is to demonstrate the flexibility of open source ASP.Net Core (and .Net Core) platforms, through which any developer can get the latest bits of runtimes/frameworks/libraries and can experiment different solutions. Being open source, any developer can identify the defects in the latest bits, report to respective teams and can even suggest a possible fix through pull request (in GIT repository).
In Getting Started with ASP.Net Core 1 Application, we saw how to create a new ASP.Net Core 1 Application and run it. In this tutorial we are going to understand the Visual Studio Project structure. There are lot of changes to the Core Project structure when compared to traditional ASP.Net MVC4 Project. We will go by each folder and file to understand its relevance in the project context.
In this short tutorial, I am going to show on how to get started with ASP.Net Core Application. ASP.Net Core is a completely new, open source and cross platform framework from Microsoft. ASP.Net Core Applications primarily work with two different frameworks – .Net Core and .Net Framework. .Net Core is used to support multiple platforms like mac OS, Linux and Window, where as .Net framework supports only Windows. One more advantage of ASP.Net Core Application is that it can support both the before mentioned frameworks at the same time in same project (for other .Net Core Projects, there are other frameworks like .Net Standard).