Resolved Is it possible to debug without saving the project?

Crom

New member
Joined
Aug 20, 2020
Messages
3
Programming Experience
5-10
Hi all,

My first post after looking for a potential answer by my own. I was programming with VB6 (as a hobby and for my own bussiness) during many years and now I have decided to learn C# using VS2019 Community edition for my windows form projects.

When I was using VB6 I could make many changes (forms and code) in my project without saving. This way I could test if I liked what I was doing. If I made big changes and finally I wanted to discard them, I just needed to exit without saving and kept on with the project where I left it, previous to any change. I have tried to find the way to do this in VS but each time I start the degug process, it saves automatically the whole project, therefore if I do not like what I see and decided to come back to my previous version I need to revert my changes manually, which is crazy if there ara several changes. So .... is it not possible to debug without saving when I am developing a windows form project?

Bests to all you you. I hope to be a 'resident' in this forum.
 
Short answer: no. VS does let you undo through saves, though, as long as you stay within the same season. Personally, I recommend that you use source control instead. You can create branches, and merge the changes that you like into your main branch only if you like the changes. And the best part of source control: you can compare versions to see what changed.
 
Source control is indeed the way to go. A DevOps account is free and support is built into VS, but there are other options that are very easy too.

There's probably no need to create a branch in most cases for a lone developer. If you're in a team then you can test out changes in one branch while other members continue to make changes to the main development branch. As a lone developer, it's usually enough to just make changes on your main branch and then simply discard them to revert to the last synced state. Cloud-based source control is also very good if you might use multiple machines for development, because you can always work on the current code without having to copy manually between them.
 
Cloud-based source control is also very good if you might use multiple machines for development, because you can always work on the current code without having to copy manually between them.
That's what I do. Cloud servers and cloud services are way underrated. It's a great way to manage multiple projects, across a variety of servers/PC's in sync with that cloud. It's also easy for other developers to work with you on projects they have shared access too. Cloud servers are excellent choices if you want to deploy your source code in real-time onto your deployment servers from remote hosts with access to your cloud. I highly recommend the route of cloud technology personally.
 
Thanks to all of you¡¡¡. It sounds amazing to me that VB6 (30 years old!!!!) allowed to fully debug without saving and VS2019 can't. Manual source control or making backups of the source code looks like uncomfortable for this purposes, ¿isn't it?. What the haps with the forms if I made changes that I want finally discard?. Should I be copying all the project files previous to any 'creative' attempt when inspiration decides to meet me?. Obviously the process I followed with VB6 was not quite safe, because any critical fail debugging could made you lose the chnge I was testing, but at least you have a way of doing that. I think that after 30 years, VS should have included sort of a tool to efficiently control the project versions so you could go back to any of them.

Thanks again for your help. Great forum¡¡¡
 
It sounds amazing to me that VB6 (30 years old!!!!) allowed to fully debug without saving and VS2019 can't.
It sounds amazing to me that that was ever possible at all, but things were more primitive back then. Thankfully, there are better ways to do things now, as technology has advanced.
Manual source control or making backups of the source code looks like uncomfortable for this purposes, ¿isn't it?.
Source control isn't manual and making backups would be as simple as right-clicking a top-level folder and sending to a ZIP archive.
What the haps with the forms if I made changes that I want finally discard?
Using DevOps in VS 2019, discarding changes involves clicking the change count on the status bar to open the appropriate tab in the Team Explorer, right-clicking the top-level folder and selecting Discard. You're trying to build this up as something onerous but it's not. It's dead simple.
Should I be copying all the project files previous to any 'creative' attempt when inspiration decides to meet me?
Like I said, as a lone developer, you probably don't have to do anything. You just start making changes and then discard them if you decide not to keep them. The source control provider knows what the state of every file was when you last committed so it restores to that state.

That said, you are offered more flexibility if you want it. For instance, lets say that you have a deployed application and you're halfway through adding new features when the client wants a bug fix to the current Production version. What do you do? With source control, it's easy. You would have at least two branches - one for development and one for current Production. The development branch is the one your adding features to while the Production branch is the exact code that you used to deploy. You can now create a new branch by cloning the Production branch and work on that to create the required bug fix without affecting the actual Production code or your development branch containing half-finished new features. Once the fix is tested and ready to deploy, you can merge that branch into both the Production branch and the development branch, so the code you're adding the new features to gets the bug fix as well, without your having to code it twice.

This can all be done with a few clicks, so tell me again how uncomfortable it is using source control. It's something new so it's a bit scary but there are many thousands, if not millions, of developers using source control from various providers and they are all very thankful for it. Once you get used to it, you won't even think about it as it just becomes part of your workflow. Eventually, you'll wonder how you ever did without it and why you thought debugging without saving was a good idea.
 
It sounds amazing to me that that was ever possible at all, but things were more primitive back then. Thankfully, there are better ways to do things now, as technology has advanced.

Source control isn't manual and making backups would be as simple as right-clicking a top-level folder and sending to a ZIP archive.

Using DevOps in VS 2019, discarding changes involves clicking the change count on the status bar to open the appropriate tab in the Team Explorer, right-clicking the top-level folder and selecting Discard. You're trying to build this up as something onerous but it's not. It's dead simple.

Like I said, as a lone developer, you probably don't have to do anything. You just start making changes and then discard them if you decide not to keep them. The source control provider knows what the state of every file was when you last committed so it restores to that state.

That said, you are offered more flexibility if you want it. For instance, lets say that you have a deployed application and you're halfway through adding new features when the client wants a bug fix to the current Production version. What do you do? With source control, it's easy. You would have at least two branches - one for development and one for current Production. The development branch is the one your adding features to while the Production branch is the exact code that you used to deploy. You can now create a new branch by cloning the Production branch and work on that to create the required bug fix without affecting the actual Production code or your development branch containing half-finished new features. Once the fix is tested and ready to deploy, you can merge that branch into both the Production branch and the development branch, so the code you're adding the new features to gets the bug fix as well, without your having to code it twice.

This can all be done with a few clicks, so tell me again how uncomfortable it is using source control. It's something new so it's a bit scary but there are many thousands, if not millions, of developers using source control from various providers and they are all very thankful for it. Once you get used to it, you won't even think about it as it just becomes part of your workflow. Eventually, you'll wonder how you ever did without it and why you thought debugging without saving was a good idea.

You are absolutely right!!!!. When you mentioned source control, zips, backups,... I was wrongly understanding the process, thinking about manual ways of controlling the code and the files, but now I have found GitHub (what you were surely referring in the beginning) and it works excactly like you mentioned and it fits perfectly with what I was looking for. Total, easy and automatic control over the versions (local or cloud).

Thanks for your kind help.
 
Back
Top Bottom