An Overview of the React Ecosystem

Well, here we go! This is the inaugural installment of The Monsters Weekly, where we take you up, down through and over all the aspects of ASP.NET Core and Core MVC. In our first episode, we're covering the startup.cs class and what happens as our application loads.
Not sure where to start in ASP.NET Core? Well, in startup.cs, of course. We run the file top-to-bottom covering some basic configuration, dependency injection, browser link, database error pages, service configuration and the Julie Lerman of Canada. This is an intro - we cover a lot of ground at 30,000 feet, but don't worry, we'll be breaking it down in the weeks ahead.
Be sure to follow the Monsters on Twitter and check out the blog for related posts.
The production code for this video is VG.
Can fix the video and make it bigger so it fits in the video player? Tough to see the demo.
I noticed inside of your Configure method when you were getting the database context, you first got the IServiceScopeFactory before pulling back your ApplicationDbContext so that you could call the Migrate method. Was there a reason for doing it this way? In code that I have written, I have just directly made a call in the Configure method that puts this all into one line like so "app.ApplicationServices.GetRequiredService<ApplicationDbContext>();". This there a condition where doing it the way you have it is better than just directly getting it from the ApplicationServices? Also, I can relate to your empty catch on the Migrate call. One thing I have done since I noticed I got this when not using a SQL backed database (like the InMemoryDatabase) is I made a very specific catch statement to only ignore the case when the Migrate method wasn't supported, but let's me know if I get something else. What I have done is created a catch block like so "catch (InvalidOperationException e) when (e.Message == "No service for type 'Microsoft.Data.Entity.Migrations.IMigrator' has been registered.") {}" which is still empty, but at least only ignores exceptions around the IMigrator not being implemented (I know, it is very English specific, I could probably clean it up a bit but it works for projects I'm writing at the moment).
Nice series, keep up the good work.
@Oliver:Sorry about that...we're still learning the ropes. We hope we have it figured out for future episodes!
@Stokes:Thanks for the questions and comments.
Here we are just looking into the default startup, so there's no specific reason why that code is there, other than someone responsible for creating the template thought it should be like so. We'll be doing a number of posts on services and DI in general, and we'll try to explore that a little deeper.
And, yeah, UGH on those empty try...catches, eh? Thanks for sharing your approach.
Cheers!
@Stokes @CanadianJames
I believe this pattern came out of the EF team's need to have a proper "seed" method/process.
You shouldn't apply a using statement on a dbcontext whose lifetime is owned by DI.
Getting the context via a service scope is a safter approach.
https://github.com/aspnet/EntityFramework/issues/3070#issuecomment-142752126
Great series BTW...
Great Start.cs to the series!
Unwatchable on a smaller tablet. Don't forget to zoom. :)
Interesting Russian Doll analogy. I don't like Russian Dolls. They're so full of themselves.
I have VS 2013 and my MVC template is quite different...
Is there a way for me to see this as displayed without upgrading to the latest VS?
Sorry, didn't sign in first; I am BrianS!
It is hard to see
This conversation has been locked by the site admins. No new comments can be made.