Debug on or off: seconds in VO, hours in VS?

[ic2]

While I was reviewing (mainly for myself) how currently using .Net with Visual Studio is against VO I came across one thing following a message from Chris.

As far as I know, a debug status can only be set by adding

[System.Diagnostics.DebuggerHidden()];

before every method which you want to skip during debugging.

That means, in the worst case, you have to manually remove 1000's lines of code containing [System.Diagnostics.DebuggerHidden()]; (and especially: later add these again) where it is done literally one checkbox (in an AEF with 100's of entities) in VO. So temporary change your debug status in VO takes a few seconds while in Visual Studio it can take a few hours.

Or do I miss something?

Dick

[robert]

Dick,

To compile without debug you choose the "Release" configuration in the toolbar.

config.png (6.23 KiB) Viewed 301 times

In the image you see that we have added a 3rd configuration "Public" (in the compiler source) which has the assertions off but does not have the optimization of a Release build

Robert

[Chris]

Dick, you really need to make peace with how things work in .Net. VO had a very powerful repository, which was making wonders, but was also causing some problems and was extremely difficult to maintain and debug (itself). In .Net we do not have such a thing, the design is different. Also myself when I first designed XIDE (CulEdit back then, 15 years ago, oops!!!), I made it work with a repository-like system, but there were so many side effects of that, so I quickly abandoned the idea. Fortunately I made peace with the file-based system quickly.

Trying to emulate how debugging in VO works with its repo by adding thousands of "no-debug" attributes in your code will not work, will make everything cumbersome, will make you miss errors, and of course will frustrate you. Those attributes are meant to be used for small low level code that gets called a lot, but NEVER makes sense stepping through it. For your basic functions you should never do that. Just spend some time getting used to how it works in .Net, debugging with step-over, step-into, step-out, set breakpoints etc, it is very powerful as well.

Personally, when I need to do any work in VO, I am now finding VO's system very cumbersome to use, even though I had been using it every single day for many hours per day some years ago and I was doing fine with it. Not saying it's bad in VO, but it needs some getting used to, when you are used to work in a different way. The same goes for the file based approach, it needs some getting used to, so please give it some time, but without fighting it. Otherwise I guarantee you, you will never like it and you will be always missing the productivity boost it offers (yes, really! ) compared to VO.

[lumberjack]

Dick,

To emphasize what Chris said... I can guarantee you, when I started in .NET with Vulcan, I went straight for using VIDE. Was only when I started with X# that I used VS...

These days I don't have any issues using any of the IDE's however my choice is:

1. XIDE rocks
2. VS feels sluggish
3. VO IDE... gosh I need to get used to it time and again...

Yes, even in my VO days I moved away from the repository to a file based VO system. Burned my fingers only once with corruption. There is just no way I can move back to it again...

[wriedmann]

Hi Dick,
I'm using the XIDE debugging, and really, I'm missing the possibilities of VO to enable the debugging only for some entities.
But it is not there, and so there is no need to complain.
And I like the XIDE debugger much better than the VO one now....
Wolfgang

[ic2]

Thanks for your replies. Yes Robert, I know the difference between Release/Debug mode. Chris asked me to removed [System.Diagnostics.DebuggerHidden()]; from a project we sent to check some issue.

Your replies just confirm what I thought. It's just another (huge) step back from VO. It means that either debugging takes a lot longer if one uses small methods, because you need many more step outs during debugging than in VO. Or it means a lot of manual work if you want a few removed temporarily and set again later.

Chris I totally agree that it doesn't make sense to complain abut everything which you can NOT (quickly) do in .Net/VS - it is what it is. I mainly ask it when I come around something hoping I overlooked a better solution, but often there isn't indeed.

For me the productivity boost only shows when I continue with VO after having worked a while in VS (regardless in which .Net language) :unsure:

Dick

[Chris]

Hi Dick,

I did not say that you must not complain, I also complain all the time . I only said you need to accept that .Net languages are file based, there's no repo, so you need to use tools designed to work with files and not try to make them emulate how you would work in a repo-based environment.

About debugging only in a number of methods, you simply need to set breakpoints in the methods that you are interested in, it takes a few seconds and does not even need a recompile of your code. And you can put breakpoints only in the relevant pieces of code inside your method, so the debugger will stop there only when this particular code is being executed, not every time you enter the method. I really cannot understand in what sense the way of doing it in VO is better in this case (not saying it is not good, just not seeing any advantage).