Backing up a C# project
-
When I edit video recording I backup the video project every time I make a few changes that way if something does not work then I can go back to a previous project backup eg Gardens1.veg Gardens2.veg etc I am hoping that you can do the same when writing a C# program but can't see any way of doing this. I normally select 'save all' so that everything is saved. Brian
-
When I edit video recording I backup the video project every time I make a few changes that way if something does not work then I can go back to a previous project backup eg Gardens1.veg Gardens2.veg etc I am hoping that you can do the same when writing a C# program but can't see any way of doing this. I normally select 'save all' so that everything is saved. Brian
Welcome to the tribe of devs who need version control/back-up software ! imho, it's a strange "empty" that Visual Studio doesn't provide a simple menu command to back-up an entire project/solution ... for the single developer. This post gives a useful overview of what you might look into to determine what you need: [^]. I sometimes put a shortcut to the current VS solution folder on the desktop, and then duplicate (the contents of) that as necessary: not elegant ! I did create my own solution for this (just code, not a VS extension), but, it was quirky, and I had to use try/catch to avoid access errors for certain locked VS run-time hidden files: I stopped using it :)
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
-
When I edit video recording I backup the video project every time I make a few changes that way if something does not work then I can go back to a previous project backup eg Gardens1.veg Gardens2.veg etc I am hoping that you can do the same when writing a C# program but can't see any way of doing this. I normally select 'save all' so that everything is saved. Brian
Backups and version control are very different beasties! Version control is pretty easy with all .NET languages - GIT support is built in to Visual Studio these days, and that allows you to use a local of remote (like BitBucket or GitHub - the latter is better IMHO) and that provides you with full source control. Google "Visual Studio GitHub" and you will find loads of explanations. Backups aren't normally "single project" related, but that's easy enough to do. The only warning I would give is that a backup regimen should be a bit more complex than source control simply because backed up data should be "air gapped" to prevent corruption when things go seriously wrong! Have a think about exactly what you are trying to achieve: I use source control and backups and it takes both care and thought (as well as time) to get it right. And always, always, always: do a trial restore of any mechanism to make sure that you can use the data before you assume it's right! There is nothing worse than being confident in your backups and finding out they are rubbish exactly when you need them to be perfect! See here: Don't Hit Save - The Screwup[^]
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
Backups and version control are very different beasties! Version control is pretty easy with all .NET languages - GIT support is built in to Visual Studio these days, and that allows you to use a local of remote (like BitBucket or GitHub - the latter is better IMHO) and that provides you with full source control. Google "Visual Studio GitHub" and you will find loads of explanations. Backups aren't normally "single project" related, but that's easy enough to do. The only warning I would give is that a backup regimen should be a bit more complex than source control simply because backed up data should be "air gapped" to prevent corruption when things go seriously wrong! Have a think about exactly what you are trying to achieve: I use source control and backups and it takes both care and thought (as well as time) to get it right. And always, always, always: do a trial restore of any mechanism to make sure that you can use the data before you assume it's right! There is nothing worse than being confident in your backups and finding out they are rubbish exactly when you need them to be perfect! See here: Don't Hit Save - The Screwup[^]
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
Hi, I'm curious about what you use for back-ups ... assuming you are automating that in some way: fyi: I interpret "version control" as implying some form of back-up/archiving. cheers, Bill
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
-
Hi, I'm curious about what you use for back-ups ... assuming you are automating that in some way: fyi: I interpret "version control" as implying some form of back-up/archiving. cheers, Bill
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
AOMEI Backupper and a bunch of 4TB USB drives! Version control shouldn't be seen as a backup - or at least not a "primary" backup - the data is out of your control (unless it's a local hub and then it's not air gapped and probably on the same machine). And we've probably all heard "Git lost the lot!" sob stories, though this can help: Oh, shit, git![^] What I do is use Git for source control, and archive "released to client" software to air gapped RAID 5 backups which live in a friends garage when I'm not using them, as well as "normal" regular backups of my whole system as AOMEI images. And I copy whole folders to my 16TB RAID 5 NAS when I'm feeling especially nervous about making changes. I think the most work I've completely lost in the last 20 years is about ten minutes. It's not paranoia if HDD's really are out to get you! :laugh:
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
AOMEI Backupper and a bunch of 4TB USB drives! Version control shouldn't be seen as a backup - or at least not a "primary" backup - the data is out of your control (unless it's a local hub and then it's not air gapped and probably on the same machine). And we've probably all heard "Git lost the lot!" sob stories, though this can help: Oh, shit, git![^] What I do is use Git for source control, and archive "released to client" software to air gapped RAID 5 backups which live in a friends garage when I'm not using them, as well as "normal" regular backups of my whole system as AOMEI images. And I copy whole folders to my 16TB RAID 5 NAS when I'm feeling especially nervous about making changes. I think the most work I've completely lost in the last 20 years is about ten minutes. It's not paranoia if HDD's really are out to get you! :laugh:
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
That's enlightening, thanks ! p.s. could you please send me one of those 16TB Raid 5 critters asap ?
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
-
Backups and version control are very different beasties! Version control is pretty easy with all .NET languages - GIT support is built in to Visual Studio these days, and that allows you to use a local of remote (like BitBucket or GitHub - the latter is better IMHO) and that provides you with full source control. Google "Visual Studio GitHub" and you will find loads of explanations. Backups aren't normally "single project" related, but that's easy enough to do. The only warning I would give is that a backup regimen should be a bit more complex than source control simply because backed up data should be "air gapped" to prevent corruption when things go seriously wrong! Have a think about exactly what you are trying to achieve: I use source control and backups and it takes both care and thought (as well as time) to get it right. And always, always, always: do a trial restore of any mechanism to make sure that you can use the data before you assume it's right! There is nothing worse than being confident in your backups and finding out they are rubbish exactly when you need them to be perfect! See here: Don't Hit Save - The Screwup[^]
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
Thanks for your reply and the replies of others to my question on backing up C# code. I'm thinking that it might be easier to zip up the project folder for the project that I'm working on and add version numbers to the zip file. If something does go wrong then am I able to restore the zip file or does Visual NET write information elsewhere other than in the project folder? Brian
-
Thanks for your reply and the replies of others to my question on backing up C# code. I'm thinking that it might be easier to zip up the project folder for the project that I'm working on and add version numbers to the zip file. If something does go wrong then am I able to restore the zip file or does Visual NET write information elsewhere other than in the project folder? Brian
So long as you're not doing anything with source control, everything is in the project folder.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak
