Skip to main content

Posts

Showing posts with the label ASP.NET Core 2.0

Configure vs ConfigureServices in ASP.NET Core 2.0

Both words sound similar but there is a very thin line which differentiates these two. Let’s have a look at key differences between these two methods. Configure ConfigureServices Main purpose Does all the initial setup Does service configurations Default Location Resides in Startup.cs Resides in Startup.cs Execution sequence Hits prior to ConfigureServices Hits after Configure Ordering Order of steps mentioned in this method matters Order of the statements written to add services doesn’t matter HTTP request HTTP request first hits in this method                                  - Parameters Configure(IApplicationBuilder app, IHostingEnvironment env) ConfigureServices(IServiceCollection services) Middleware Setting up all the middleware are done in this method    

All About Pages In ASP.NET Core 2.0

I hope while working on Razor pages, one thing you have noticed is @page.  Let’s say you added a new page (named Sample.cshtml) in Visual Studio Code in your existing application. Once the page is added, we will get an empty editor window on the right side pane where we are going to write code for our page. In order to make things simple, I’m adding very simple HTML code:        <h1> Welcome to my page </h1>          Now, save the application and run. Oops 404! Any idea why we end up looking at such a weird page? Well, @page is holding this magic. Basically, none of the Razor pages will be considered as pages until and unless they are decorated as @page in the very first line. But as soon as we append the @page in our newly added Sample.cshtml page, things will work as expected. Next, we will quickly look at a few of the files which are added by default under a Pages folder with some pre-specified lines of code.

All About Appsettings.json in ASP.NET Core 2.0

As most of you are aware that in ASP.Net Core, we don't have anything called Web.Config, where we use to write our connection strings or application specific settings. Rather, here we have the file named appsettings.json to store similar sort of information. There are few very common use cases where we need to maintain multiple appsettings.json file in a single solution. For example: Multiple application settings per application - When we need to maintain different-different application specific settings based on the application environment. Say, one can have one type of application settings for Development, another type of application settings for Production, another one for Staging, and so on. Needless to mention, all the appsettings file will have different names. To implement inheritance – If there are some common settings between multiple application settings file, in that case developer can come up with a base application settings file and on top of that specific file