xsharp.eu

Hi to all (and specially directed to Dick),
following what Dick posted in the comments about the much longer time needed to start an (xported) application from Visual Studio than from VO, I have selected this form to explain the "why" and "how to fix".
First of all, VO comes from a time when computers were really slow, and therefore the architects of VO decided to build the IDE on a database (the repository) with dependency managment on the entity level (i.e. a method, function, constant etc) when nearly all others, including the Xbase world, Microsoft, Borland and the entire *x world were using much simpler text files to store code.
It took many years (until Robert fixed it definitely) to make that repository stable, and many people has lost code because of database instabilities.
This approach led to very short build - run cycles, and contrarily to the trends to short and many files in the rest of the development world, the repository led us build gigantic classes and loooong methods, and even worser, monolithic applications with executable sizes over 50 MB.
Unfortunately VO and its repository based development approach remained a niche product (this is not the correct place to speak about the "why"), and to give uns a way into the future, GrafX and later the X# team was forced to give up this approach and turn to a file based model.
Unfortunately, Microsoft with its C# and VB.NET compilers had to give up the incremental building process of Visual C++ (again a choice I would not like to discuss about), and use a full build model, maybe because with SSDs, much memory and fast processors that seemed not be important.
So, if whe combine our typical VO development style with these changed environment, we will understand what the price is: much longer build - run cycles, because the compiler needs to rebuild the entire application every time, and not only the (few) changed entities.
The culprit of these long times is not the X# development team, nor a slow compiler, but our old development style.
So, if you are porting a VO application to X#, break it up into smaller libraries and, if possible, a small executable.
My WPF applications are built by small libraries and relative small executables, and even if they don't reach the code volume and complexity of my VO applications, they have relatively short build - run cycles, normaly about 20-30 seconds (ok, that is longer than in VO, but I can live with that).
So, to move forward with an xported VO application, it would be a good idea to break it up, and move the base libraries to a different project. Your development speed will increase, and combined with the powerful .NET framework libraries you will need much less code.
Wolfgang
P.S. of course, whe can discuss this here - and this is why I opened it in the Chit-Chat section and don't opened a follow-up in the comments

Hello Wolfgang,

I think your story is basically sound and it's good to separate it from the "Progress update comments".
We may not be able to solve the issue, and yes I know X# is probably not causing it, or only limited, but that does not stop me from being frustrated that I often have the feeling that we go one step forward and 2 steps back. Especially when companies like Microsoft are involved. Instead of massive rejection, these companies full of substandard executives and programmers rule the world.

And unlike you, I don't find run cycles of 20-30 seconds acceptable. When I am developing a full work day I have probably compiled and restarted the program a 100 times. In VO total waiting time for that would have been 5-10 minutes, in X# close to an hour. So I probably lose 3/4 of an hour every day on a day of programming.

I realize perfectly that making a program future proof + some advantages (more widely) available in .Net does not really allow us to do nothing. Nevertheless I will postpone it for most of my programs as long as possible.

One thing I still do not understand. The program does consist of 1 main program and 16 libraries. Why does VS build all 16 every time even when typing 1 space in 1 project? How can we prevent that?

Dick

Hi Dick,

I think Robert has mentioned it a lot of times already, you need to go to Build -> Configuration Manager, and uncheck the "Build" checkbox from all the entries (projects) of your solution in the dialog that opens up. Now, VS will not rebuild everything when you make a small change, you will be responsible for doing that when this really needed (like when you change the signature of a method, the name of a class etc), by explicitly telling it to do so with a "Rebuild" command.

If you still get compile times of 30 seconds or so, then you either need to cut a library that's over 200,000 lines of code to two smaller ones, or get a faster PC CPU more RAM (at minimum 16GB is a good idea).

.

Dick,
What Chris said, BUT

1) You have to be sure that you set the output folder for all projects to the same location, for example $(SoliutionDir)$(Configuration), which creates a separate Debug and Release folder under the Solution folder. Otherwise each project will copy its output in its own folder and the new DLL will not be in the folder where the EXE is created. That will usually be a binRelease and a binDebug folder under the project folder.

2) Make sure that you are not using a assemblyversion in the form of "1.0.*.*". If you use the asterisk in the assembly version then each compilation will result in a new version number and then the new assembly is no longer compatible with the old one, so the dependent assemblies will not recognize it.
If you remove the checkboxes in the configuration manager then you can rebuild the whole solution from the Build-Batch Build screen, or select all projects in the solution explorer and riight click and choose rebuild.

Robert

Hi Dick,
I have to correct myself as I have now measured the build - run cycles for my largest X# applications (built from scratch and not xported): they are between 6 and 9 seconds.
But nevertheless I think these times are relative short when compared to the time I need to get to the functions I need to test and to the test times itself.
But there is a saying here: accept things you cannot change, and improve things you can change.
So I think we cannot block us on the things that were better in VO and worse in the new IDE. There are many things that are much better in X# than in VO, and IMHO it is really a big step forward, even with many small steps backwards.
Wolfgang

Hello,

Thanks for the hints; Frank (re)applied them all. He has done this before but ran into problems but we couldn't recall which. Hopefully it was due to something which is now fixed because re-running the program is indeed much faster. As written, the issue is not the Pc, which is new and has the best possible specs.

Frank will carefully collect and post details here in case he runs into issues again.

Dick