xsharp.eu • Debugging in Visual Studio - Page 8
Page 8 of 8

Debugging in Visual Studio

Posted: Fri Feb 16, 2018 2:34 pm
by Phil Hepburn
Hi Dick,

Unfortunately some of us (me included) do not have the luxury of being able to stick with VO.

In fact I can't stick with Vulcan either due to missing LINQ and related technology.

And, I can't even stick with good old XIDE, because I need WPF and it designer surface.

So I have to get the best from Visual Studio and its related tools.

As Terry said in a very recent post, VS is surprisingly straight forward to use once we stop worrying about its complexity, and just get on and use it.

It is visually confusing at times, but conceptually simple enough.

However, to my mind a well thought out session on VS at a conference, would do a lot of guys some good I am sure. And all of us can learn a few things even if we are day to day users.

Good luck with all your projects.
Cheers,
Phil.

Debugging in Visual Studio

Posted: Sat Feb 17, 2018 3:31 pm
by robert
Dick,

When I close a solution in VS and then reopen it (a day later for example) then all the documents are reopened just like they were in the last run. My breakpoints are restored as well as my bookmarks.
I have never a problem to see where I was working the last time.
Don't you see that ?

Robert

Debugging in Visual Studio

Posted: Mon Feb 19, 2018 10:25 am
by Phil Hepburn
Hi Robert and all,

Yes Robert, and as well as being exactly as you describe, it is even more useful I find. I enclose/insert a couple of images to explain what I mean.

I use the taskbar a lot to launch my VS apps in development, and often have two or three instances of VS open at once - simply because of my eNote writing. See below for my VS desktop situation :-
VS_saved_IDE_Settings_01.jpg
VS_saved_IDE_Settings_01.jpg (32.81 KiB) Viewed 437 times
When I open two or three of these different solutions, from the taskbar roll-up menu, I get the solutions opening in VS (like you say) with all the documents and tabs open and displaying just like when I closed/exited from VS. But, the SE pane is also set as it was - AND - all and any uncommitted 'SC' red ticks are also visible. Below is an example of what we are saying, with a couple of indicators showing the uncommitted files/folders :-
VS_saved_IDE_Settings_02.jpg
VS_saved_IDE_Settings_02.jpg (84.78 KiB) Viewed 437 times
Finally, the drop down list shows the tabs which were left open / available in the editor region/area :-
VS_saved_IDE_Settings_03.jpg
VS_saved_IDE_Settings_03.jpg (69.19 KiB) Viewed 437 times
So it would appear that the IDE settings for each solution seem to be save along with that solution, so that all solutions can be re-opened and appear exactly as they were when the VS shell was closed.

The only thing I do when closing the VS IDE while working on a solution is 'Ctrl+S' to save my changes, which is probably not necessary, but habit. I don't always do a SC commit as often I did that recently and prior to the close down. And I never close any tabs before closing the VS shell - I just continue working as I was, the next time I open the project/solution.

I often have mixed projects in my solution X#, C#, and XAML, and everything so far looks to works exactly as described above.

Please can you tell me, does this also work like described above, if I RAR up a project/solution and send it to a colleague ? Does it open just as it was left by me in my VS IDE ?

HTH a few guys getting into using VS.
Have a nice day,
Phil.
Wales, UK.

Debugging in Visual Studio

Posted: Mon Feb 19, 2018 3:13 pm
by ic2
Hello Robert,

I have never a problem to see where I was working the last time.
Don't you see that ?


Yes, but although I talk about 'last time' I often mean 'recently'. The entity I've been working on last week, or even the one I was working on just before I changed e.g. a typo - that's the one I can not find back easily. That the cursor is again where I was working on last time is often not what I need to know.

Apart from that, more than once the whole fragile configuration of open windows and positions is lost. Than I have to dig into my documentation again how to have the solution explorer and other windows where I want them. Because of that I more or less gave up optimizing it - it's usually lost within a few weeks at most and one of the reasons of my antipathy against VS.

Dick

Debugging in Visual Studio

Posted: Wed Feb 21, 2018 9:18 am
by Otto
This is key for me: In our SCC is the truth, not in my repository/solution.

I agree, that the entity viewer in VO-IDE was a nice feature.

But, if I want to trace back what I did recently, I look for the checked out/changed icons in the repository/solution explorer, compare with the VSS version, or look directly in VSS, look through the check-in history etc.

In VS a coupling with TFS or Git, I can easily see what has changed for what supposed purpose.
What not was possible, and now it is: annotation of the source who changed what section, and when.

Debugging in Visual Studio

Posted: Wed Feb 21, 2018 10:03 am
by ic2
Hello Otto,


But, if I want to trace back what I did recently, I look for the checked out/changed icons in the repository/solution explorer, compare with the VSS version, or look directly in VSS, look through the check-in history etc.

As written earlier, SCC hasn't been helpful to me at all but once I have figured out how to determine where & how I can store my repos per project I may give it a second chance. Although I think I can't - I've seen requests to vary this per project since 2010 and it's still impossible. E.g. for one project you may want to store your changes in a cloud repo shared with others while for another project you want it only on your own Pc because the shared programmers on that other project have nothing to do with it.

Can't do that with VS, can you?

About finding the last changed code: I'm 100% sure that while you are still comparing and looking into check in histories in VS, I have already long opened the 1 or 2 entities in VO and am working on it. If I want compares, VOPP has automatically exported my AEF's daily, unlike the manual committing in VS.

What not was possible, and now it is: annotation of the source who changed what section, and when.

We do that in comment lines which IMO is clearer than external annotations. But if I would want to see it a glance, for every AEF, MEF and Entity in VO you can right click Properties and enter a description which is directly visible in the browser.

The VS/TFS Annotate options seems a poor men's version of that of VO to me; more work, less detail. But VS users seem to love that.

Dick

Debugging in Visual Studio

Posted: Wed Feb 21, 2018 12:40 pm
by Otto
Hi Dick,
Can't do that with VS, can you?
Not sure what you want to do here, but you can in TFS/Git make a project private or public, open to sets of developers. If needed, several acts can be automated in a build server etc.
One can branche and merge solutions/folders at ones own discretion.
Like we do/did in VSS. Merging in VS/TFS is easier than in VO/VSS.

Sometimes we lose some 'short cuts', but there are other things we gain.
Bytheway, I don't use annotate much, but 'shelving' (temporary check-in) etc constantly.

You improved your development environment by knotting tools to get backups etc. Why not accept that your wanted feature isn't available and just write it.

Have you ever used the VS debugger option setting the cursor back and repeat the statement that baffles you? Not possible in VO.
Ever tried to remote debug a program? Not possible in VO.
Ever tried to attach a debugger to a running program? not possible in VO.
The debugger of VO was slow in comparison to the debugger of Clipper.
Skipping set breakpoints? Not possible in VO, in Clipper it was though...

Do I still prefer Clipper? No...

I don't want to squabble. I suggest that asking 'how do I ...' is more future proof than 'I can't ...'.

Hope you find your tool, or create it. If you do, maybe I will use it too.

Regards,
Otto

Debugging in Visual Studio

Posted: Wed Feb 21, 2018 1:29 pm
by ic2
Hello Otto,

I suggest that asking 'how do I ...' is more future proof than 'I can't ...'.

That's basically why I started this thread - and that question, which I had asked multiple times since 2013, was finally answered to my satisfaction by Chris. The other issues which came up were answered too, which I truly appreciate, but most of the replies are IMO a poorer solution than we have in VO.

I think I basically hoped that I missed a solution which is there, like with the debug mode in the start of thread. But it seems that this is not the case and most users don't mind. I obviously value these options more than most users.

Apart from that you are of course 100% right. Against a couple of apparently missing options there are no doubt dozens of options which are a lot better in VS. Indeed not able to skip breakpoints for example is one of the VO things which makes debugging often more time consuming because you have to start over after clearing the breakpoint. And yes, VO still crashes a few times a week (although restarting takes a few seconds). There are a few other disadvantages and I am sure VS will have a few other advantages I (could) use.

I am not in a hurry to abandon VO, which means I have a choice. But I think I'll re-plan investigating SCC to see if, with some extra effort, can use it to find my last changed code. I will also make a short list of other nuisances in VS which may have a solution I am currently unaware of, in a separate thread. That together determines how fast I want to move my work to an environment which, despite years of regular working with it, I still dislike.

Dick

Debugging in Visual Studio

Posted: Fri Mar 02, 2018 10:26 am
by MathiasHakansson
Hi,

here's the functions that I use with C# and TFS to investigate changes. Often this needs to be done when tracking bugs and when trying to determine what kind of correction that should be made.

* Annotate
I really like this function. It answears two questions for me. Why was this source code line changed and who did it.

* View History (for a specific file).
This is a way to see what development items that has affected a certain file.

* Class View (View - Class View)
This function lets you navigate quickly to definitions of methods and properties in your classes. It automatically opens the correct source file and positions the cursor on the definition when you double click in it. You can also filter this window to see only items that contains a certain text.

* Code Map
Create a graphical view of where a class, method or property is used. A new window with the graphical view is created and you can expand it further with more dependancies if you like. The map can then be used to quickly navigate between usages by clicking on items in the map.

/MathiasH