Don't worry. Not everyone knows it...

Ngrok is one of the well-known tool for local tunneling  solution. I have used it many times being the easiest tool for any developer. This time once again, I thought to use Ngrok for my current application, which uses Graph API to get notifications from Microsoft Teams channel. As always, I launched the Ngrok with required port as shown below: ngrok http 44332    and it got connected as shown below: Till now everything is alright. But now when I ran my application with Ngrok’s forwarding address, I end up getting an error -  400 Bad Request . And here is what I read more about this: Seems like some applications can’t deal with the default behavior of Ngrok and need an explicit mention of header information, which means there is another way to handle such scenario: ngrok http http://localhost:44332 -host-header="localhost:44332" After connecting Ngrok with above command, everything went very smooth and as expected. Hope this tip would be useful fo...

Generally, whenever something is to be saved to the database or to any other place, as a best practice almost everyone use to validate the state of the model. So, if state of model is valid, we proceed and if model state is invalid, we handle it as a bad request. This looks something like this: If(!ModelState.IsValid) { // create bad request object } So, all these were done by using the IsValid property. Problem Now what if we have to perform the same validation for all the models. Are we going to write the same validation in each and every controller? Of course, No. Solution Rather than duplicating the same code in each and every controller, we can create a global filter. This global filter has few methods, but for our purpose we can go with OnActionExecuting . public class ValidateModelStateFilter : ActionFilterAttribute { public override void OnActionExecuting(ActionExecutingContext context) { if (!context.ModelState.Is...

Most of us might have worked upon various versions of ASP.NET and few of you must be aware about the major changes happened in application initialization and configuration phase. In this article, I'll be outlining few of those major changes starting from ASP.NET MVC, ASP.NET Core 1.x and ASP.NET 2.x. In ASP.NET: In an era of ASP.NET (prior to ASP.NET Core releases), loading of the application was handled by IIS or say Inetmgr was the one who use to call web application's entry point wherein Global.asax.cs use to provide the Application_Start()method.Below is the sample code snippet take from Global.asax.cx file:        public class MvcApplication : System.Web.HttpApplication   {        protected void Application_Start()        {               AreaRegistration.RegisterA...

Nowadays one of the most popular question is ‘Can ASP.NET Core be chosen over ASP.NET MVC?’ So, to answer this question, let’s have a look at .NET architecture diagram:  By looking at above diagram, one can easily see that .NET framework is used develop desktop Windows applications using WPF and Windows Forms and Web applications using ASP.NET MVC. .NET Core supports UWP and ASP.NET Core libraries, in which UWP is used to create Windows 10 apps and ASP.NET Core is used to build Web applications for Windows/Linux/Mac operating systems. Now regarding what has to be chosen and when has to be chosen, I need not to re-invent the wheel because Jeff has written a very good article on it at ‘’Should I use ASP.NET Core or MVC5?’. Hope you find this post useful.

Another interesting feature of ASP.NET Core is service consumption using Dependency Injection. I already provided the overview of Dependency Injection in my earlier articles. Moving further, in this article we will see how one can inject and consume services to controller using dependency injection. In ASP.NET, you can access services at any stage of your HTTP pipeline through dependency injection. By default, it provides Constructor injection, but it can easily be replaced by any other container of your choice. Before moving ahead, one point is very important to understand and that is lifetime of services. ASP.NET Core allows you to configure four different lifetimes for your services. Transient - Created on every request Scoped - Created once per request Singleton - Created first time when they are requested Instance - Created in ConfigureServices method and behaves like a Singleton To understand the service consumption in easier way, we...