Introduction
This article will describe a new concept, which is introduced in ASP.NET MVC 6.
ASP.NET 6 introduces a few concepts, which 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, the developers can now work with specific files and the folders devoted to the specific purposes.
New Folder Structure
Startup.cs
In 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 MVC 6. This is very good news because creating the configuration is a huge pain for the developers.
Microsoft is now supporting JSON, XML and INI files for configuration and those you can easily create your own. In MVC 6, “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 MVC 5 are writable (IConfigurationSource), which means during the startup or first access to your config, you can detect what needs to be updated to support your new version, make the updates in the 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 the major version to the 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 the database connection string. In web.config file, we use <ConnectionString> to configure the connection string. 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. .SIN in the past is replaced with global.json file now. By default, the projects and sdk are two sections mentioned in the file.
The 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 ofglobal.json defines the version of dnx.exe from one of the runtimes, which you installed.
It's important to understand about the "projects" part of global.json, which will be scanned by all the 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 MVC 6 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 user's Browser should be stored inside this folder.
The code files should be placed outside wwwroot, including C# files and Razor views. Having a wwwroot folder keeps a clean separation between the code files and static files. It brings clarity to the items, which will be sent to the Server and the items, which should remain on the dev machine.
Dependency Folder (Client Side Dependency Management)
In this folder, we can find two more folders, which are-
- 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, 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.