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

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

UPDATE: May 5, 2005

To date we have not been successful in finding any VB.NET to C# automated translation tools which can deliver the 95%-100% reliability. We have experimented with 5 commercial applications which promise this success rate but have been disapointed with the results. That being said, some of the tools are getting better and if one the vendors committed to satisfying our needs, it could be a very successful long term partnership.

In terms of a third party developing a C# version of DotNetNuke, there are some legal principles which folks need to be aware of. The BSD license for DotNetNuke is extremely liberal in that it allows you to obtain, modify, and distribute the source code without any restrictions ( other than retaining the copyright notice ). However, the DotNetNuke product name is a registered trademark which means that third parties are not legally entitled to promote their derivative works under this trade name. This may seem somewhat restrictive but it is the only way we can preserve the integrity of the brand/product for the benefit of the community ( if multiple versions of the app emerge which are all called DotNetNuke - it makes support for the users and partners nearly impossible ). What this means is that any C# version would need to be officially endorsed by the DotNetNuke Core Team for it to be legally distributed under the DotNetNuke tradename.

If one of the reasons for supporting a C# version of DotNetNuke is support for Mono ( and Linux ) then there are other alternatives to consider in this area. We are talking to MainSoft, creators of Visual MainWin, and they have indicated that we can compile VB.NET MSIL code into J2EE using their tool - which would allow DNN to run on Linux. This concept has not yet been proven but we have established a working relationship to pursue the possibility.

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

UPDATE: July 28, 2004

Based on the latest automated VB.NET to C# converters on the market, the DotNetNuke Core Team is undertaking a research project to determine the feasibility of supporting a C# version of DotNetNuke. The goal of the research project is to measure the automated conversion success ratio for each product and determine the scope of modifications required to improve the automated conversion process. Based on our findings we will be able to make an educated decision on whether or not we can support an official C# version of DotNetNuke.

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

by bhopkins

04-16-2004 5:05 PM

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