最近DNN发布了5.0,看到很多人在评论这个系统的优秀架构，不禁也想来凑凑热闹，简单看了一下，的确很不错，大有兴趣，无奈对VB的偏见不是一时能改过来的。试着找C#版的，结果找了Author的这段话，看来是没戏了，倒希望社区能给个好的方案。
不过看到最后，按作者所说的，这对C#的程序员来说是个好处，可以接触到更多的知识。
----------------------
Why isn't there a C# version of DotNetNuke?
Originally posted by Bruce Hopkins on ASP.Net, April 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 the .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 ease 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 received very little formal recognition and it is easy to see why many companies who adopted .NET in these early stages were convinced that C# was the language of the future.
As is the case with many technological 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 languages. 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 to 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 could really benefit from a C# version. If we could 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 would continue to be in VB.NET but at the end of each release cycle, we could perform an automated conversion on the entire project and with some minimal testing ( hopefully ), we could 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. "
感谢作者的努力！也希望更多的C#程序员放弃成见，并用自己的能力去完成作者没完成的事情。