In the past years, we could notice major changes of the fundamental concepts software development relies on: a faster pace of innovation and releases, the focus on cross-device development strategies and the collaboration within the community of developers that is based more and more on open source. In addition to this, there is an increasing need for developers to maintain older applications up to date and to integrate easily new technologies within them. Microsoft tried to find an answer for all these demands by establishing a new trend of its well-known framework .NET, a trend that is referred to as vNext.
During the TechEd conference of this year, Microsoft unveiled the next version of .NET framework called vNext, which came out as a solution for fulfilling all the current needs of the developers. More precisely, Microsoft wants all these changes to bring the way applications are implemented to a totally new level.
vNext sums up several changes to the .NET platform. These changes consist of: high degree of modularization, an easier transition of the applications to the cloud, enabling more contributions to the framework by open source code, a faster development cycle, free choice of programming tools, and last but not least, the option to selectthe platform where applications can be run. Given all these premises, the main questions that one would address are how is vNext reflected in software development process and what features does it bring to the tools?
One of the major changes to .NET platform is the total modularity. Until now it was required to install the global .NET framework on the target machine in order to run your applications. This involved more storage size on the disk. Moreover, there are problems when we want to run an application under a different .NET version than the current one. This implies changing the global version of the framework on the system and it might cause other applications to break. All of these issues request more time for setting up the applications on a particular environment.
vNext relies on features organized as packages. As a result, all the dependencies of a solution (including the framework, Common Language Runtime) are built as Nuget packages that are deployed together with the application. Moreover, in order to optimize resources for the cloud, Microsoft has decided to split the current framework into 2 flavors: one for on-premise solutions and one for cloud applications. The cloud optimized framework contains only the resources that are strictly required from the deployment of an application on cloud and nothing more. Therefore, this flavor of the framework will not contain references for Windows Forms or Windows Presentation Foundation, for example.
The modularization of the framework is visible in the next version of Visual Studio IDE that provides a new way for structuring a solution. References are not listed in linear form anymore; from now on, they are structured in a tree-like form so that they provide a more clear view of the dependencies, regardless if they are Nuget packages or class libraries. Furthermore, if we go for a Web application, the first thing that can be observed in the IDE is the absence of Web.config file. On the other hand, there has been added a new file named project.json that is included for any type of project. The project.json file plays an essential role when configuring vNext applications. This contains a list of project dependencies, definitions for custom command or settings for several configurations. Visual Studio provides Intellisense support for editing this file and for searching references. Moreover, the dependencies that are specified within the file are synchronized in real time with the references tree from Solution Explorer.
"dependencies": {
"EntityFramework.SqlServer": "7.0.0",
"Microsoft.AspNet.Mvc": "6.0.0",
"Microsoft.AspNet.Identity.EntityFramework": "3.0.0",
"Microsoft.AspNet.Identity.Authentication": "3.0.0",
"Microsoft.AspNet.Security.Cookies": "1.0.0",
"Microsoft.AspNet.Server.IIS": "1.0.0-*",
"Microsoft.AspNet.Server.WebListener": "1.0.0-*",
"Microsoft.AspNet.StaticFiles": "1.0.0",
"Microsoft.Framework.ConfigurationModel.Json": "1.0.0",
"Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0-*",
"UserManagement.BusinessLogic": ""
},
"commands": {
"web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls http://localhost:5000"
},
"configurations": {
"net451" : { },
"k10" : { }
}The json file is a very powerful resource. A developer can choose between a particular version of a package or the last version. This proves to be extremely useful because one can load in the project the latest versions of the packages that often contain fixes for bugs from previous versions. In addition to this, if bugs form open source packages are detected, the packages can be cloned on the local system and they can be fixed. Later on, their package references can be updated to point to the newest version (the one that contains the fixes).
Besides specifying dependencies, the project.json file can be used for the complete recovery of a solution in Visual Studio, in case that some .proj file have been deleted accidentally from the application.
The future trend of .NET framework puts a great emphasis on Dependency Injection concept which becomes a built in mechanism for setting up applications. This configuration is performed in Startup class within Configure method that is shown below:
public void Configure(IBuilder app)
{
// Setup configuration sources
var configuration = new Configuration();
configuration.AddJsonFile("config.json");
configuration.AddEnvironmentVariables();
string connString = configuration.Get("Data:DefaultConnection:ConnectionString");
// Set up application services
app.UseServices(services =>
{
// Add EF services to the services container
services.AddEntityFramework().AddSqlServer();
// Configure DbContext
services.SetupOptions<DbContextOptions>(options =>
{ options.UseSqlServer(configuration.Get("Data:DefaultConnection:ConnectionString"));
});
// Add Identity services to the services container
services.AddIdentity<ApplicationUser>()
.AddEntityFramework<ApplicationUser, ApplicationDbContext>()
.AddHttpSignIn();
// Add MVC services to the services container
services.AddMvc();
});
// Add MVC to the request pipeline
app.UseMvc(routes =>
{
routes.MapRoute(
name: "default",
template: "{controller}/{action}/{id?}",
defaults: new { controller = "Home", action = "Index" });
routes.MapRoute(
name: "api",
template: "{controller}/{id?}");
});
}One can notice that there is an enhanced control which allows explicit setting for the features that are required. It is very important for the required services to be registered in the json config file.
In the previous section, we mentioned that Web.config file is not present in Web applications. This is due to the fact that developers have the opportunity to select their own configuration mode: specified by xml, json or ini files. And of course, this is done in Configure method, by setting the chosen file as a reference within configuration object.
In this method we can specify also if we want to include Entity Framework or MVC in the project, for example. This is done by calling methods like AddEntityFramework or AddMvc. Moreover, we can set several parameters of the included features (by calling methods like UseEntityFramework or UseMvc). Such an example would be calling UseMvc for configuring MVC routes.
Even though there are 3rd party containers for Dependency Injection in .NET (Autofac, NInject), from now on it is provided also built in support for this. The built in mechanism allows a much better control of the features that are used. If we want to use a 3rd party container for Dependency Injection, we can do this by specifying particular dependencies in project.json file, followed by the explicit setting of parameters in Configure method.
Another important advantage that is included in vNext applications (and not only) is the dynamic compiler. The new platform of .NET compilers, which is codenamed Roslyn, provides an open source API. If developers have access to the API of .NET compilers, they will create more easily applications for code analysis, custom diagnostics or even optimized versions of the compilers.
Since the dynamic compilation is performed in the system memory and does not involve rewriting assemblies on disk, it brings a performance boost to the execution of an application. Therefore, once the application process is started, one can edit the source code and after saving the edited file(s) will see the changes in real time. It is important to notice that there is no need for rebuilding the software (process that takes up time and resources) and the only thing we need is to save the modified sources. For instance, if someone implements a Web application, he only needs to edit the source code and press F5 in the browser to see his changes applied there. This enhancement results in a faster cycle for both software implementation and bug fixing and it increases a lot the productivity of all developers.
vNext comes up with many more other innovations. Among the novelties brought by vNext there are the merging of Web Pages, MVC and Web API within a single model and an increased support for Mono (used for running .NET applications on other platforms). The high degree of modularization and the enhanced control facilitate the deployment and maintenance of the applications on each environment. The software will be able to run even on portable drives like memory sticks. Even more, multiple versions of the same application will be able to run simultaneously.
Last but not least, vNext represents a new era for .NET framework, an era where developers can choose freely their own tools and operating systems. Since it is open-source, the entire community can see the latest updates of vNext; moreover, its development is highly influenced by a continuous feedback process. The future version of .NET framework will definitely revolutionize the entire implementation phase. We are looking forward for it to be officially released in order to explore all the features that it provides.
by Ovidiu Mățan
by Mircea Vădan
