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.
Related
I am trying to debug a web application hosted in local IIS web server. I have attached the VS debugger to the process but get the error - "The breakpoint will not currently be hit. No symbols have been loaded for the document".
I have done the following things:
Deleted the bin/obj folders
Cleaned and rebuilt the solution
Closed and reopened the solution
Things I noticed:
Opened Process Explorer and made sure I am attaching to the correct process.
Opened Debug-Windows-Modules but cannot find the project dlls and referenced dlls (Does this notify that the right process is not attached?)
Please share your suggestions. Thank you.
This error will also show up if you have attached to a process that was compiled in release mode.
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 have a project, which contains various classes and user controls. Every once in a while, often on the second build attempt, Visual studio locks the project's target assembly and the build fails with the following error:
Unable to copy file "obj\x86\Debug\MyProject.dll" to "bin\x86\Debug\MyProject.dll". The process cannot access the file 'bin\x86\Debug\MyProject.dll' because it is being used by another process.
This same issue was reported here: VisualStudio2010 Debugging - The process cannot access the file ... because it is being used by another process. I tried a few of the presented answers, but none of them resolved the matter for me.
Any suggestions?
I read somewhere it's a known issue and they're working on a hotfix - knowing Microsoft it should come out about the time Windows 9 does.
The current only real fix is to uninstall SP1, but since I can't be bothered doing that I just delete all the project files in the Debug folder, but you have to do this every time it throws the error. You can't use a program or batch file to do this since for some reason it completely locks the file and you have to wait ~5mins for the system to unlock and delete it.
Is there any reason, maybe a known bug or missing SDK that would cause debug and trace to stop working in the following environment:
I recently formated my workstation. Fresh install of VS2010 Ultimate in a solution I've been working with for a month. It contains an exe and a vsix as it's outputs. debug and trace work in the exe but when debugging the vsix nothing is written to the output window. I have the VS SDK installed. I've used Import/Export settings to reset the environment. I've disabled all extensions (from the extension manager). I also tried deleting the .suo files in the solution.
Do you have Resharper installed by any chance?
When you break in the debugger and put System.Diagnostics.Debug.Listeners (or same for Trace) in the Watch window, what do you see?
Does doing System.Diagnostics.Debug.Listeners.Add(new DefaultTraceListener()) help?
Does adding a new TextWriterTraceListener work?
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".