Why isn’t there a C# version of DotNetNuke?

最近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#程式員放棄成見，並用自己的能力去完成作者沒完成的事情。