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

While working on web application, it’s quite natural that we need to jump between various environments (i.e. Development, Testing, Production, etc.) during various phases of product life cycle. In other words, all these environments may have different-different host addresses. Let’s have a look at a few of those. During the development phase, we usually run our application with http://localhost:8080/features/..., where our host is localhost:8080 During the testing phase, the same application can be run on http://www.consumerapps.com/features/..., where our host is www.consumerapps.com Now, what if we want to get the host name in log file for an audit purpose. We cannot go and hard code  it in the application, as it may change based on the environment on which application is running. In ASP.NET Core 3.1, it can be easily achieved using HttpContext . First change we have to do is, to register IHttpContextAccessor as a singleton: services.AddSingleton<IHttpConte

Introduction to Application State Application state provides a way to store in-memory data, which are smaller in size. It includes both global and user-specific data. Such data can be used across application and can be used by all users. Prior to ASP.NET Core 1.0 also there were Application and Session state options available to store such sort of data. Ways of managing Application State? Now question is, which state storage provider is to be used and when? It is influenced by variety of factors: Size of data Format of data Duration to persist data Sensitivity of data, etc. Based on your answers, Application State can be managed in variety of ways like: HTTPContext Cookies Session Querystring and Post Cache Other options (EF, Azure Table Storage, etc.) As part of ASP.NET Core 1.0 release, there is change in HTTPContext object. Hence I’ll emphasis on that. HTTPContext: Items collection of HTTPContext is used to store data which is required onl