|(Please note, this is a long reply to this posting [^], so I intended to write a whole new posting instead)
I nearly finished "converting" the approx. 300.000 lines of C++ code of our flagship product "Zeta Producer [^]" (a Windows-based CMS) from MFC/C++ to C#.
Following is a short description of the things I experiences along the road. Since I'm currently in the right mood, I want to share them here with you :
It roughly took me 10 month (having other smaller projects in parallel, though) to convert from C++ to C#.
My own coding experience is 15 years of C++ and maybe 5 years of C#. I strongly recommend that you really know both languages (and their libraries MFC and BCL!) very well.
I do think I still have a lot of (smaller) bugs due to the conversion, but we already do use Zeta Producer (version 8 now) internally in serveral projects and several beta testers do use them, too.
The steps I did when "converting" (inside quotes, cause it was rather a rewrite than a conversion) where roughly:
- Re-create all MFC-present dialogs, windows, controls from scratch inside the Windows Forms designer. No functionality, just the plain GUI.
- Port all non-visual code by first creating all classes inside C#. This was the largest part. I did it by creating file by file (for each .h/.cpp pair, I did one .cs file), copying the content of one C++ class into the corresponding .cs file. Then I manually changed the syntax until no code editor errors are present any more. This really took looooooooooong, since it were several hundreds of files.
- Add the event handlers for all Windows Forms. The same way as in 2.).
- Build the first time (this was after 3 month or so when I first started . Get thousands of errors. Fix them and repeat rebuilding. Do this until no more compiler errors are present. This took half a week IIRC.
- Run. Get lots of runtime errors.
Finally, to sum up, I eventually get the think running. Still rather unstable, but it ran.
Then It again took a rather long time to really get things better and fixing all those little glitches.
I really saw the light at the end of the tunnel. (This was after maybe 5 or six month from start). I slightly began adding new features (since the customer doesn't care that it now is C# rather than C++; he cares about stability, easy of use and new features, to name a few) for the new version 8.
Also, in parallel I did (and still do) refactor larger portions of the code step-by-step to more .NET-centric coding- and algorithm-style (like using BackgroundWorker and all those myriads of new things that only exist in .NET ). I do read a lot in the GoF book and also other design pattern stuff to make my code better. This is much easier (in my opinion) after having ported it to C#.
Reasons to port
The reasons I did the port were:
- Zeta Producer is our key product and "cash cow" that is one of our USP. Therefore I wanted to ensure that it is safe for the future.
- I wanted to lower developement times. C++ tooks waaaaaaaay to long to develop, especially all those nice GUI stuff that is trivial in C#/.NET.
- First, I tried C++/CLI. Although Nish would disagree, I think it is a total crap. At least for me, at least for the kind of product we do develop.
- I wanted to use all those sexy .NET features like WebServices, etc.
Where we are now:
- We are currently in beta stage, still adding some features that are not present in the original C++ version.
- The translation still needs to be done. Thanks to Zeta Resource Editor [^] I hope this is painless (and it is not done by me either - hurra! ).
- Testing, testing, testing.
Lessons learned, Pros and Cons
My summary until now, how I experience the "porting":
- Pro: What we have now really justified the hard work. It's a pleasure to work with the code, it really does compile rather fast (10 seconds for a rebuild, compared with 20-30 minutes for the C++ version).
- Pro: We do have a strong code base to develop further version.
- Con: I am paranoid. What if I have introduced thousands of yet-to-discover bugs during the conversion?
- Con: Speed. Currently the C# version is slightly slower than the C++ version. This is, as far as I can tell, not caused by the CLI itself, but due to my own partially inefficient algorithms. The last two weeks during the holidays, I spent a lot of time profiling (with ANTS Profiler [^]), already gaining large performance benefits. So this is definitively accomplishable, but takes time.
- Con: The port is done by one single developer (me). The C++ code was written by a max. of 3 developers. Seeing multi-national/-million dollar companies having huge resources of developers, I sometimes feel that I never can compete with them, both in functionality and in academically approaching such a port. I ask myself things like "Should I have done UML"? "Should I use Unit Testing"? etc. But on the other hand, the software is running and will be making money. So I cannot be that wrong .
Here, I do end, maybe someone likes what I've written here and it is a good hint for porting your own projects . Enjoy!