Steve Fabian wrote
So, here's the scoop... I'm running into some tough technology decisions. On the one hand, I want to be able to take advantage of all the latest toolkits and technologies like .Net 3.5, Linq, AjaxControlToolkit, WCF, etc. and there's some cool new stuff in DotNetNuke 5.0 (Cambrian). So the issue is .. do I target a moving train and require DNN 5.0 as the mininum version supported? and even tougher, do I use Linq and some of the other .Net 3.5 goodies. The highly dynamic nature of the module lends itself really, really well towards Linq, but DNN 5.0 initially will remain .Net 2.0, and there are some integration issues with Linq and WCF that still need to be worked out ( I believe there's a Linq issue if you are using an ObjectQualifier in your DNN installation ) as well as some expected installation issues if I target a platform greater than DNN itself.
It's not an impossible task, I am currently running verison 4.0 of the Repository module on my own site, http://www.gooddogs.com/dotnetnuke, which is running DNN 4.8. I just had to upgrade my site to .Net 3.5, then add the web.config sections for Linq. So it is possible. But I need to balance the advantages of developing using the newer technologies vs. the installation, configuration and support issues if I step too far ahead of the core platform.
It is quite easy to get DNN to run under .NET 3.5. We've been doing it since 4.7 actually. If you run from source, you can easily make the changes necessary to make it work. That being said, if the usage of .NET 3.5 features is delaying the release of the 4.0 version of the repository, I'd say skip the glam and go with what works for now. We have all been waiting a very long time for a new version and I believe some of us are still dealing with performance issues and flexibility issues with the 3.01.14 version that a totally re-written module is sorely needed. I'd love to see a module use all the new features that .NET 3.5 has to offer (and what came with the .NET 3.0 extensions), but I'll take a working, faster module, over one that is overly simple to implement because it offers better UI for setup and configuration.
I appreciate the hard work that is being done here, but am becoming a little impatient for the new version. I'd be glad to help, but as you know, it is difficult to get time away from full-time jobs to work on open source projects, especially when you need to commit to the project before you can actually see the code's trunk in the repository. It'd be nice if this project became 100% open at all stages, source repository was open to the public, and we could submit patches against the project, rather than following any kind of formal project team. I think you'd get a lot more help that way. It'd probably help the DNN project overall if DNN core and the rest of the projects followed that, too. See the Mozilla Foundation for projects like Bugzilla and FireFox for what I mean...