.Net Standard Library is a specification through which API portability is achieved on all .Net runtimes. It defines a set of base class libraries which are compatible with all .Net platforms like Windows, UWP, .Net Core, .Net Framework, Windows Phone etc. Using BCL’s, developers can write custom portable API and use them across different .Net platforms.
In this tutorial, we are going to see how to support versioning for ASP.Net Core Web API endpoints. Versioning helps API owners to roll out enhanced functionalities to different customers on a time to time basis without breaking the old versions of endpoints. In previous versions of ASP.Net, we used to create a custom IHttpControllerSelector through which we will route the request to appropriate controller version based on custom header or URL pattern. In ASP.Net Core, we will use aspnet-api-versioning middleware (created by Chris Martinez).
In this tutorial we are going to demystify the contents of Publish folder of an ASP.Net Core MVC application. To host an ASP.Net Core Application, we publish it using dotnet publish command of Dotnet CLI. Publish folder is created as an output of dotnet publish command and it contains all the necessary dependencies along with project artifacts for successful project hosting.
In this tutorial, we are going to see how to publish an ASP.Net Core 1 Application to IIS. Unlike older versions of ASP.Net, ASP.Net Core 1 applications are not dependent on IIS for hosting. In fact ASP.Net Core 1 applications are console applications and run in their own Kestrel Web Server. But if we need to have more functionalities which IIS provides by default (or through extensions), then we can use IIS as reverse proxy which will forward requests to Kestrel.
In this jumpstart we are going to see how to set Environment variables in ASP.Net Core MVC application. This is new feature in ASP.Net Core and primarily used for configuring the behavior across multiple environments likes Development, Staging and Production. We can also add extra environment variables and access them in application using IConfigurationRoot.
Caching helps in improving performance of an application by replicating the data (otherwise which has to be fetched from database or any other source). ASP.Net Core supports both in-memory and distributed caching. In-memory caching holds the copy of data in local server’s memory, where as distributed cache maintains cache in a centralized location which is accessible by servers in cluster. In this tutorial we are going to see how to implement both in-memory and distributed caching in ASP.Net Core MVC application.
In this Jumpstart, we are going to see how to use Redis Distributed Cache 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 Redis Cache) acting as Session store. Sessions can be shared across multiple applications and also between multiple servers in a cluster. Redis is also capable of supporting different data types and it is faster than SQL Server (because of its in-memory nature). Redis also supports cluster for scaling and persistence to disk (data will not be lost on server restarts).
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.
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.
In this tutorial we are going to see how to create a simple Azure WebJob using a C# console application with parameters. Azure WebJobs are used to run scripts or programs (typically long running) as background processes on Azure Web Apps. WebJobs can be ran in three different ways – Manually triggered, Trigger on a Schedule and continuously trigger. WebJobs are capable of executing different scripts(for example cmd, bat, exe, js, jar, ps1 etc.,).
In this jumpstart, we are going to see how to download a file from server to client browser in ASP.Net MVC using a RouteHandler . A RouteHandler will be created to handle all the requests made to a particular URL with specific route data (part of URL itself) to identify the file requested and will return a particular HttpHandler for the request. HttpHandler is going to find the file on the server, set it into the Response of HttpContext and finally send the response back to the client (typically a browser, but it can be anything).
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).