My Cart (0)  |  My Orders  |  My Downloads  |  My Auction  |  My Account  |  Help


Login |Register        Search

Break changes in DNN 8

                Print      Add To Favorite     Add To Watch List     Contact Author

Creator: host   6/8/2016 4:23:11 AM    Author: Joe Brinkman   Source: http://www.dnnsoftware.com/community-blog/cid/155269/a-break-with-the-past   Views: 1658    0    0  
Tags:
DNN 8

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?

Separating Telerik

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.

One of the performance bottlenecks that we noticed was that all static files were being processed by a number of HttpModules in the platform.  In doing our performance testing we found that this resulted in a significant degradation in performance.  Under low load, there wasn’t much performance difference, but as load increased the performance problems became worse.  Ensuring that all of the HttpModules include a preCondition=”managedHandler” ensures that only actual ASP.Net code is run through the HttpModules.  All static code (like images, JavaScript and CSS) will be served by IIS which is very efficient in serving these files.

Conclusion

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.


Rating People: 0   Average Rating:     

     DnnModule.com is built to provide DNN quality modules and DNN skins, some of them are free, some not. We wish these stuffs (free or not ) can be useful to you.

     Besides that, we also provide a full range of professional services, ranging from web site build, seo, system management, administration, support, senior consultancy and security services. We act as if your development project or network was ours, with care and respect. We are not satisfied until it works the way you want it to, and we don't silently ignore found issues as somebody else's problem.