DNN 8 is a major leap forward for DNN. There are many new features like MVC and SPA module development support, OAuth2 server support, a new HTML Editor, the Dynamic Content Creator and a new default skin and template. In addition to all of these new features, we are also updating the DNN architecture. We are working to enable the creation of custom DNN distributions, to improve platform performance and to get rid of some outdated portions of the platform that are holding us back.
As we have progressed on DNN 8 development, we have been faced with some tough choices. Some of the architectural and performance improvements that are needed will require us to break backwards compatibility. In speaking with many community members on these issues, we have consistently heard the same message – do what is right to move the platform forward. In most cases these changes will have no impact on your use of DNN. We are spending a lot of effort to ensure that the core platform features continue to work properly even after these changes. We are also working with the Evoq team to ensure that the Evoq Content and Evoq Engage products provide a smooth upgrade for our commercial customers.
So what is changing?
In 2009 DNN began working with Telerik to ship RadControls with DNN as part of an OEM arrangement. This OEM agreement was ended in 2013 and since that time we have continued to ship Telerik with the platform even as we have worked to reduce our reliance on Telerik controls. In DNN 8 we are moving all of the Telerik wrapper controls into a standalone assembly so that it will be easier to make it an optional install in later DNN 8.x releases. While Telerik and the associated wrappers will still be shipped in DNN 8, this change will require some work by developers who rely on these wrappers. This will be as simple as opening the code, adding in a reference to the new assembly and recompiling. We will announce when this change has been added to the nightly build as it has not made the cutoff for CTP 5 which is due out this week.
Removing “Dead” Features
We have identified many features of DNN that are no longer relevant or that are rarely used. We have also identified a few features that are used by a small portion of our user base, but for which much better options exist. In removing these features we will reduce our memory footprint and improve the overall application performance. The following features are being removed from the core platform and being moved to the DNN Community section on GitHub (we are still working to get these projects completed and tested).
For those people who still rely on these features, you will be able to re-install the appropriate module or provider to re-enable the associated functionality. This approach allows us to streamline DNN for the vast majority of our users while still providing these features for those users who still want them. As we remove these features we are making sure that we don’t delete any data associated with the feature. For example, if you have data in the site log, after upgrading to DNN 8 you will be able to install the new SiteLog Module and continue using the feature without loosing any of your logged data.
While some features will be deprecated and moved to GitHub, the features below will be removed completely. These features have long since been deprecated, but the code has remained in DNN. This cleanup is long overdue.
- SolPartMenuNavigationProvider (and associated skin objects)
- Feed Browser
- Webslice Support
- What’s New Module
- ContentList Module
There is one final change that we have made that we have tried on two previous occasions. We are finally getting rid of the Connection String that resides in AppSettings. When ASP.Net 1.0 was launched, connection strings were just one more type of app setting in the web.config file. With ASP.Net 2.0, Microsoft introduced a dedicated ConnectionString section in web.config. Unfortunately, many modules used code which directly reads the connection string in AppSettings which prevented us from getting rid of the setting. This leads to extra code in the platform to try and keep these strings in sync, and can also lead to weird behavior if you modify one connection string without updating the second copy. We have fixed most of the community modules which relied on the old connection string and will work with vendors to ensure their modules don’t rely on this relic from 2005. If for some reason, you find a module that still requires this setting, it is not the end of the world, as a simple web.config edit will have you back up and running.
Performance, Performance, Performance
One of our goals with DNN 8 was to improve the overall platform performance. We have looked at many aspects of performance and have made changes to improve application startup time, page rendering speed and scalability. In looking at some of the application bottlenecks we had to make some changes which are technically breaking changes, but which should not impact your DNN site.
There are a lot of changes coming in DNN 8. While we want to avoid breaking changes whenever possible, we also have to balance that against the need to continually improve the platform. Sometimes this will require us to remove old code or refactor code to provide a more reliable and stable platform. In the end, I believe that the breaking changes in DNN 8 are necessary and will help improve the overall maintainability and performance of the platform. I would love to hear your feedback on these changes.
NOTE: We have a WIKI entry listing the DNN 8 breaking changes. We'll keep the WIKI updated if we make any additional breaking changes.