I've converted DNN3.0.13 (core framework project only) to c# and successfully running the site.  Modules and providers come with the package in a separated project are not converted except a couple of selected.

Although most of functionalities have been working fine, some serious QA testing would be needed before releasing it for public use.  Any volunteer to help please drop me an email.

Man you really need something more fun to do with your time

Congrats on your effort but why would you do such a thing? I guess you want to modify the core and prefer c# over VB? I hope the maintenance effort is managable.

This is a hypothetical question?  What are the benefits of the port, does it run faster? I assume all existing modules would work the same, but would need to be recompiled against the C# version correct?

In fact, as a by product, it really helped to understand how DNN was written, better than any documentation if there is any.  A roadmap to modify the core actually exists, make it 3 tier enabled, web farm aware, independence of database vendor, quite a few, can't wait for DNN team.  Release maintenance is really trivial aided by VSS 's visual diff.

However, it's really desirable if DNN make a C# version available in the same release cycle of the VB version.

this is not correct,
Visual studio alows for solutions with multiple projects in multiple languages. You would make your references just as you would in an all C# solution.

In this sence porting DNN to C# is pointless because you can easily make modules and providers in C#, google or search this forum for 'dnnjungle templates' for more information on this subject.

However, it's really desirable if DNN make a C# version available in the same release cycle of the VB version

Sorry, I find that completely UNdesirable. The vast majority of value from DNN comes from the framework and its features, not from the ability of people to modify it. I would much rather see the core team spend its precious time on features and stability of the VB version rather than diverting energies into a C# version. Just the testing effort alone (100% extra) is enough of an argument IMO.

Anyway, there's a pinned post somewhere that explains the core team's position on a C# version of DNN.

As for PurpleBox's comment, I don't entirely agree. The benefit of having a C# core is that developers who will only develop in that language can now modify the core. Like I said above I think this is a minor benefit but it's still there.

Some work you have pulled off there mate.

How do you plan your update? Will you try to be on Dnn VB equal number? Or will you lag behind?
But I suspect you have had a terrific learning experiance, better then a text book.

The only major benfit I see is for those who are running Dnn on Mono/Linux today. Now they can compile whenever needed. Of course there is ways around the compiling issues on Mono, one can just compile in VS then make a new upload. So that leaves the learning experiance.

Don't get me wrong, I applude your effort but I belive that most Dnn'ers will continue to use the VB version.  And this even if they do prefer C# over VB. Cause mainly people leave the core alone, and just make whatever modules they need. But the community beeing so big now, you just may have made someones day here.

 

Good Luck on the future updates

The major advantage that I see to a C# version of DNN is increased ease in porting DNN to non Microsoft platforms.

As far as I know, no one is yet successfully running DNN on Mono.  Though Mono can theoretically run any assemblies that have been compiled to IL (whatever language the source code was in and whether compiled using Mono's compilers or Microsoft's), there are enough non-cross platform compatible issues in DNN's source code (hard coded path separators and the like) that DNN won't run "out of the box" on Mono.

I imagine such issues in DNN's source code could be fixed with some effort.  But that's tough to do using Mono's tools because their VB compiler isn't quite ready for prime time yet.

On the other hand Mono's C# compiler is quite mature.   There seems to be a growing community of C# developers on the Linux platform who are attracted by the power and productivity of the .NET framework and care little or nothing about compatibility with the Microsoft platform.  Given that Mono's implementation of ASP.NET is stable and nearly feature complete, yet there is no web app framework as mature and powerful as DNN yet available for it (I know Rainbow can run on Mono, I like DNN better), it seems to me that having a C# version of DNN available, it is likely that some of those Mono only developers will be attracted to the DNN community and the cause of having DNN run "out of the box" on Linux, FreeBSD, even Mac OS X (all platforms that Mono will run on).

Such an influx of new talent can only be good for everyone who uses DNN.  Even if a C# version would be considered a fork (there, I've said it), users of DNN will utimately benefit.  It's likely that new ideas will cross pollinate between the two code bases.

As one who would like to work with all of the power of DNN on non-Microsoft OS's, I am very much looking forward to the release of this C# DNN code base and the PostgreSQL data provider developed by MainSoft.

Thanks for your efforts.

Well Done!

 

    DNN should be a C# project. I've always thought it odd that it was developed in VB to begin with. Not withstanding the Core Team's language preferences, it's clear that Microsoft is primarily interested in developing applications using C#.

    Whereas the Core Team is composed of seasoned developers, they're far more capable of learning a new language such as C#, than are inexperienced developers (such as myself) trying to learn two languages at once, which, are far more likely to be cutting their teeth on C# than vb.

    For the sake of simplicity the Core Team should begin supporting a C# version of DNN, with plans to drop support of a VB version in the next major release.

    Likewise module developers should begin the same transition.

    There's no compelling reason to continue to use VB when C# is just as good a language.

 

 Out with old, in with new!

 

Mark Garcia

Russell, this is one heck of an effort.  I hope it is running smooth for you.  I am very curious what you did to achieve this in terms of just all by hand or did you use some sort of conversion tool?

Web Farm support is almost here.  The setup is already database vendor independant, Oracle and MySQL dataproviders currently exist. (Not all modules come with another data provider though)  As for three tier, there are some rules I am sure we are breaking which keeps us from being completely 3 tier but we are very close with the DAL and CBO.

I think what you have done is great especially since I am sure you have learned tons.  The thing that would frighten me if I were in your shoes is missing all the improvements that are to come and if you want them you will have so much work on your hands.  Part of the next release is seperation of modules as sub-projects which will bring about lots of changes for every core module plus the forums/blogs/gallery. 

There's no compelling reason to continue to use VB when C# is just as good a language.

I really don't want to start a language debate here but that's not a very good reason. If both languages are equally good (something I agree with) then why tell people to choose one?

As you are an inexperienced programmer by your own admission perhaps you should focus on coding your modules in C# rather than wanting to modify the core. That would be the ONLY reason to ever port DNN to C#. It is not needed to satisfy the need for C# module support.

Personally I don't care what language the core is written in but I am against the core team wasting precious time on a port from VB to C#. Not that it matters what I think, the core team will do as it pleases but that's my nudge in that direction.

edit: made the first paragraph more palatable, sorry

Hmmm...  I really can't see Vb.Net going away. This discussion has been had many times.

The short answer here is that it does not really matter which language you choose.

It's really not that bad, after a run by VB to C# toolkit, most left are the syntax error , debugging and fixing, though a lots of them.

Admittedly, the first thing I had in mind after the porting would be to separate the built in modules from the core, as I am only interested in porting core, modules are ok to be left in VB, apparently less code means less work for me.  As IMHO, c# matters mostly in the non GUI code, I don't care about the aspx/ascx pages written in VB or C#.

So this is good news to hear what're coming in the pipeline.  Upgrading would be a pain, especially with major release.  I've actually kept upgrading since 3.0.7, while DNN3 becoming close to final, the changes have slowed down.  The objective of my porting is definitely trying to keep in the same release cycle of VB DNN3, at least not far behind.  Any modification to the core will be considered as fork to branch out into a separate open source project.

To tell the truth there is not a lot of difference between these two languages, if you can read and understand one you should understand the other even if you can't write code in it. If you can't then DNN may be too much app for you and you might need to start playing with the starter kits for a while.    Every once in a while someone starts talking about a c# version, but this is the first time I've heard someone say they had a lot of it converted and it runs. Bravo.

 

I just don't see the reason to have two bases as its a waste of resources unless the entire process is automated with some tool. The thing to really think about here is DNN was accepted as much as it was because it was VB. If it would have been C# when Shaun relaesed it, I doubt a lot of the old timers here  would have jumped on this train. Now you can talk all you want about this was just a fluke and it was the features, while the continued growth is the features fo the app, the start was because of  the language choice. Rainbow was here before DNN and it had features that DNN had, Rainbow was actaully more powerful at one time. So if C# would open all these additional doors, then why is Rainbow lucky to generate a couple of posts a week in their forums. Seems to me since its C# then all these people that will flock to DNN if it was c# then they should be there helping them and not worrying about DNN. Call it logic, but I'm having a hard time seeing how the core converted to c# is going to change a lot.