Introduction
This article will describe the new concept which is introduced in ASP.NET 5.
ASP.NET 5 introduces a few concepts that didn’t exist in the previous versions of ASP.NET. Rather than working with web.config, packages.config, and a variety of project properties stored in the .csproj/.vbproj file, developers can now work with specific files and folders devoted to specific purposes.
New Folder Structure
Startup.cs
Previous versions of ASP.NET for configuration stuff we had to use web.config file or *.config files. Good to hear web.config is gone now. 
. Configuration itself can now be configured in ASP.NET 5. This is very good news because creating the configuration is a huge pain for developers.
Microsoft is now supporting JSON, XML and INI files for configuration and those you can easily create your own. In ASP.NET 5, “configuration” will mostly be done with code found in your Startup.cs file, anything that you want to enable in your application is done in this class. Any package that is installed in your application, you will need to opt-in to use it in your Startup.cs file. In some cases however, a configuration file might need to be updated/transformed… this could be due to an upgrade of a package. The good news is that the configuration sources in ASP.NET 5 are writable (IConfigurationSource) which means during startup or first access to your config, you could detect what needs to be updated to support your new version, make the updates in code and commit (ICommitableConfigurationSource) the changes.
public Startup(IHostingEnvironment env)
{
var builder = new ConfigurationBuilder()
.AddJsonFile("appsettings.json")
.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true);
if (env.IsDevelopment())
{
builder.AddUserSecrets();
builder.AddApplicationInsightsSettings(developerMode: true);
}
builder.AddEnvironmentVariables();
Configuration = builder.Build();
}
................
project.json
project.json is another json file. It is used to define the projects' server side dependencies and other project specific information such as usersecretsid to identify the uniqueness of your application, version of the application and so on.
Server side dependencies refer to an installed NuGet package or to another project. Each of the entry package versions can be specified specifically. This is the best feature it has provided to avoid pulling major version to minor version update. This was a huge pain while deploying the project.
{
"userSecretsId": "aspnet5-WebApplication1-8479b9ce-7b8f-4402-9616-0843bc642f09",
"version": "1.0.0-*",
"compilationOptions": {
"emitEntryPoint": true
},
"dependencies": {
"EntityFramework.Commands": "7.0.0-rc1-final",
"EntityFramework.MicrosoftSqlServer": "7.0.0-rc1-final",
"Microsoft.AspNet.Authentication.Cookies": "1.0.0-rc1-final",
"Microsoft.AspNet.Diagnostics.Entity": "7.0.0-rc1-final",
"Microsoft.AspNet.Identity.EntityFramework": "3.0.0-rc1-final",
"Microsoft.AspNet.IISPlatformHandler": "1.0.0-rc1-final",
"Microsoft.AspNet.Mvc": "6.0.0-rc1-final",
"Microsoft.AspNet.Mvc.TagHelpers": "6.0.0-rc1-final",
"Microsoft.AspNet.Server.Kestrel": "1.0.0-rc1-final",
"Microsoft.AspNet.StaticFiles": "1.0.0-rc1-final",
"Microsoft.AspNet.Tooling.Razor": "1.0.0-rc1-final",
"Microsoft.Extensions.CodeGenerators.Mvc": "1.0.0-rc1-final",
"Microsoft.Extensions.Configuration.FileProviderExtensions" : "1.0.0-rc1-final",
"Microsoft.Extensions.Configuration.Json": "1.0.0-rc1-final",
"Microsoft.Extensions.Configuration.UserSecrets": "1.0.0-rc1-final",
"Microsoft.Extensions.Logging": "1.0.0-rc1-final",
"Microsoft.Extensions.Logging.Console": "1.0.0-rc1-final",
"Microsoft.Extensions.Logging.Debug": "1.0.0-rc1-final",
"Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0-rc1-final"
},
"commands": {
"web": "Microsoft.AspNet.Server.Kestrel",
"ef": "EntityFramework.Commands"
},
"frameworks": {
"dnx451": { },
"dnxcore50": { }
},
"exclude": [
"wwwroot",
"node_modules"
],
"publishExclude": [
"**.user",
"**.vspscc"
],
"scripts": {
"prepublish": [ "npm install", "bower install", "gulp clean", "gulp min" ]
}
}
appsettings.json
As we see, web.config is replaced with JSON files, appsettings.json file json file in which we can mention database connection string. In web.config file, we use <ConnectionString> to configure the connection string in here it will create in json format string to mention the connection string.
{
"ApplicationInsights": {
"InstrumentationKey": ""
},
"Data": {
"DefaultConnection": {
"ConnectionString":
"Server=(localdb)\\mssqllocaldb;Database=aspnet5-MVC6VNext-d6155af6-412a-4c71-8378-ae3c4ddbe2ed;
Trusted_Connection=True;MultipleActiveResultSets=true"
}
},
"Logging": {
"IncludeScopes": false,
"LogLevel": {
"Default": "Verbose",
"System": "Information",
"Microsoft": "Information"
}
}
}
global.json
global.json is used to configure the solution. .sln in the past is replaced with global.json file now. By default, projects and sdk are two sections mentioned in the file.
version is important because your computer can have multiple versions of dnx.exe. You can see %USERPROFILE%\.dnx\runtimes using this command. The multiple version of dnx is installed. The "sdk" part of global.json defines the version of dnx.exe from one of the runtimes which you installed.
It's important to understand about "projects" part of global.json that it will be scanned all sibling folders on any level under every directory.
{
"projects": [ "src", "test" ],
"sdk": {
"version": "1.0.0-rc1-update1"
}
}
wwwroot Folder
The wwwroot folder is new in ASP.NET 5 to store all of the static files in your project. Any files including HTML files, CSS files, image files, and JavaScript files which are sent to the users browser should be stored inside this folder.
Code files should be placed outside of wwwroot including C# files and Razor views. Having a wwwroot folder keeps a clean separation between code files and static files, it brings clarity to the items that will be sent to the server and the items that should remain on the dev machine.
Dependency Folder (Client Side Dependency Management)
In this folder, we can find two more folders:
- Bower
Today, most of the web applications are using JavaScript and CSS framework such as jquery, bootstrap, angularJs, etc. Front-end developers working with other frameworks are more likely to use a system called Bower, which is a package manager specifically for managing client-side libraries which are located on GitHub. Bower was developed by the team at Twitter (who also produced Bootstrap), and is a Node.js application.
- NPM
Previous versions of ASP.NET included a framework for minifying and bundling client-side script and style sheets files - System.Web.Optimization. As its name implies, it is dependent on System.Web, and therefore hasn't been included as part of ASP.NET 5. Rather than reinventing the wheel a second time, the ASP.NET team decided to incorporate a popular Node.js application to perform these tasks - Gulp.
Gulp is variously described as a build system or a task runner that you can use to automate the copying of files, bundling and minification, compiling LESS or SASS to CSS, etc. as part of your build. There are other Node.js task runners available, but this particular tool has been chosen by the ASP.NET team as one of the options to include in Visual Studio. It uses streams when handling files, which is a lot more efficient than creating temporary copies. You obtain Gulp using npm - a package manager bundled with Node.js.
References (Server Side Dependency Management)
The References folder, shown within Solution Explorer in Visual Studio, details the server-side references for the project. It should be familiar to ASP.NET developers, but it has been modified to differentiate between references for different framework targets, such as the full DNX 4.5.1 vs. DNX Core 5.0. Within each framework target, you will find individual references, with icons indicating whether the reference is to an assembly, a NuGet package, or a project. These dependencies are checked at compile time, with missing dependencies downloaded from the configured NuGet package source.
