1
00:00:00,210 --> 00:00:05,210
The startup class is just a plain class,
no base class inheritance, or

2
00:00:05,210 --> 00:00:07,400
interface implementations.

3
00:00:07,400 --> 00:00:11,942
It includes two specially named methods,

4
00:00:11,942 --> 00:00:16,120
configure services, and configure.

5
00:00:16,120 --> 00:00:19,930
Our host will look for and call these
methods when our app is starting up.

6
00:00:21,710 --> 00:00:25,980
The constructor is being used to
set up our apps configuration.

7
00:00:25,980 --> 00:00:30,680
App configuration is no longer
dependent upon the web config file.

8
00:00:30,680 --> 00:00:35,380
Instead app configuration data,
stored as key value pairs,

9
00:00:35,380 --> 00:00:38,730
can be read from a variety
of file formats.

10
00:00:38,730 --> 00:00:43,500
We're adding three configuration
data sources, two JSON files and

11
00:00:43,500 --> 00:00:45,390
environment variables.

12
00:00:45,390 --> 00:00:48,450
The second JSON file is
being dynamically named

13
00:00:48,450 --> 00:00:52,120
by including the environment
name before the file extension.

14
00:00:52,120 --> 00:00:55,320
This allows us to customized
the configuration data for

15
00:00:55,320 --> 00:00:58,100
each environment that we need to support.

16
00:00:58,100 --> 00:01:03,280
The configuration data sources are loaded
in the order that they're defined.

17
00:01:03,280 --> 00:01:06,890
If a key is the same as a key
that has already been loaded,

18
00:01:06,890 --> 00:01:10,070
then the new value will
replace the old value.

19
00:01:10,070 --> 00:01:13,760
This allows our environment
specific configuration settings

20
00:01:13,760 --> 00:01:15,760
to override the base settings.

21
00:01:15,760 --> 00:01:20,420
And our environment variables to
override any of the JSON settings.

22
00:01:20,420 --> 00:01:24,560
Environment variables give us a convenient
way to provide sensitive configuration

23
00:01:24,560 --> 00:01:28,822
data, like API keys or
database connection strings,

24
00:01:28,822 --> 00:01:33,470
at runtime without having to
write those values to a file.

25
00:01:33,470 --> 00:01:36,900
Instead, you define those
settings in your environment.

26
00:01:36,900 --> 00:01:40,180
For instance,
in Microsoft's Azure Cloud Service,

27
00:01:40,180 --> 00:01:42,972
you can define environment variables for
your web apps.

28
00:01:42,972 --> 00:01:47,850
The ConfigureServices method is used to
configure any services that should be

29
00:01:47,850 --> 00:01:52,960
made available to your app using the
built-in dependency injection container.

30
00:01:52,960 --> 00:01:57,829
Here, we're calling the AddMVC extension
method to add the services that

31
00:01:57,829 --> 00:01:59,660
MVC requires.

32
00:01:59,660 --> 00:02:05,340
The configure method is used to configure
the HTTP request pipeline for our app.

33
00:02:05,340 --> 00:02:09,600
Our request pipeline is
composed using middleware.

34
00:02:09,600 --> 00:02:14,860
Each app.use method call that we see
here represents a middleware component

35
00:02:14,860 --> 00:02:17,230
that is being added to the pipeline.

36
00:02:17,230 --> 00:02:21,450
Earlier we saw a very basic example
of creating our own middleware.

37
00:02:21,450 --> 00:02:24,810
Luckily, we don't need to create
all of our own middleware.

38
00:02:24,810 --> 00:02:29,410
Each of these middleware components
is provided by ASP.NET Core,

39
00:02:29,410 --> 00:02:32,780
the developer exception page,
browser link,

40
00:02:32,780 --> 00:02:37,560
the exception handler,
static files and in MVC.

41
00:02:39,090 --> 00:02:42,720
Notice that we're checking if
the current environment is development.

42
00:02:42,720 --> 00:02:46,228
And if it is, then we add
the developer exception page and

43
00:02:46,228 --> 00:02:48,670
browser link components.

44
00:02:48,670 --> 00:02:50,780
If it isn't the development environment,

45
00:02:50,780 --> 00:02:53,780
then we add the exception
handler component.

46
00:02:53,780 --> 00:02:58,780
Each middleware component gets a chance
to perform asynchronous logic on the HTTP

47
00:02:58,780 --> 00:03:04,120
context and optionally invoke
the next middleware in the sequence,

48
00:03:04,120 --> 00:03:06,630
or terminate the requests directly.

49
00:03:06,630 --> 00:03:11,170
For example, if the static files component
detects that the request is for a static

50
00:03:11,170 --> 00:03:16,040
file, then the component will write
the file contents to the request body and

51
00:03:16,040 --> 00:03:21,600
terminate the request, preventing
the MVC component from being invoked.

52
00:03:21,600 --> 00:03:23,350
Let's try an experiment.

53
00:03:23,350 --> 00:03:28,544
I'll comment out all of our request
pipeline configuration and run our app.

54
00:03:38,900 --> 00:03:41,850
And we get a blank page.

55
00:03:41,850 --> 00:03:46,506
If we open Chrome's dev tools and select
the Network tab and reload our page,

56
00:03:49,335 --> 00:03:54,190
We can see that we're getting
a 404 Not Found HTTP status code.

57
00:03:55,630 --> 00:03:58,680
No error page, just the status code.

58
00:03:58,680 --> 00:04:04,710
This demonstrates that ASP.NET core uses a
build up approach to web app development.

59
00:04:04,710 --> 00:04:08,220
Which is in contrast to
earlier versions of ASP.NET,

60
00:04:08,220 --> 00:04:10,890
which used a tear down approach.

61
00:04:10,890 --> 00:04:15,130
With the tear down approach,
ASP.NET provided a default feature set for

62
00:04:15,130 --> 00:04:16,130
your app.

63
00:04:16,130 --> 00:04:20,760
And if you didn't need or want one of
those features, you had to disable it.

64
00:04:20,760 --> 00:04:22,780
Well, if you could it all.

65
00:04:22,780 --> 00:04:26,610
With ASP.NET Core,
nothing is added by default.

66
00:04:26,610 --> 00:04:30,173
You need to explicitly add the features
that you need for your app.

67
00:04:36,403 --> 00:04:40,409
Let's add the MVC middleware
component back and run our app again.

68
00:04:47,499 --> 00:04:50,668
Now we're getting the content for
our default route, but

69
00:04:50,668 --> 00:04:53,201
it appears our styles and
images are missing.

70
00:04:57,586 --> 00:04:58,907
In the Network tab,

71
00:04:58,907 --> 00:05:03,748
we can see that all of those resources
are returning a 404 status code.

72
00:05:03,748 --> 00:05:10,010
This is happening because by default,
ASP.NET Core won't serve static files.

73
00:05:10,010 --> 00:05:13,997
If your app uses static files,
you need to explicitly add support for

74
00:05:13,997 --> 00:05:18,688
static files by adding the static files
middleware component to your pipeline.

75
00:05:28,348 --> 00:05:32,116
It's worth noting that if our app
didn't need support for static files,

76
00:05:32,116 --> 00:05:35,480
we could remove that NuGet package
from our project.json file.

77
00:05:37,640 --> 00:05:41,057
This would reduce the overall
deployment footprint for our app.

78
00:05:46,902 --> 00:05:49,553
Let's add back support for
static files and

79
00:05:49,553 --> 00:05:53,430
look at one more example of
ASP.NET Core's build up approach.

80
00:05:59,880 --> 00:06:06,012
We'll throw an exception in our
HomeController's index action method and

81
00:06:06,012 --> 00:06:10,433
run the app without debugging
by pressing Ctrl+F5.

82
00:06:17,134 --> 00:06:20,317
And again, we don't get any content.

83
00:06:25,493 --> 00:06:27,637
If we reload the page in the Network tab,

84
00:06:27,637 --> 00:06:31,689
we'll see that we're getting a 500
Internal Server Error Status Code.

85
00:06:37,405 --> 00:06:41,965
By default, ASP.NET Core doesn't
provide any exception handling.

86
00:06:41,965 --> 00:06:46,353
But that can easily be added by adding
the developer exception page middleware

87
00:06:46,353 --> 00:06:47,093
component.

88
00:06:50,534 --> 00:06:55,044
Now when we run our app,
we get a nicely formatted exception page.

89
00:07:07,898 --> 00:07:12,702
Or if we're running in production, we
can add the exception handler component,

90
00:07:12,702 --> 00:07:14,870
which will log the exception.

91
00:07:14,870 --> 00:07:19,468
Reset the request path through our
error route and re-execute the request.

92
00:07:24,277 --> 00:07:27,420
Now we get a user friendly error page.

93
00:07:27,420 --> 00:07:32,152
The startup class gives you an idea
of how much ASP.NET Core differs from

94
00:07:32,152 --> 00:07:34,360
previous versions of ASP.NET.

95
00:07:34,360 --> 00:07:38,610
In the next video, we'll take a look
at MVC controllers and views,

96
00:07:38,610 --> 00:07:42,850
which have changed from previous versions
of MVC, but not to the same degree.