To understand the reasons for this change, I think a bit of historical context and clarification is needed. Throughout the past 14 years Microsoft has pretty much maintained backwards compatibility between one version of ASP.Net to the next. You could take a solution built on one version of .Net and run it on any version of .Net that came after that. Customers have been free to run DNN on whatever the latest version of ASP.Net was available and it was not necessary for DNN to make any significant changes to ensure we continued to work with each new .Net release (often just some web.config changes).
This was true with one exception - ASP.Net 1.1 solutions built in VS2003 were not compatible with ASP.Net 2.0 and VS2005. When ASP.Net 2.0 first came out it only supported the WSP model for website development. It was only in a subsequent update when they added the WAP project model back to ASP.Net. In order for DNN to compile and work in ASP.Net 2.0 it needed to be repackaged and rebuilt for VS2005. In addition, ASP.Net 2.0 added a lot of new features which were desperately needed by DNN and that we really wanted to leverage in the platform.
To address this issue, we created DNN 4 which was for the most part exactly the same as DNN 3 but used the new ASP.Net 2.0 features and the VS2005 solution and project formats. We maintained DNN 3 & 4 in parallel for quite a long while so that customers were free to move forward when they were ready. They were not stuck on ASP.Net 1.1 while waiting on DNN to update the platform. Some customers were not ready to move to ASP.Net 2.0 and they were not forced to upgrade because we continued to maintain DNN 3. Customers were free to move forward at a pace that made sense to their business.
Since we released DNN 4, we have been slow to adopt the latest ASP.Net versions as a requirement to run DNN. We wanted to ensure that only after a large majority of customers had moved to the later versions did we adopt a version as the baseline requirement for DNN. Even today we are still built on ASP.Net 4.0 which was released in April of 2010 (we expect to increment the minimum version to 4.5.2 with the release of DNN 7.5.0)
Fast forward to today (10 years after the introduction of ASP.Net 2.0 and DNN 4) and we have Microsoft on the verge of releasing ASP.Net 5. This version of ASP.Net is not compatible with previous versions. ASP.Net 5 addresses some very real pain points for many developers in the .Net ecosystem. In fact ASP.Net has been losing market share for several years to competing platforms like Node, PHP and Ruby because they were not viewed as a modern or relevant platform for the current generation of developers. There were many architectural issues that MS tried to address with ASP.Net MVC, but in the end there was only so much that the MVC team could accomplish due to the nature of the .Net and ASP.Net frameworks on which it was built. ASP.Net 5 is a complete rebuild of the ASP.Net platform to utilize more modern development techniques than those that were around when the Y2K bug was still a thing people talked about.
Given the direction that MS is going and DNN's history of providing customers the flexibility of moving forward as quickly or as slowly as they choose, it is necessary for us to develop a version of DNN to run on ASP.Net 5. Like we did with DNN 3 & 4, we will continue to maintain a version of DNN (DNN 7.x) that runs on the current ASP.Net stack, but we will also have a version of DNN for customers that want to move forward with Microsoft (DNN neXt).
In addition to creating a dual track it will be necessary to create some bridging technology and tooling which can help customers make the transition to DNN neXt when they are ready. The first step in this process is to create richer support for Single Page Application (SPA) style development. In DNN 7.5 we will include a SPA module type which makes it easy to fully embrace a more browser centric approach to building modules. In 7.5 we will also include an MVC module type which allows you to build modules using the current ASP.Net MVC framework. Both of these efforts will make it easy for people to build modules which will require minimal effort to port to DNN neXt.
Part of our DNN neXt development effort will be focused on creating tools and processes to enable migration of existing sites to the new platform. This is still very much in the theoretical realm as we have not begun coding of DNN neXt yet. As we begin development, then we'll also start looking at what the migration process will look like and we'll look at how we make it as easy as possible given the constraints of running on two architecturally different versions of the ASP.Net stack.