Debugging in Visual Studio

More
8 months 1 week ago - 3 months 2 weeks ago #1 by ic2
Debugging in Visual Studio was created by ic2
Regular readers will know that I dislike Visual Studio very much, especially compared to programming in VO. Main problem is the fact that you can not isolate an entity so .prg/.cs based code with all code in it in some random order and unsortable on last changed/added leaves a cluttered mess.

Also high in my VS annoyance top 10 is debugging. I have posted multiple messages about this in newsgroups since 2013. I didn't really get a solution, one of the suggestions then was that multiple VS versions could cause the extra steps but as I have VS 2015 only on a system which has seen a full new W10 installation and no other VS version since, this can't be the cause. As now we have this forum with easily accessible attachments I have compiled a PDF with the 8 steps/screens I have to go through before I can start debugging while in VO, with Debug status on, I can do the same at once.

In the preview the link to the PDF didn't seem to work. If it still doesn't, please use www.ic2.be/VS/VSDebugging.pdf and change the https to http (the forum editor changes an url in https!)


I would especially like to hear from those of you who wrote earlier how much better VS was in their eyes than VO. Basically I've got 2 questions:

1) Do you experience the same steps as I show in the PDF on getting a run time error (as unhandled exception)?
2a) If no, what did you do to prevent this?
2b) If yes, why then do you consider debugging better than in VO?

Dick

This browser does not support PDFs. Please download the PDF to view it: Download PDF.
Attachments:
Last edit: 3 months 2 weeks ago by ic2.

Please Log in or Create an account to join the conversation.

More
8 months 1 week ago #2 by Chris
Replied by Chris on topic Debugging in Visual Studio
Hi Dick,

You need to press many more buttons, because you are not using VS the way it was designed. Not saying I prefer this way or not, but in VS you are supposed to always (or usually) start your app from the IDE by clicking on the green arrow button, which starts your app in debug mode. When you do that, when an error is found in your app execution, it will be shown instantly, with no additional windows etc.

What you did instead of that, is that you run the .exe directly. Try doing that in VO, run the .exe directly, will you have any option to debug the app if a problem arises? I think there's no possibility at all. Only thing you do is to run it from within the IDE, VO opens the app in special mode, ready for the debugger. So you need to do the same thing in VS (or in XIDE), run the app in the Debugger ready mode.

About the error itself, the very first window shown when debugging starts says "Collection was modified; enumeration operation may not execute". The debugger is pointing you to a line of code where you are using foreach in the iSelection collection. That's it, no more other info needed, most probably you are modifying iSelection inside the loop that enumerates it and this is not allowed. Should be easy to fix this. In case you do really want to modify it within the loop, don't use foreach, but use a custom for loop, in which you can do anything you want with the collection.

Chris

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
8 months 1 week ago #3 by ic2
Replied by ic2 on topic Debugging in Visual Studio
Hello Chris,

Well, this is the reply I hoped for! You are absolutely right - using Start Debugging indeed directly goes to the error. That's great to know; thanks - I've been asking this multiple times and now we see that a picture says more than 1000 words.

However, I do not completely agree with your comparison of VO. The point is when I start debugging, in both VO and VS, the program will also stop at every breakpoint which may be unwanted. But in VO, with debug on, and starting Run instead of Debug, I still get directly to the program line with the error. That is different from running an exe. VS does not do that (maybe there is a setting to run the debug mode without stopping at breakpoints?). So I still think VS is doing the job worse, but with a bit of compromising it's by far not as bad as I experiences so far.

PS: The error itself I already solved. Actually it was partly caused by the fact that C# is difficult to read with all the accolades - I put a refresh statement (changing the collection) within instead of just outside the Foreach loop. This is of course well avoidable (VS Professional shows a tooltip since 2015 telling which statement a } closes) but, as many things compared to VO, it's almost always more effort to get things working.

Dick

Please Log in or Create an account to join the conversation.

More
8 months 1 week ago #4 by ic2
Replied by ic2 on topic Debugging in Visual Studio
I have one additional remark. From my comments it looks like I hate VS in every respect and find nothing positive. That is not true. The problem I experience is that using VS is often more cumbersome than using VO in a couple of fields I consider most important - which means it's more time consuming.

In the meantime I found that I can disable all breakpoints (without deleting them) from the Debug menu which means that with a small extra step, VS debugging will actually be better than VO (yes, I admit!) - however only on using C# . Reasons:

1) I don't have to set (AEFs/MEFs/entities) to debug mode on for one or more parts of the program which is the only way to do it in VO as end users exe's with debug standard on my fail sometimes. That's good.
2) Inspecting VO variables like arrays goes only to 64 steps. In VS I have not yet seen a limit.
3) The immediate mode is more comprehensive than VO's Ctrl X. However - that goes for C# (and maybe VB). For Vulcan compatible debugging, I have to translate the commands to C# and they are also case sensitive which makes it a bit of a guess to enter them.

So in short: with my freshly gained knowledge, C# debugging is better than VO debugging. But because of -the important- problem in 3) I still think VO debugging is much better than Vulcan compatible debugging in VS. I have not yet tried Core X#, maybe the immediate window works there with 'untranslated' commands?

Dick

Please Log in or Create an account to join the conversation.

More
8 months 1 week ago #5 by Phil Hepburn
Replied by Phil Hepburn on topic Debugging in Visual Studio
Dick,

Life will be 'more sweet' for you if you just give up comparing VO and the repository with VS etc., etc.. There seems little to no point.

Just move forward, and learn to use VS in the best way possible, and get useful tips from your colleagues. I did this many years back and I have never looked back. And I am far from being and expert - BUT - I seem to survive quite satisfactorily.

VS is a different way of doing things - so just go with the flow ;-0)

Best regards,
Phil.

Please Log in or Create an account to join the conversation.

More
8 months 1 week ago #6 by ic2
Replied by ic2 on topic Debugging in Visual Studio
Hello Phil,

Currently I spend 90% of my programming time in VO. I won't go that far that I call it fun all the time but most of the time I am pretty satisfied with how I can manage my code in VO.

Now X# is an excellent product. After some preliminary work from 2 students of Fabrice at one client, using the latest VOPorter I think technically I could get a working version of the programs I maintain in X# as the current versions just works.

However: my VO programs work fine. Most are pretty mature and 99% of the coding can be done in VO very well. For example: a WPF screen has way more options than a VO screen and XAML code can be programmed. Sure. But using the window editor, I have far less problems building windows in VO than I have in VS. I estimate getting my WPF screen right takes me twice as much time. Always a control 'lands' in the wrong Grid.Row or isn't visible because by putting a control somewhere VS has given it some margin of 1500 or whatever- and the XAML code is just as much as a mess as the prg/cs programs. In my C# program, I also have a lot of these inefficiencies. For example: I spend a lot of time replacing spaces with tabs in comment lines because when you copy code, VS isn't smart enough to keep tabs.

So "going with the flow" is going to make my programming work a lot more unpleasant and more time consuming.

That's why I compare and why it makes sense too. Should I keep my well working VO code, or move it to X# which -for this code and in the current circumstances- does not bring me much advantages but, mainly due to the lack of repository and having to deal with a lot of Visual Studio quirks, will definitely bring me many disadvantages.

One more comparison. Currently governments want to have everyone in electric cars. Should you be in for a new car, it makes sense to go with the flow and buy an electric car, right? You get zero emission, quiet, tax exempts, and the latest technology to operate the car. But it means that you'll always be stressed for reaching your destination or face searching charging station and multiple long waiting times on longer distances. And a car like a Tesla can only be operated with touch screens which makes (IMO) driving it more dangerous than using a mobile phone while driving.

So that's why people compare. Lot's of people don't buy an electric car nowadays. And lot's of VO users stick to VO. Oh yes, it will change, gradually. But there are often good reasons stay away from the flow.

Dick

Please Log in or Create an account to join the conversation.

More
8 months 1 week ago #7 by wriedmann
Replied by wriedmann on topic Debugging in Visual Studio
Hi Dick,

maybe my situation may be interesting: Currently I pass between 50% and 90% of my programming time in VO, but the pressure to move to X# comes from several sides:
  • more and more things I need are available only in .NET. Latest example was the webservice interface of a supplier that I needed to send orders. With X# and a COM module it was less than a day of work - in pure VO it would have been much, much more.
  • customers are making pressure to have more modern interfaces, at least WinForms, but better WPF.
  • and I like it very much to work in X#, more than in VO now - but I use XIDE

Therefore I have a precise migration path: all of my applications that are in active developments will be moved over to X# the next 18 months.
Two of my standard applications (my invoicing and my accounting software) that are too large to be rewritten from scratch should be moved to WinForms using a VO GUI compatible WinForms library.
New applications will be written completely in X# and WPF.

Wolfgang

Please Log in or Create an account to join the conversation.

More
8 months 1 week ago #8 by Phil Hepburn
Replied by Phil Hepburn on topic Debugging in Visual Studio
Arrrh ! - there lies the difference I feel.

I am looking forward to the first of many 'E' cars that I will own and enjoy driving ;-)

Vive la difference !!!

Phil.

Please Log in or Create an account to join the conversation.

More
8 months 1 week ago #9 by Phil Hepburn
Replied by Phil Hepburn on topic Debugging in Visual Studio
Arrrh ! - there lies the difference I feel.

I am looking forward to the first of many 'E' cars that I will own and enjoy driving ;-)

Vive la difference !!!

Phil.

Please Log in or Create an account to join the conversation.

More
8 months 1 week ago #10 by Chris
Replied by Chris on topic Debugging in Visual Studio
Hi Dick,

This is exactly what I was about to suggest you, to disable breakpoints at will. I also liked VO a lot (well, wrote a whole IDE making it similar to it!!), but in my opinion, once you are used to the .Net way of doing things, it also feels natural, same as VO does. For example, personally now I don't miss VO's repository (which I had been using for many years of course) at all, while in the beginning I didn't think I could cope without it. Now when I go back to VO, it feels a little strange that I do not get by default to see all of the code in the module and need to hit CTRL+M instead :)

About the debugger, I think once you are used to it, it offers a lot more possibilities. For example the Set Next Statement option, which changes the active line to a different one, allowing to skip a few lines of code, or go back to a previous one, while you are debugging. I don't know how I could debug in VO without that in the past! :)But, yes, I agree, it needs improvements in order to make some features work better with x#. Making the evaluation accept x# syntax is one of the items in the todo list. Btw in XIDE this is semi-implemented, but not fully yet.

Btw, Getting with the flow is for me the absolute exact opposite of my philosophy in life (sorry Phil :)), so I wouldn't suggest you to embrace "the new way" just for the sake of it, but just because (I am sure you will eventually find more and more proof for that) it makes your programming work more efficient, powerful, productive and more fun. I realize it's not how you see it now, but I think you will eventually agree with that.

Chris

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
8 months 1 week ago #11 by ic2
Replied by ic2 on topic Debugging in Visual Studio
Hi Phil,

You write "enjoy driving".
I hope you enjoy waiting as much - you will often have to do it, and you get very looooong breaks, after trying to find a charging station. That is, if you haven't crashed because you were trying to get your windscreen wipers on which may be hidden 3 submenu's from your current view on Tesla's touchscreen.

I would love to drive a non petrol car too but only when I can drive a 1000 km and then recharge in half an hour at most. As this may be technically impossible, my waiting may result in a hydrogen car from which I can wave to the electrical car owners while driving past the charging stations were they have to spend the next hour.

Dick

Please Log in or Create an account to join the conversation.

More
8 months 1 week ago #12 by ic2
Replied by ic2 on topic Debugging in Visual Studio
Hello Wolfgang,

I fully agree with 1) - we do the same. To my own surprise, 2 doesn't seem to matter - when I replaced my Vulcan created WPF screen with a VO screen again because when it was displayed Sven's toolbar stopped displaying text+icons for some unknown reason, nobody reacted negative. Instead I got one reaction saying they liked the new screen better....
And about 3 - with XIDE it's partly a different story - but for Winforms applications.
Dick

Please Log in or Create an account to join the conversation.

More
8 months 1 week ago #13 by wriedmann
Replied by wriedmann on topic Debugging in Visual Studio
Hi Dick,

And about 3 - with XIDE it's partly a different story - but for Winforms applications.


As you know, I have opted for code-based WPF screens because I feel there is much less code and more oversight over my code.
But yes, sometimes I'm missing a sort of an graphical editor....

Wolfgang

Please Log in or Create an account to join the conversation.

More
8 months 1 week ago #14 by ic2
Replied by ic2 on topic Debugging in Visual Studio
Hello Chris,

With the knowledge you gave me today, and as soon as I have finished converting Vulcan to X#, and re-installed VS 2017 (Set Next statement is not in VS 2015 and getting VS 2017 to work is a challenge but let's assume for a moment it works) you may be right for C#, but not -yet- for Vulcan compatible code. The most important thing in a debugger IMO is the ability to run some code to see the result of some actions on a variable. In the immediate window I can not issue Vulcan/X# commands. In VO I can issue VO commands and it works. Without X#/Vulcan code working in the immediate window there's no way I can gain productivity. I have tried it a few times, entering all kind of case combinations and finally gave up, stopped my code and programmed temporary windows to show me results. In VO I would have had this result 10 minutes earlier....

But it's great to hear it's on the ToDo list. I thought it was not possible to implement it.

I agree with you that you eventually get used to everything. If new cars will come with square wheels everyone will forget how much more comfortable the round wheels were unless they still own such a car. VO's repo obviously being the round wheels.

Maybe this is (partly) a solution to my problem vlasovstudio.com/task-canvas/ . I'll check that out. Phil may think I oppose everything new but this isn't the case; I oppose everything making my life harder and unfortunately this is too often the case with new technologies. I am now working with VS since VS 2010 so it's not new but my feeling towards it is unfortunately unchanged- it is always a relief to go back to my VO programming.

Dick

Please Log in or Create an account to join the conversation.

More
8 months 1 week ago #15 by Chris
Replied by Chris on topic Debugging in Visual Studio
Hi Dick,

SetNextStatement has been available at least since VS2010, even VS2008 or previous probably, if it's not visible then you probably need to tell VS to show it. Or it is hidden in a submenu or something :). about the X# syntax in evaluation, yes, I absolutely agree, this is important to be implemented.

Regarding getting used to things, you may know that I, like you, absolutely hate and never do that, just for the sake of doing it. For example I completely refuse to use some things in newer windows versions the way MS "wants" us to, so first thing I do is to install the Classic Explorer and stuff like that, which make things work again in an intuitive and practical way (IMO) and not the way MS tells us they and we should work.

So when I am suggesting that you will be used to the .Net way of doing things, I don't mean that you will learn to live with it, but I think you will find that it is in many (not all) ways better than what you use now. For your analogy, I would describe VO as a very good tire designed to handle speeds upto 320 km/h (200mph for our imperial friends :)) in dry conditions without issue. On the other hand, .Net possibly is a tire that can handle upto 250 km/h, but can also handle wet roads, snow, ice, extreme heat, allows 3rd parties to easily further enhance its characteristics etc. And it lasts much longer :)

Chris

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
8 months 1 week ago #16 by NickFriend
Replied by NickFriend on topic Debugging in Visual Studio

Dick wrote: Hello Chris,
Maybe this is (partly) a solution to my problem vlasovstudio.com/task-canvas/ . I'll check that out. Phil may think I oppose everything new but this isn't the case; I oppose everything making my life harder and unfortunately this is too often the case with new technologies. I am now working with VS since VS 2010 so it's not new but my feeling towards it is unfortunately unchanged- it is always a relief to go back to my VO programming.


This looks like a terrible idea, as all it's doing is encouraging you to try and work against the way projects are structured in VS, and so prolong your agony of adapting. If you need to edit several different files, just open them all up and spread them around over a couple of monitors since you can easily drag windows out of the VS shell (unlike with VO).

To be honest it seems to me that the only reason you can't progress with VS is because you're not actually willing to spend the time to learn how to use it. All your suffering with debugging would have been avoided by 30 seconds looking at the Debug menu so that you could choose "Start Debugging" instead of "Start without Debugging". VS is a large complex program which needs to be learnt to be able to take advantage of it.

Nick

Please Log in or Create an account to join the conversation.

More
8 months 1 week ago #17 by Phil Hepburn
Replied by Phil Hepburn on topic Debugging in Visual Studio
So would you have an electric car fitted to your nice new shiny tyre ?

P.

Please Log in or Create an account to join the conversation.

More
8 months 1 week ago #18 by Chris
Replied by Chris on topic Debugging in Visual Studio
Hi Phil,

Phil Hepburn wrote: So would you have an electric car fitted to your nice new shiny tyre ?


:)

If it doesn't have the big disadvantages Dick mentioned, then absolutely yes!

Chris

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
8 months 1 week ago #19 by ic2
Replied by ic2 on topic Debugging in Visual Studio
I learned a lot today - indeed the command is in the right mouse menu. I can imagine this to be handy. And I think your "tire" comparison is brilliant and true - there might actually be a point where the sum of VS features outweigh the sum of VO features for me but with me relying on navigating through last changed/programmed entities and the intensive use of Ctrl X for debugging, at this moment I prefer the 'speed tires'.

I just installed the above mentioned plug in and it does allow me to edit 1 entity in a separate window - you see that changes are simultaneously done in the main window. It's $ 49 which I think is reasonable. Let's see if it also could offer accessing latest changes. If so, and with X# command working in the immediate window, I will have a good incentive to move to X#+VS.

Dick

Dick

Please Log in or Create an account to join the conversation.

More
8 months 1 week ago #20 by ic2
Replied by ic2 on topic Debugging in Visual Studio
Hello Nick,

I think you misunderstand this. I am not talking about opening multiple files. I am talking about opening just one entity without the chance to accidentally change (read: delete) code of a next method, which happened to me in VS more than once. And find back quickly what I was editing last. You can't in VS. Or can you? If so: how?

Now Nick, just look objectively at the organization of code in VO, where you see a sortable list of entities (sortable on last changed, creation time, type and more) compared to a prg/cs in VS with all code randomly dropped somewhere. Unless you spend a lot of time with half baked "solutions" like regions or manually moving code - which is a lot easier from a VO browser anyway.

So I don't have an agony of adapting, but an agony of being forced to work with less efficient tools.

Finally, no doubt I am not aware of certain VS options which could be useful. But of course I know the difference of Start Debugging and Start without debugging. Only in VO you don't need to make that choice to allow efficient debugging of run time errors (as long as Debug is on, that is). So I never realized that in VS you have to.

Dick

Please Log in or Create an account to join the conversation.