Dear Steve,

can you please let us know when do you planning to release a beta version. Where are you in your "to do" list now? I'm very exiting about new repository module, so please keep us informed!

Best regards,

Alexander

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...

oh and btw. I am still committed to supporting .Net 3.5.  There are some core modification being discussed regarding .Net 3.5 support in DNN 5.0. Nothing final yet, but as of right now, I am planning DNN 5.0/.Net 3.5 as the target platform for version 4.0 of the Repository. I know at least one person has voiced an opinion that if the repository 4.0 module required DNN 5.0 and .Net 3.5 it would be a disaster for him, however it's difficult to support the type of functionality I'm building in .Net 1.1 and/or 2.0, and the effort to support 2 code bases would be overwhelming.

It should also be possible to run version 4.0 of the Repository on a DNN 4.X site, but that will require some manual changes to the web.config file. 5.0 is looking like it will support the automated updating of your configs to add the 3.5 entries. Again, this is just in the discussion phase.

I am also considering at this point, releasing 4.0 as a brand new module, NOT an upgrade. Which means that you will be able to run Repository modules version 3.01.15 and 4.0.0 side by side on the same DNN site. I would certainly provide an 'import' or 'conversion' process for moving your 3.X modules over to 4.0, but I do not want to leave the 3.X users in a lurch if DNN 5.0/.Net 3.5 is not an option for them.