Why isn't there a C # version of dotnetnuke?

Recently, dnn released 5.0. Many people commented on the excellent architecture of the system, so they wanted to join in. After a simple look, it was really good and interesting, however, the prejudice against VB cannot be changed at the moment. I tried to find the C # version and found the author section. It seems there is no such thing.CommunityA good solution can be provided.

However, according to the authorProgramIt is a benefit for members who can gain more knowledge.

 

----------------------

Why isn't there a C # version of dotnetnuke?

Originally posted by Bruce Hopkins on ASP. NET, objective L 4, 2004.

Shaun Walker's comments:

"This question comes up far too often in the Forum and as a result, I feel it is beneficial to have a definitive answer for the community. too often this topic has degraded into religious flame wars which do nothing but distract and confuse our esteemed community. hopefully some education and context will provide some insight into the deeper issues surrounding this topic, and provide some closure for those who are willing to listen...

Dotnetnuke is based on the VB. net implementation of the ibuyspy portal starter kit. the reason I chose the VB. net code base is because I have 12 years experience developing Visual Basic applications and I personally did not see any substantial benefit in moving to C #. I reached this conclusion based on the fact that the Common Language Runtime (CLR) provides an exceptional foundation which allows developers to use the programming langauge of their choice.

when. net Framework 1.0 was released, Microsoft focussed a great deal of effort on promoting the new C # language. I personally believe this was intended to handle the migration concerns of C ++ developers as well as to try and get the attention of the growing J2EE developer community. however, as a result, VB. net already ed very little formal recognition and it is easy to see why then companies who adopted. net in these early stages were convinced that C # was the language of the future.

As is the case with semantic ical achievements, these things eventually come full circle and it has been refreshing to see the strong commitment by Microsoft to VB. net recently. I was lucky enough to attend both PDC 2003 and vs live! 2004 and was excited to see the renewed focus on the VB. net Development Community (even Bill Gates 'key Note Speech demos had a solid VB. net flavor ). all of the Whidbey features which C # advocates have been so excited about (ie. generics, iterators, partial classes) will be in VB. net as well; not to mention, VB. net will exclusively get its legacy edit-and-continue feature back.

as far as dotnetnuke is concerned, the management team who is responsible for maintaining the open source code base is primarily comprised of VB. NET developers. this means that all core enhancements are developed in VB. net. however, this does not mean that dotnetnuke is incompatible with other ages. controls, providers, and private assembly modules can be written in any CLR compliant language and will integrate seamlessly with the dotnetnuke Core Architecture (this is the largest extensibility improvement over the ibuyspy portal Starter Kit-Where custom modules had be compiled with the core DLL; limiting the developer to a single language ).

when I hear the question "Why isn't there a C # version of dotnetnuke? "I assume that it means a C # version in addition to the vb version. most of you with product development experience realize that it is not really a development issue of porting the source code to C #. rather it is the logistical issues of managing parallel Code bases through evolutionary release cycles which is the real challenge. in fact the initial development effort is probably the least complicated part-it is the ongoing integration of enhancements and defect corrections, the testing of Multiple Code bases (each with multiple data providers ), packaging and releases, management of defects for each code base, support for each code base, documentation for each code base ,... the list goes on. as a volunteer effort, we currently do not have the committed resources necessary to support a parallel language version

That being said, I think the project cocould really benefit from a C # version. if we cocould find an automated translation tool which is capable of converting the VB. net code base to C # with 95%-100% reliability then we may consider supporting a C # version. in this scenario, the core development effort wowould continue to be in VB. net but at the end of each release cycle, we cocould perform an automatic conversion on the entire project and with some minimal testing (hopefully), We cocould publish a C # version. unfortunately at this point I have not encountered any automated translation tools which can perform the task to the level of accuracy we require."

 

Thank you for your efforts! I also hope that more C # programmers will give up their prejudice and use their own capabilities to accomplish what the author has not done.