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 http://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
Debugging in Visual Studio
Debugging in Visual Studio
- Attachments
-
- VSDebugging.pdf
- (206.19 KiB) Downloaded 78 times
Last edited by Frank Maraite on Tue Jul 03, 2018 4:57 am, edited 1 time in total.
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
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
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
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
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
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
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
-
Phil Hepburn
- Posts: 743
- Joined: Sun Sep 11, 2016 2:16 pm
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.
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.
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
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
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:
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
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
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
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
-
Phil Hepburn
- Posts: 743
- Joined: Sun Sep 11, 2016 2:16 pm
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.
I am looking forward to the first of many 'E' cars that I will own and enjoy driving
Vive la difference !!!
Phil.
-
Phil Hepburn
- Posts: 743
- Joined: Sun Sep 11, 2016 2:16 pm
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.
I am looking forward to the first of many 'E' cars that I will own and enjoy driving
Vive la difference !!!
Phil.
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
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
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu