|
Search for Windows Workflow Foundation, it's the latest workflow framework from MS, all .NET based.
|
|
|
|
|
(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 "Porting"
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.
Current state
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!
|
|
|
|
|
actually i have made an RSS reader in C# using SQL Server Express Edition.. but every time i make some minor changes in the program and publish it and install it all news channels folders that i have made during the previous installtion goes away... is there any way to store data ie is there permanently...
Please help me i am new to C# programming only 2 months experienced
|
|
|
|
|
During the publish, you are uploading the database as well. You need to make sure that you aren't uploading the database to stop this.
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Hey thanks Pete for the idea but if you have the time could you tell me where is the setting to accomplish this.... thank you in advance
|
|
|
|
|
Hey All,
A very happy new year to you all. I am working on GoF design patterns. I want to know if it is feasible or possible to make a library like STL for design patterns using .net Generics? If there are some existing projects like this can someone please send me links to it?
thanks
RB
|
|
|
|
|
I doubt that this is possible. I do not design my algorithms just for their own sake, but rather dependent on the infrastructure and related classes of the project where I need the classes in.
But on the other hand, maybe you come up with a great solution. I would be the first to use it !
|
|
|
|
|
I am not making classes just for the sake of it. What i have in mind is that like in STL to have a list of student what we can do is List<cstudent> s_list similarly i was looking to do something like if we need a single student object in our object..we do not need to make the student class singleton but only keep the object singleton like Singleton<student> ss = new Singleton<student>();
Do you still think its impossible?
thanks
RB
|
|
|
|
|
hi
i have a string and i want to search a string and navigate into this string,but how to do ?
|
|
|
|
|
See IndexOf() and IndexOfAny() .
/ravi
|
|
|
|
|
Look at the Substring method on the String class.
|
|
|
|
|
I am looking at converting some C++ code to C# and i have a few questions. My experience with C++ is severely limited, mostly to some recoding of Quake 3 and Half-life 2 source code, just fooling around with modding.
i am not 100% clear on the function of header files, and would like to know if there is a need to, and easy(ish) way to emulate the behavior of header files in C#.
if they simply contain large groups of static variables? should it then be a simple task of taking the contents of a header file and rewrite it as a bunch of static variables in the program.cs file (or wherever they may be used)?
______________________
Mr Griffin, eleventy billion is not a number...
|
|
|
|
|
Vodstok wrote: if there is a need to, and easy(ish) way to emulate the behavior of header files in C#.
There is no need. Header files in C++ are a way to tell the compiler and other class files which functions are in a class.
C# has no such restriction, just declare all variables, methods, symbols, etc. right inside the class file, no header required.
|
|
|
|
|
That makes me very happy Thank you.
______________________
Mr Griffin, eleventy billion is not a number...
|
|
|
|
|
I posted my experiences when porting an application here [^].
Maybe it is of some value to you .
|
|
|
|
|
Every little bit helps
______________________
Mr Griffin, eleventy billion is not a number...
|
|
|
|
|
how can I make activex (.ocx) file
in c#?
I have a software that can get .ocx files
and not .dll files
|
|
|
|
|
You can't. C#, VB.NET and the other managed-code languages can't target building an old .OCX file. It can still be done using C++ though. The managed languages can "emulate" a COM component by COM-interop, but they cannot build an exact binary replacement for them.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Hi gurus!
I’m creating a large array that holds the distances from all points in a location file (x and y coordinates) to all other points. I have no control over how many locations the user will input (thousands most likely) so with the number of distances to record at (n(n-1)/2), I’m going to be storing a helluva lot of values. As I want to use these in a Monte Carlo simulation and access each value up to 999 times, I would prefer to calculate the distance matrix only once and not have to recalculate each distance every iteration of the MC simulation.
I would appreciate advice on the most efficient way to store and quickly access these values: ArrayList, Hashtable, Queue or something else?
A secondary question. Is what I am trying to achieve just unmanageable? For example, with the user including 10,000 locations, that creates 49 million distance calculations. How will this affect access time to reading the values again and again…?
TIA
Jerry
|
|
|
|
|
Hi,
if your distances are theoretical, why not just store city coordinates, and calculate
the distance every time you need it?
If it is actual distances, you will need to store of course; maybe a random-access
file on disk is appropriate.
In any case, I would be worried more about elpased time for your program,
when it will deal with 10000 cities visited 999 times...
I hope it is not a brute force attempt to the travelling salesman problem !
Luc Pattyn
|
|
|
|
|
I'm afraid I'm not familiar with the travelling salesman problem, so it isn't that!
The Monte Carlo simulation is one that keeps the spatial locations constant, but randomises a third variable (the first two being x and y location), and yes, these are real locations. My concern with recalculating the distances every time is that with 10,000 locations, that creates 49 million distance calculations. With 999 iterations of the Monte Carlo simulation (1000 with the observed outcome), that means that to complete the program requires 1,000 x 49 million distance calculations . Hence my desire to only do the 49 million calculations once and then store the results in an array that I access the remaining 999 times.
Do you (or anyone else out there) think that recalculating the distances every iteration for 999 times will be quicker than storing the distance results in an array or a file and accessing them repeatedly?
Jerry
|
|
|
|
|
I still dont know what you want to do in each run, e.g. I am not sure you need
all the distances everytime.
If each run only needs "a few", do lazy calculation (i.e. only what is needed),
if you need all of them every time, I would go for the (large) file on disk,
which will automatically get cached when your code reads the relevant entries.
Also, how complex is one iteration ? is it much larger than calculating the
distances it needs, or not ?
Can you be more specific ?
Luc Pattyn
|
|
|
|
|
I need every distance, every time. The program is designed to conduct a new statistical process on locations that have a date attached. Think something like bird spotting. I have, say 10,000 records with an x and y coordinate and the date of observation. The program measures the distance between each point to every other point, and also measures the number of days between each observation. It then randomizes the day, and repeats the process 999 times, randomizing the days each time. The distance between points therefore remains constant and does not need to be recalculated, but it does need to be remembered every one of the 999 iterations, becuase it categorizes the results by distance. And there will be 49 million distances to remember.
The question therefore remains, for speed do I recalculate the distance every time on the fly, or save in a file, or save in an arrayList, Hashtable or Queue...?
|
|
|
|
|
OK, I start to get the picture.
Your basic information consists of some 10000 points (that could be 80KB of data).
So it seems very wasteful to expand that to a full distance matrix (some 50MB).
Let us assume that distance simply equals SQRT(dx*dx+dy*dy).
I did a simple experiment: the following code
double z=0.0;
for (int dx=0; dx<10000; dx++) {
for (int dy=0; dy<10000; dy++) {
z+=Math.Sqrt(dx*dx+dy*dy);
}
}
Console.WriteLine(z);
took less than 4 seconds on a 1.7GHz Pentium M.
Using a file on disk would certainly be faster (A large part of your file would
typically be in the file cache in memory, which gets refilled at the disk's
transfer rate, typically 100 MB/sec or more). So I expect consuming 50MB would take
under 1 second (you could try that with another 50 lines of code...)
On the other hand, the (lack of) speed of the above code is mainly due to the
Math.Sqrt() method; if we replace that line by z+=dx*dx+dy*dy; it runs in less
than 0.7 seconds.
Preliminary conclusions:
- if you are lucky and only need the square of the distances, go for direct calculation;
- if you are unfortunate and need a more complex calculation for distances (the earth
being round, remember), go for the file on disk.
- it may be worthwhile to investigate faster SQRT methods (maybe int based, maybe
slightly less accurate, whatever).
My suggestion:
I would certainly start of with direct calculation and see how it is behaving
before introducing a file-based optimization (the rule is: think first, then code
and get it working without unnecessary complications, then observe and
only then make changes, and introduce complexity, to improve).
Luc Pattyn
|
|
|
|
|
This helps a lot, thanks!
I hadn't considered that the SQRT function was so time consuming, but given the iterations that I have, that is a big factor. I'll try what you suggest.
Cheers.
|
|
|
|
|