Hi,

Sorry if this is the wrong forum...

I am using Microsoft Visual Studio 2019 and would like to know how to make a backup of my project. I need to re-install windows and would like to make sure I back up correctly.

Thanks in advance.

The simplest way to back up a project is to copy the files and folders to somewhere safe, such as an external or secondary HD. Of course to properly use the project later you'll need to reinstall VS and all the extensions and settings your current VS setup has.

There is nothing really special about a project's files, they are text files that contain data for the IDE.

Maybe after the win reinstall it might be a good time to consider installing VS 2022, your 2019 project files will work with 2022, maybe with a slight automated update.

Theres a few different ways you can do it. I personally save my projects in my google drive folder on my hard drive and it auto backs up to GD.

The second way is just to grab the entire folder of the project and back it up somewhere, you can move these around to a new PC and load them up, i've done so with all of my projects, if you dont know where they are, in VS in the solution explorer if you right click on the project name under the solution, there should be an option that says "Open folder in file explorer" which will take you right to it.

The third and easiest way is to just use the built in Git repo and backup your code to somewhere like github, then you dont need to even move the project folders at all, you can just pull your code from the repo.

I personally do a mixture of all three depending on the importance of the code.

Also i agree with George, upgrading to VS22 is a good idea.

Learn how to use Git 😏
https://git-scm.com/book/en/v2

There are many good reasons why you want to manage your code with an SCM (source code management) system, but one of the reasons is that once you are managing your code with Git, creating a "backup" of your local repo becomes as easy as:

Push all local changes to the Git server:

git push

Create "all in one" backup file (not just the latest state, but the complete version history!) of your local repo:

git bundle create my_backup.bundle --all


You probably want to create a .gitignore file for your Visual Studio project like this:

VS integrates github functionality within the IDE, making it easy to back up and restore projects.

I personally haven't done that with my projects, yet, 'cuz most of them are ephemeral "learn this or that" type projects.

@George P

I have, its great, really convenient and i highly suggest it for OP over just moving folders.

From what little I've read git/github integration was/is a bit twitchy with VS 2019 compared to 2022.

2019 and 2022 can coexist on the same machine. Of course installing two VS IDEs side by side can gobble up quite a bit of HD space. I did that with 2017 and 2019 initially, and then when 2022 was released I installed that along with the other 2 for a couple of days. I then uninstalled 2017, and a couple of months later did the same with 2019. So 2022 stands alone. 2019 IMO was getting rather creaky, more compile issues with C++20 and later code, and generally being more HD and RAM intensive and slower than 2022. YMMV.

Lately 2022 offers the ability to install preview editions side by side with the official release.

Pretty much the sole reason to stay with 2019 is if it is installed on a 32-bit machine, VS 2022 requires 64-bit. 2019 isn't getting updated as frequently as 2022, it is doubtful 2019 will get most C++23 functionality. 2022 will get it.

Yes, that should matter even if you don't use C++20 or later.

I was using non-MS compilers before VS 2015 was released and on a whim decided to install 2015. More and more I've gravitated away from primarily using non-MS compilers like Code::Blocks and MSYS2. It is possible to do command-line compiles using the VS engine. Maybe one day I'll do the research needed beyond just reading about it.

I'm a self-taught (badly) programming hobbyist, so what I know is rather narrowly scoped.

Oh, and if using 3rd party libraries is something done routinely consider looking into the MS created, community maintained package manager vcpkg.

https://vcpkg.io/en/index.html

Integrating it into the VS IDE is insanely easy. Installing and updating libraries with vcpkg makes a library's headers and libs easily findable by the IDE so you don't have to manually kludge the locations for every project. There's over 1,500 3rd party libraries available for vcpkg. Including Boost.

vcpkg will require git client being installed, but really a programmer should have it installed anyway.

There's a git port for Windows available, Git for Windows.

https://gitforwindows.org/

I have it installed and you can either use the Git Bash interface or the Git GUI.

Thanks for the suggestions.

My project is in a folder called source, the default location. I have been copying this folder to another drive.
I also copy my code to a txt file what I’m currently working on.

My main concern is the VS settings for my project. I had to go through hoops to get c++ working along with other things which I can’t remember. It’s been well over a year I have been working on my program.

Will I lose all my project settings when I reinstall VS? Or when I update it?

Those settings should all be in the *.vcxproj file(s) - one for each project. You should back those up, as well as your source code.

There's also .sln for the solution settings - and .vcxproj.filters and .vcxproj.user

When you update VS you'll keep the current global settings.

Also have a look at VS property sheets. There's loads of info about these on the internet.

[changed to .sln as below]

My main concern is the VS settings for my project. I had to go through hoops to get c++ working along with other things which I can’t remember. It’s been well over a year I have been working on my program.

Project-specific settings are stored in the .vcxproj file, user-specific settings (e.g. command-line parameters for debugging) are stored in the *.user file(s), and global Visual Studio settings are not stored in a file (in your project directory) at all.


Again, just manage your code with an SCM, such as Git, and add all files in the project directory to the repository, except for:

• The hidden .vs sub-folder – this contains temporary files generated by the VS IDE
• Any *.user files – those contain user-specific settings and therefore don't belong into SCM
• Any build artifacts, such as the generated object code and executable (or DLL) files

(You should create a .gitignore file to exclude the files mentioned above)

Once you have done that, you can simply check-out your code from the Git server on any machine and it should build right away!

https://gitforwindows.org/ I have it installed and you can either use the Git Bash interface or the Git GUI.

I much prefer TortoiseGIT over the "standard" (built-in) Git GUI:
https://tortoisegit.org/

Git For Windows, is a port of Git SCM.

https://git-scm.com/

For me the Bash/mintty console is more "user friendly", the GUIs are a bit off-putting. Yes, I have TortoiseGIT and TortoiseSVN installed, and I still prefer the command line console interface for most of my git usage. To access a TortoiseGIT feature requires spelunking into several submenus before the GUI starts up. YMMV.

Speaking of git....Pro Git, 2nd Edition is available in a free eBook version. pdf, epub and mobi formats and well as html.

https://git-scm.com/book/en/v2

The book is still being updated and revised, the last revision was 17 hours ago:

https://github.com/progit/progit2

If'n videos are your thang Git-SCM has several available:

https://git-scm.com/videos

There's also .sin for the solution settings - and .vcxproj.filters and .vcxproj.user

found those but I can't find the .sin file.

There are no SIN files, there are SLN files. The main "solution" files you can use to load your project/solution.

Typo.

Sorry - my bad. Yes, it's .sln not .sin. I've changed my post above. I'm blaming the gremlins...

Heh, I blame fat fingers.

To err is human, to really mess things up requires a computer.

I am old school, but all my coding stuff is under a single parent folder with the occasional smoke and mirrors with a mapped drive or mapped folder, which backup software can be told how to handle. That can be backed up easily. Git is version control, and while it does keep you safe from loss, it usually is missing your libraries, externals, and so much more.

One of the smoke and mirrors you can do (esp for visual studio) is to have the build folder be a linked trash folder that doesn't get seen by the backups, not necessary unless your projects are quite large, but at some point, when it saves gb of space, its useful.

I am old school, but all my coding stuff is under a single parent folder with the occasional smoke and mirrors with a mapped drive or mapped folder, which backup software can be told how to handle. That can be backed up easily. Git is version control, and while it does keep you safe from loss, it usually is missing your libraries, externals, and so much more.

If your project depends on any "third-party" libraries, then these should probably be managed by NuGet, vcpkg, Ivy or a similar package/dependency manager. In this case, simply add your packages.config to the Git repo, and add the "packages" (or whatever it is called) directory to the .gitignore file, so that the packages themselves will not be managed/stored in your Git repo. Once you check out the Git repo on a "fresh" system, the package manager will read the packages.config and re-download all required packages/libraries.


If your project includes any libraries as source code (e.g. from another repo/project), Git has a nice feature called submodules:
https://git-scm.com/docs/git-submodule

Simply put, a submodule links another Git repo into your "main" Git repo. The submodule will then appear as sub-directory in the "main" Git repo. Just be sure to use git clone --recursive when checking out the "main" repo, so its submodules will be initialized too.


Not sure what else you might be missing. But I think a project should be organized (preferably in Git) in such a way, that anybody can check out your repo on a fresh system, run MSBuild (or make) from the "untouched" project directory, and get a working binary.

yes, I use submodules for sure, the package managers seem like overkill for the 2 or 3 packages I use so those are directly installed/downloaded instead for now, probably not ideal. But that is sort of a fork off what I was saying .. I was saying my backups (not my version control) are still old school triggered off a single root folder with all the projects, libraries, everything inside. Compressed and offloaded to a USB every week or so, or after massive changes. That is, while I use git, I still do old fashioned full backups that get the compiled files and everything. Its probably silly, but git requires a lot of hand waving after a catastrophic fail (eg hard disk blooie): you have to compile everything and reinstall all the libraries and it doesn't even remember the folder structure exactly, only the subfolder structure. The old school way is a one click full restore and back up in moments ... I like having both.