|
|
Sep
9
Posted by:
Joe Brinkman
9/9/2009 10:15 PM
 From time to time every platform faces a choice – continue supporting old technology or make a break with the past so that you can better take advantage of current technology and position your platform for the future. We have been very fortunate over the past several years that we have not been faced with this choice very often. In 2004 we officially ended support for ASP.Net 1.0. In 2006, with the sun setting of DotNetNuke 3.x, we officially ended support for ASP.Net 1.1, even though many modules that were compiled against the .Net 1.1 framework continue to run today without any difficulty. The DotNetNuke platform as it exists today, supports the same operating systems, .Net frameworks and databases as those we supported in 2005 when DotNetNuke 4.0 was released.
We once again find ourselves at the point where supporting those old framework and database versions is hindering our ability to keep up with the state of the art in .Net development. .Net 3.0 and 3.5 added substantial improvements to the framework which we have largely been unable to take advantage of in the core platform. Not only does this hinder core development, but it also hinders our ability to help the development community apply best practices when using new technologies like Linq to Sql or Entity Framework. Equally important, module vendors are likewise held back from moving forward as long as we continue to support ASP.net 2.0. Commercial module developers have told us that they very much are constrained by the baseline framework supported by the platform. As long as a large majority of the community is running on ASP.Net 2.0, then they will continue to develop for that platform. By moving DotNetNuke forward, we enable our vendor community to follow our lead and move forward themselves after they have given the users adequate time to upgrade to the new DotNetNuke version.
Continuing to support SQL Server 2000 also means that we can’t optimize DotNetNuke for the current platforms like SQL Server 2005 or SQL Server 2008. We are increasingly having trouble maintaining environments where we can ensure backwards compatibility across all of the supported database versions. This is seen by the number of recent bugs which affected SQL Server 2000 compatibility. This is not just an issue with core developers. As an Open Source project, we rely on the community to help us identify issues and suggest fixes. As fewer and fewer members of the community are running these platforms, we have fewer and fewer resources to help identify and correct issues when they occur. As a result, a smaller and smaller segment of the community is responsible for continued testing to support an equally small segment of users.
Whenever we reach a point where we wonder whether to continue supporting a feature or a platform, the first question we always ask is how many people will this impact? Since the first day when Shaun launched DotNetNuke in 2002, we have always taken backwards compatibility very seriously. That is not to say we have been perfect in maintaining compatibility, but that it is a high priority for us. Discontinuing support for features or platforms is not a decision we make lightly. Over the past 18 months we have spent a lot of time talking with system integrators, hosters, developers and our contacts at Microsoft to find out how widely ASP.NET 3.5 has been deployed. We also asked how widely SQL Server 2000 continues to be used.
Based on the data we have collected and the people we spoke with, we know that well under 10% of sites currently running DotNetNuke do not have ASP.NET 3.5 deployed and and equally small percentage of sites are still running SQL Server 2000. As a result of this information we have made the decision to officially require ASP.NET 3.5 SP1 and SQL Server 2005 for DotNetNuke 5.2 and beyond. Those people who are unable to meet these system requirements will still be able to run DotNetNuke 4.9.5 and 5.1.2 which are both stable products.
In addition to ending support for SQL Server 2000 and officially moving to ASP.NET 3.5 SP1; with the release of DotNetNuke 4.9.5 we have stopped development of the DotNetNuke 4.x platform. We will continue to evaluate security issues on a case by case basis and will consider the release of DotNetNuke 4.9.6 if we feel a security issue is critical enough to warrant such a release. One of the things that we learned when we made the transition from the 3.x to the 4.x platforms and again when we made the transition from 4.x to 5.x, is that we spend a large amount of effort to try and keep two dissimilar codebases in sync. Bugs must be validated against two platforms, triaged, and resources assigned. The 4.x and 5.x platforms are dissimilar enough that it is not always easy to port a fix from 5.x to 4.x, and often requires a completely unique fix. Continuing to maintain the 4.x platform consumes resources that would otherwise be used to further improve the 5.x platform. Given the current state of the 5.x platform, we feel that the time is right to take our focus off the platform we first launched with the release of Visual Studio 2005 and focus our resources 100% on completing the Cambrian vision we laid out at OpenForce 2007 and further moving our platform forward.
With these changes we are confident that the DotNetNuke platform will continue to maintain it’s leadership position as the Premier Web Content Management System and Application Framework for Microsoft .Net.
Tags:
19 comment(s) so far...
Re: DotNetNuke: Taking a Leap Forward
Sounds like sound logic. I'm looking forward to being able to harness the improvement of ASP.NET 3.5 and the newer versions SQL Server.
By David OLeary on
9/10/2009 7:59 AM
|
Re: DotNetNuke: Taking a Leap Forward
Awesome news, and well-written post (as usual). Just the sort of thing I would hope our DNN Technical Fellow to announce. ;)
Seriously, this is great news to everyone.
By Will Strohl on
9/10/2009 9:32 AM
|
Re: DotNetNuke: Taking a Leap Forward
Time to toss those ASP.NET 2 books I've been hanging on to.
By Kelly Ford on
9/10/2009 9:32 AM
|
Re: DotNetNuke: Taking a Leap Forward
Excellent news! I think it's a great move and appropriate timing. I do, however, question the "well under 10%" assertion regarding DNN sites currently running on .NET 2.0. All of our self-hosted sites and all of our new shared-hosting customer sites are brought up under 3.5 but we still have a _greater_ number of legacy shared-hosting sites humming along happily under 2.0. I suspect the same may be true for many others' existing DNN sites (much more than 10%) though, for most non-source-code sites, the change should involve nothing more than an admin tracking down the appropriate place to select ".NET 3.5" instead of ".NET 2.0".
I'm looking forward to all the cool new module offerings that should start to pop up as a result of the move to 3.5. Once again, excellent news!
By mamlin on
9/10/2009 7:57 PM
|
Re: DotNetNuke: Taking a Leap Forward
good news!
By brian on
9/10/2009 7:57 PM
|
Re: DotNetNuke: Taking a Leap Forward
You guys have been great with backwards compatibility and legacy module support. I don’t believe advancing with times and using new, modern, and more efficient .Net APIs will case too much problems. Most DNN installations are hosted in shared hosting environments which are usually up to date with core stuff like .NET versions
By Slavic Kozyuk on
9/10/2009 7:58 PM
|
Re: DotNetNuke: Taking a Leap Forward
this is fantastic news! but what about nhibernate?
By CurlyFro on
9/10/2009 7:58 PM
|
Re: DotNetNuke: Taking a Leap Forward
Nice post. I have been thinking lately about the future of DNN. Where is it headed? Is it on an web development evolutionary dead end? Is it time to create a clean break with the past? Do we need a stripped down / lightweight version? These are just some questions to get the discussion moving. I'd be interested to hear what other people think. Maybe I'll start a thread in the Chat About it forum.
By Robert on
9/10/2009 7:58 PM
|
Re: DotNetNuke: Taking a Leap Forward
Now we can get started on an IQueryable interface and ditch the old IDataReader, cloud hosting here we come :)
By Philip Beadle on
9/15/2009 5:00 AM
|
Re: DotNetNuke: Taking a Leap Forward
We have not made any decisions regarding the use of Linq to SQL or any other ORM in the core, but we feel that the core should enable module vendors to create extensions that serve their target audience. Some vendors will choose to use an ORM approach and some will not. I suspect that the decision on how that is implemented will be driven largely by customers who make their feelings known to the vendor community. The bottom line is that the core team does not want to be a barrier to progress.
By Joe Brinkman on
9/15/2009 5:08 AM
|
Re: DotNetNuke: Taking a Leap Forward
@Mike - We are not planning to change our Data Access layer. The announcement is only that we are requiring .Net 3.5 SP1 starting with 5.2.
By Joe Brinkman on
9/15/2009 10:20 AM
|
Re: DotNetNuke: Taking a Leap Forward
Great news!
By Ernst Peter Tamminga on
9/12/2009 9:28 PM
|
Re: DotNetNuke: Taking a Leap Forward
This is great, however, we would urgently need a starterkit, written specifically to take full advatage of FW 3.5, Control Methods, AJAX, Extension Methods, Silverlight, WPF, WCF, WWF etc. and examlifies the newer features.
By Jaydeep Bhatt on
9/11/2009 10:14 AM
|
Re: DotNetNuke: Taking a Leap Forward
> Time to toss those ASP.NET 2 books I've been hanging on to.
Don't do that !!!! You will need them.
By Alex Shirley on
9/12/2009 9:29 PM
|
Re: DotNetNuke: Taking a Leap Forward
Great news. Our customers are asking more and more to for these features. We use it often. DNNflow.com planned to use only the 3.5 platform from 2010 to develop our new modules. DNN is now ready to maintain its place as a winning platform.
By Mike Wertwyn on
9/22/2009 9:00 AM
|
Re: DotNetNuke: Taking a Leap Forward
Please do not use Linq-to-SQL. It is effectively dead. Use Linq-to-Entities or some other ORM.
I have a lot of experience in using DNN but cannot use it in my present job because they use Advantage Database Server.
Supporting multiple databases is what I really need.
By Mike Grace on
9/15/2009 10:16 AM
|
Re: DotNetNuke: Taking a Leap Forward
That's a bit of a pain for us, but we can move forward.
But my greatest fear from this announcement is that the platform developers will get carried away with Linq-to-SQL. Use of an ORM more or less requires all users get base table permissions and this is much less secure than requiring stored procedures.
I beg that you discuss the implications of Linq-to-SQL with the whole of the team, involving Cathal in a big way. While ORMs have gained much favour in the industry recently, the people advocating their use are not listening to - indeed sometimes actively dismissing - the security champions that say that your database should be locked down.
We've already seen a core module - Survey - move away from use of stored procedures, and as such it will no longer work in our environment. If any other sections of the application move in this direction then we'll have to drop DNN. I suspect that lots of other enterprises will be the same.
While I understand how attractive ORMs are to developers, code generation from a high quality set of templates can prove a better productivity tool from the point of view of security. Please don't let the ability of the application to run against a highly secure database slip without having actively made a decision on this crucial security concern.
By AndrewH on
9/15/2009 5:01 AM
|
Virtual Assistant Philippines
Good news travels fast! There will be a lot of changes, I'm sure, all for the improvement of the system.
By ShiningRay on
9/22/2009 9:01 AM
|
Re: DotNetNuke: Taking a Leap Forward
good choice...being able to compete requires some changes now and then...good luck..
By chiqui13 on
3/6/2010 9:19 AM
|
|
Follow us on Twitter @DNNCorp or join the DotNetNuke Community on LinkedIn
|