I want to version my visual studio 2010 debug builds. I'm going to use git. Right now all the project files are in 'project' and the output binaries are put by visual studio in the directory 'project\debug'. I've read a few questions on here that have ignore lists for Visual Studio but most of them have an ignore list that ignores the binary files, like the obj exe idb pdb ilk etc.
If I want to be able to debug my exe in the future what files do I need to keep? Is there any reason to keep the obj files? Does VS use them at all during debugging or tracing a crash? I thought I should keep at least the the pdb files and the exe. So that would be project.exe, project.pdb and vc100.pdb. But what about vc100.idb, project.ilk, project.res... etc. Is there an ignore list that will ignore everything that isn't needed to keep binary builds but keep everything that is?
I want to make sure if a user sends me a crash dump or reports a problem at some point in the future that I can go back to the version that was being used and be able to debug it. I had also hoped to make the binaries and debug files available in a remote repo so that anyone else could as well. Thanks!
Don't keep binaries in version control. Instead, build from source.
Since the binaries are built from source, and you have the source versioned already, just re-build the particular version as-needed. It will both keep your version control system lean and fast, as well as not cause merge headaches (which binaries are notorious for).
So, the answer is don't keep any binaries in version control.
If you feel you really must keep them, however, then just zip them up and store them like normal files using the tag of the build they came from.
I'm going to keep project.exe and project.pdb in the branch. The other files like *.obj, *.ilk, and *.sdf are not needed. Neither are the vc100.* files. I made my decision after speaking to a number of people in person and reviewing this:
File Types Created for Visual C++ Projects
and this:
Which Visual C++ file types should be committed to version control?
Although that SO question/answer does not answer my question it gave me a lot of good information. I also looked through my project.pdb for all the file references to confirm which files in my project that I needed to keep around. I used this command from the debugging tools for windows:
srcsrv\srctool -r project.pdb
Related
In my company, people used to work with Visual SourceSafe, but some years ago they decided to start working with GIT.
I started working here some months ago, and as such I've never set up a Visual SourceSafe environment.
While debugging dumps from older versions, this is giving problems: it seems that the dumps (taken using procdump) contain commands for retrieving source code, using Visual SourceSafe.
I've just installed Visual SourceSafe, and I was hoping that this would make it possible to get the older versions of the source code, but this is not the case. (For your information, even after having installed Visual SourceSafe, I don't see any SourceSafe information in Visual Studio's "Team Explorer - Connect" window)
(the original question contains quite some investigation information, which seems to be obsolete now that the answer of this question is known)
How things are related
[...] it seems that the dumps (taken using procdump) contain commands for retrieving source code, using Visual SourceSafe.
A crash dump does not contain commands. It contains version information about the EXE and the DLLs that were loaded. WinDbg and Visual Studio will then look for PDB files which match that version information. The PDB file then contains information about the source code.
To find PDBs, you need a symbol server and/or a local path with symbols.
SourceSafe
I've just installed Visual SourceSafe, and I was hoping that this would make it possible to get the older versions of the source code, but this is not the case.
Installing SourceSafe does not help. You'll need to connect to a repository using Visual SourceSafe Admin and grant yourself access rights.
Then, using Visual SourceSafe (not Admin), map a local folder ("Set working folder") and pull ("Get latest version"). You then have the source code locally and you can instruct your tools to use that path. For WinDbg, .srcpath and .lsrcpath should be correct.
You might need to get different versions by date if you really want to analyze with source code. To automate this process, you would need a source server, but you would know if you have one.
The age of the dumps
You say:
[...] some years ago they decided to start working with GIT.
So your source code should be in GIT, not in SourceSafe.
If your crash dump file is so old that it refers to SourceSafe, then consider it as obsolete and take a new dump. If nobody complains about crashes recently, I would no longer care (saying that as a former Test Manager).
Unbelievable: the issue is caused because the SourceSafe installation seems not to be complete:
In order to get it working, the following needs to be done:
Add the SourceSafe directory to the $PATH$ environment variable (C:\Program Files (x86)\Microsoft Visual SourceSafe)
Create the $SSDIR$ environment variable in order for SourceSafe to know where to look for the source code (should refer to the directory, containing the srcsafe.ini file).
I am new to TFS and I'm trying to add some custom library files that the whole team uses into Team explorer in Visual Studio. It's library files of Sahi Testing tool so that any changes made to the files can be seen on all machines. I have tried searching online but could not find exactly what I want. Help
Basically, you have the following options:
If you have Nuget Packages for the libraries, you do not necessarily have to add the packages to source control and restore them when you need them. See this link for details.
As an alternative, you can add libraries as binary files to source control so that each developer or build server can retrieve them together with the source code. It's a good practice, to add them to a special location so that they are located in one place and not spread over the solution. However, only use this approach for binaries that do not change too often. Otherwise, you might bloat your TFS database if the files are large and change very often.
I'm using Bazaar and Visual Studio 2010 in a C# project. I have prepared an ignore list but still I think all the files in Solution Output directory could be ignored.
I search a lot but nobody had mentioned it. So I'm going to know if I can ignore this directory because output files are changing regularly and seems are not important for repository copy.
What do you suggest about this issue ?
In general, any file that is automatically generated by compiler or build tools should NOT be committed into source control. This includes object files, executables, generated resource files, symbols, etc. Committing those files does not serve any useful purpose. Also, sometimes there are configuration files which look like can be committed, but really should not if they only contain local user specific info - for Visual Studio there are *.user files.
By that logic, solution output folder should be always put into ignore list.
How can an incremental build using IncrediBuild detect when a source file has been deleted?
When I modify a source file it will be recompiled and the corresponding dll relinked -- but deleting the same file does nothing, even when a complete rebuild would fail. How can IncrediBuild be instructed to check for deleted files?
UPDATE
I understand that Visual Studio behaves the same way, so it is not really a bug of IncrediBuild. Nonetheless I seek to remedy this situation in a Good Way. Considering that the files being deleted are known, perhaps it is possible to implement a script that removes the corresponding object files or similar. Or perhaps there is a better way?
Modifying a source file and deleting a source file are two different things.
The scenario you are describing is a proper incremental build behavior and you will see the same behavior when building with Visual Studio (without IncrediBuild). When deleting a file and then performing an incremental build, a link step will be executed by the build system and fail whether you are using IncrediBuild or regular Visual Studio builds.
Here's my specific scenario: Using VS2010, Pex and TFS2008, generated moles files are getting automatically added to source-control (TFS).
Pex adds a "project_name.moles" file to your test project and then autogenerates 3 files at build time: project_name.Designer.cs, project_name.Moles.dll, and project_name.Moles.xml. I want to keep the *.moles files in TFS (it's source code) but I don't want the 3 generated files to be in TFS (they are still part of the project, but they are generated when first built on a new system).
There are two reasons I need this behavior:
1. It's not a good idea to store generated code in source-control (let's not debate the merits of that here).
2. Specially, the DLL file is BAD because every time someone builds, all moles files are regenerated and thus all files are checked-out and DLL files are checked-out EXCLUSIVELY (non-mergable) and so other people can no longer build on their local box.
The Pex/Moles team are working on this but the solution is still likely several months away.
Is there a csproj property that can be assigned to these project files so that they are in the project but not managed by version control? I don't mind hand-editing the csproj file.
Moles will not be adding any files to the project in the next version (v0.94). It will use MSBuild to generate the assemblies on demand.
I think it depends more on the version control tool than Visual Studio, as usually you can set up some kind of filters in your version control configuration in order to exclude some files/paths.
E.g. if you use Mercurial/Hg, you can (and should) edit your repository .hgignore file and specify e.g. to exclude all *.moles files and the whole sub-tree MolesAssemblies\*. I guess other version control systems have similar options.