When I build a release version of a project in Visual Studio 2008, it creates a .pdb file, e.g. for a simple WPF project it generates a .exe and .pdb file.
I've always understood .pdb files to be for debugging, so I would expect them to be in the Debug folder but not the Release folder.
And looking around at other StackOverflow questions, it doesn't seem that pdb files work well with teh Release version anyway.
Why are .pdb files generated in the Release folder by default and how can I turn that option off?
You are right. PDB files are for debugging but you may need to debug release builds too. Saving PDBs of released builds is very important when you want to debug a customer issue and you have the crash dump file related to that issue.
By the way, generating PDB files does not harm compiler optimizations. If you don't ship it to the customer, there will be no performance implications.
It depends on the project settings. Just happens that in Release version a .pdb is also generated by default. It will not hurt you - just don't ship it to the customer.
To skip its creation go to Linker->Debugging in project settings and set "Generate Debug Info" to "No".
Related
I am working in Visual Studio 2010 VC++. I am trying to debug a release build. I have it in release mode, and made all of the changes noted in the following link:
http://msdn.microsoft.com/en-us/library/fsk896zz(v=vs.100).aspx
As well as rebuilt the solution. The breakpoints are still complaining that the symbols have not been loaded.
When I try to debug, I have looked at the modules window and tried to hand-locate the PDBs. However, I have over 100 DLLs, half of which say "Cannot find or open the PDB file."
Do I need to manually go through and search for all of these PDB files? I started, but I checked out the code from a company repository and all of the PDBs are all over the place, it's a little bit of a mess. Also, if I can find the PDB file, sometimes the dates don't match up with the DLLs, and Visual Studio doesn't take them. I thought the PDB files were created when the project was built, so I thought they would be created again when I re-built the project, but maybe I am incorrect?
Is there any way around this problem, and is finding the PDBs the correct solution to being able to hit the breakpoints?
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
get from https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473
The standard setup for .NET solutions is that each assembly gets its
own bin directory to which it is copied along with the assemblies of
all its dependencies. If your solution contains an .EXE file and, say,
40 different assemblies. Does it really make sense to copy the
dependencies of each assembly to each separate build directory? The
target directory of the EXE should be enough. Another way to
accomplish roughly the same would be to give the assemblies common
output directories. That also avoids the copying. Some earlier
versions of Visual Studio did not support this well, so be careful. I
have, however, been using this approach with VS2008 for quite a while
without noticing any problems.
question - how to disable creating "bin" etc for all child projects? Thanks
Edit - there is a more comprehensive answer at Optimizing Visual Studio solution build - where to put DLL files?.
Create top level /bin/ folders above all your child projects. Then for each project, right click and go to properties. On the build tab, you can amend the "Output path" to point to your new top level bin with a relative path (e.g. ../bin/Debug or ../bin/Release). You should do this for each build configuration (e.g. Debug and Release).
This should result in each assembly being copied just once to the same location.
Note I've checked this procedure in VS2008 but I suspect it is similar in 2010.
I asked a similar question a while ago Error Creating Debug Information - Code Won't Compile but never found a solution.
That problem seems to have evolved a bit. Now Visual Studio is creating a PDB debug file even when the application is in Release mode and debugging is turned off in Web.config. This PDB file is getting locked by Visual Studio and sometimes w3wp.exe. Compiling fails saying the PDB file is in use by another process (devenv.exe, w3wp.exe, or both). I cannot compile until I use Unlocker to release all the locks.
First off why is VS creating a debug file when in release mode?
Secondly how can I fix this? I have run a repair install on VS and re registered ASP.Net with IIS but that didn't help. I am using Windows Server 2003, VS 2008 Standard, and IIS6.
The first symptoms showed up a week or two ago when I was working on a WPF application. Until today putting the project in Release mode made the problem go away. Now it is happening even in Release mode.
Any ideas?
PDB files are created for release builds too - that is by design so you can still debug crashes in a release binary.
The PDB file is certainly not required for running. However, if it is in the same directory as the binary being run, IIS may be loading it (not really sure what IIS does here though). You can copy the binaries to a different folder (minus the PDB files) to prevent this problem.
Did you try this: http://callicode.com/Homeltpagegt/tabid/38/EntryId/24/How-to-disable-pdb-generation-in-Visual-Studio-2008.aspx?
You can also add custom after-build event to release configuration to delete the pdb file if everything else fails.
I have a Visual Studio (2008) solution consisting of several projects, not all in the same namespace. When I build the solution, all the DLL files used by the top level project, TopProject, are copied into the TopProject\bin\debug folder. However, the corresponding .pdb files are only copied for some of the other projects. This is a pain, for example when using NDepend.
How does Visual Studio decide which .pdb files to copy into higher level bin\debug folders? How can I get Visual Studio to copy the others too?
References are as follows: all the DLL files are copied to a central location, without their PDB files. TopProject only has references to these copied DLL files; the DLL files themselves, however, evidently know where their PDB files are, and (most of them) get copied to the debug folder correctly.
From MSDN:
A program database (PDB) file holds
debugging and project state
information that allows incremental
linking of a Debug configuration of
your program. A PDB file is created
when you compile a C/C++ program with
/ZI or /Zi or a Visual
Basic/C#/JScript .NET program with
/debug.
So it looks like the "issue" here (for lack of a better word) is that some of your DLLs are being built in debug mode (and hence emitting PDB files), and some are being built in release mode (hence not emitting PDB files). If that's the case, it should be easy to fix -- go into each project and update its build settings. This would be the default scenario, if you haven't done any tweaking of command line options.
However, it will get trickier if that isn't the case. Maybe you're all in release or debug mode. Now you need to look at the command line compile options (specified in the project properties) for each project. Update them to /debug accordingly if you want the debugger, or remove it if you don't.
Edit in Response to Edit
Yes, the DLL files "know" that they have PDB files, and have paths to them, but that doesn't mean too much. Copying just DLL files to a given directory, as others have mentioned, won't clear this issue up. You need the PDB files as well.
Copying individual files in Windows, with the exception of certain "bundle"-type files (I don't know Microsoft's term for this, but "complete HTML packages" are the concept) doesn't copy associated files. DLL files aren't assembled in the "bundle" way, so copying them leaves their PDB file behind.
I'd say the only answer you're going to have is to update your process for getting the DLL files to those central locations, and include the PDB files ... I'd love to be proven wrong on that, though!
First off, never assume anything. Clean the solution, rebuild it in debug mode, and check to see if all PDB files are created. If not, that's your problem.
If they are created, and they're not all getting copied, you can get around this by creating a post build event that manually copies the PDB files to the desired locations. This is just a workaround, of course.
The only other thing I can think of is that your solution file has become corrupt. You can open your .sln as an XML file and examine the contents. Check the configuration for the projects that are acting as expected and compare them to those that aren't. If you don't see anything, you have to repeat this at the project level. Compare working .csproj (or whatever) project files and the non-working ones.
Edit in response to edit:
If you're just manually copying stuff around, then manually copy the PDF files as well. DLL files shouldn't "know" anything about PDB files, I believe. Just stick them in the destination directory and go have a cup of coffee. Relax.
Check when you clean the solution, that it is actually cleaned.
I've seen Visual Studio leave files hanging around in bin\debug directories even after cleaning. Delete the bin\debug directory on all of your projects and rebuild.
As other posts have said, you may have a compiler/corruption issue.
But, as Will said, if the PDB files are being created, but not showing up where you want them, create a post-build step. Here is the post-build step I define for every project in my solution. It makes sure all output files are copied into a common directory.
If your project file is in \SolutionDir\ProjDir, then the first line of the post-build step will copy the output files to \Solution\Bin\Release or \Solution\Bin\Debug. The second line copies the PDB file if this is a debug build. I don't copy the PDB file for release builds.
So, \SolutionDir\Bin now contains all your output files in one location.
xcopy /r /y $(TargetPath) $(ProjectDir)..\$(OutDir)
if $(ConfigurationName) == Debug xcopy /r /y $(TargetDir)$(TargetName).pdb $(ProjectDir)..\$(OutDir)