Getting Started With ASP.Net 5 Part: 2

Hi Friends.

Please go through my first article of the series first:
In this section, we'll delve further into the new ASP.NET 5 project. When you take a closer look at the ASP.NET 5 project, you will see that there are many things that are carry forwarded, like Model, View, Controller, clean separation of concerns and may more. But, there are also some significant changes around ASP.NET 5. Now, the root of the website is no longer the root of the project. By default, the root will be the WWWroot folder. The reason for that is to maintain the clean separation between the files in the web server retrieved and sent to the client and the files containing the logic and configuration. Static files like JavaScript, CSS and HTML can live in the WWWroot folder.



Now, let's assume that assume when I run the app and try to see the image that I have placed in the My Imgaes folder, it will give me a 404 error.



On the other hand, if I go ahead and add the same folder to the WWWroot folder and try to navigate to it then it will produce me the following result:





So, the point is, all the static files are served by the root folder and the logical stuff is served by the project space as we initially saw when I added the controller to the controller's folder and it took effect. One more thing you might have observed is that there is no web.config file now in the solution. Also, there is no Global.asax file now, however it is replaced by the startup.cs file. But, we'll see this later. First let's see the project.json file. This file now manages many aspects of the website.



The first thing you will notice here is that the root folder is set to WWWroot. So, this is what is telling the website that this is the root folder. So begin the show from here. This you can change as well or rename if you like. Now, this configuration file is in JSON format. This is also telling the ASP.NET runtime what dependencies the project will need. In this new ASP.NET 5 system there is a new way to manage dependencies. There is no need to reference assemblies and store the lists of referenced assemblies in the project file. Instead, we refer to the Nuget packages as dependencies and these dependencies are listed in our project.json file. Now, there are a couple of reasons for this change. One reason is to simplify the dependency management. Another good reason for this is that ASP.NET is moving away from Visual Studio dependency. So, in the future I can use any text editor to build the ASP.NET App.

Now, these dependencies can be both the ways. One way that we used already is shown below in the screen shot.





Now, the UI of this is also changed. Initially we used to have a Modal window. Now, this is more like a complete screen giving wider visibility. I can also see the installed templates as in the following:



Also, I still have the flexibility of a different Nuget source.



The second option is via a project.json file. Let's assume I am planning to install some custom package. Then I can do that as shown below as well.



However, whatever package you install, you can find its references under “References“. Below, in the screen shot, you can see that there are two versions of runtime here. The first one is the core version and the second one is the cloud-optimized version.



Now, let's collapse it and drill into it.



Now, here the dependency management system will keep your assemblies in a nice tree structure. So, it nicely tells which package are dependent on which package.



Now, as far as the framework and runtime is concerned, as you can see below in the screen shot, I have both frameworks listed here.



So, whenever I am building the solution I am building against both of these frameworks. By building against both I am actually ensuring that it will work well against both frameworks. This also means that whenever I am switching platforms my code won't break.

But, let's go ahead and break something here. You remember in the last segment I created a new controller with Notepad. Now, let's modify it and refresh the app.



So, as you can see, it says that GetCallingAssembly() (part of System.Reflection) is not supported in the cloud-optimized version. But, let's assume I overlooked this error and refreshed the app. So, it actually produced the desired result for me.



But, when I explicitly build the project and check the output window, it gave me the following error message.



So, we are building with an error but the application is working fine with the full-blown CLR. Now, if you have decided that you don't want the Core CLR version then you can just comment out the Core CLR section in the project.json file as shown below in the screen shot.



Now, as soon as I commented out the preceding section, the following references were refreshed automatically.



Now, when I build the app it will build fine.



But assume you want the other, in other words you would like to keep the cloud-optimized version also and the build should also succeed. For this scenario I need to refer to the conditional build as shown below.



With this I would like to wrap up this second session of ASP.NET 5 New Features. We will delve further in the future series. Until then stay tuned ad Happy Coding.


Similar Articles