When an exception occurs with any ASP.NET project (possibly any .net app) the stack trace will show the path on the developer's machine, even when in production.
How to change it?
What's going on under the hood?
This information is stored inside the .PDB files that were generated during the compilation of the source code. They contain the debugging information. But normally people don't compile applications on their machines before shipping them into production. They use continuous integration and build servers that are dedicated for this purpose.
Now if you want to turn off debugging details you could configure the level of verbosity and debug info in the properties of your project.
In order to remove it, go to Properties -> Package/Publish Web:
Make sure to click or check the "Exclude generated debug symbols".
This will Publish your site without PDB files attached on the Bin folder. Make sure you are on Release mode before publishing your site for Live environment. One of the main difference of publishing your site without PDB files is that you cannot see the line number on the StackTrace when an error happens on your site.
Related
Windows 8, VS2013 IIS8,5
I'm trying to connect to a local WEB API by connecting to processes w3pv.exe (Managed (v4.0.30319), 19). The website front end and back end is both running fine on my local IIS. Right after publishing my x86 web API to the local IIS i try to connect to the process, where the break point states "The Breakpoints will not currently be hit. No symbols where loaded for this document". My colleague' can without any problems debug from his local computer.
So far I have.
Reinstalled VS2013.
Checked All Debug Properties
-Project -> build: Define DEBUG constant check / Define TRACE constant check.
Generate serialization assembly = Auto. Advanced build settings -> Debug info = full
Enable Just My Code: Check, Use Managed Compatibility Mode: Check
Enable Edit and Continue : Check
Made sure all Debug mode is set and all project Configured to Active solution platform x86, marked Debug and Build.
Deleted all bin and obj folders, as well as pdb folder in C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files
Reset IIS.
Set Select Code Type to Automatically determine the type of code to debug
Checked in IIS that .Net compilation -> Debug and Enable Prefetch is set to true.
And I still get the same error message. Anyone found anything in addition to this?
I have encountered similar problems many times while training new employees in our very complicated devenv, so here is our internal step by step instruction:
Don't panic
Make sure you attached the debugger to the correct process - you debug the plugin by launching VMS which is external app that has separate config file where the plugin path is stored, so when you change just your configuration Debug/Release it doesn't work.
Make sure you have symbols generated for the assembly Project properties->Build->Advanced->Output section
Make sure the build path hasn't changed. You may have accidentally changed the path and you may only think that the assembly you are trying to debug is the correct one.
Investigating the information you provided this is only help I can think of. My guess is the files you publish are not the files you're debugging locally.
RESOLVED (embarrassed)
A few day's ago, I downloaded the front-end code for the website from the VPN (GIT). I forgot to update the code-behind reference in the App.js file in the front end root. This, of course, referred to the API on the cloud, and not my local API.
This took me way to long to find out. But, at the same time, it's not a solution I've seen so far on the web.
Thanks for all your help.
I'm having an issue with loading symbols on my ASP.NET MVC project. The first time I load visual studio and debug my project, symbols are loaded in roughly 2 seconds. I then end the debug session, make a code modification, and debug again, and the symbol load time is about a minute. Based on the research I have done, here are some applicable settings on my machine/VS:
In Options/Debugging/Symbols/Symbol file locations, "Microsoft Symbol Servers" is unchecked, and there are no additional locations.
Options/Debugging/Symbols/Cache symbols in this directory is "G:\Symbol Cache". I did click "Load all symbols" and I have inspected that directory and I see lots of symbols.
Just my code is enabled.
The _NT_SYMBOL_PATH and _NT_ALT_SYMBOL_PATH environment variables are not defined on my machine.
Options/Debugging/Symbols/Automatically load symbols for is set to "Only specified modules", with no modules specified.
I have tried both debug and release builds, with identical results. Ctrl + F5 loads the site almost immediately.
I too had this problem, the cause was that I had accidently enabled the "Microsoft Symbol Server"
You can disable it by going to Tools > Options > Debugging > Symbols and uncheck the "Microsoft Symbol Server"
Now it loads just as fast as it used to.
I too had this problem and noticed that it was mostly related to 3rd-party assemblies acquired via NuGet. In these cases, Visual Studio was trying to load PDBs from paths that apparently existed on the original author's machine (i.e. D:\OriginalAuthor\MyVisualStudioProjects\AwesomeNuGetPackage) but on my machine the same path referred to an optical drive. I then discovered via Command Prompt that if you tried to change directory to an optical drive that didn't have a disc in the tray, it took a very long time (~30 seconds) to fail. With this in mind, my solution was to simply place a DVD in the tray. At that point Visual Studio was able to very quickly determine that the path didn't exist, skip loading the PDB, and go straight into debug.
So, if Visual Studio is taking a long time to load symbols, watch the Output window for the paths it's trying to access and verify that you can quickly access (or quickly fail to access) those paths yourself via Command Prompt.
This brings up an interesting question about security/privacy--apparently Visual Studio is storing the absolute path of the original PBD within the assembly. I suppose this isn't a super critical issue, but from a privacy perspective I don't really want my absolute filesystem paths being exposed to the public without my knowledge.
Just try this Debug -> Delete All Breakpoints.
Its works on me.
I had 2 .dll's giving me grief that I didn't need to debug that started taking minutes to load. The afore mentioned solutions didn't help. So I went to Options -> Debugging -> Symbols and under the radio button for "All modules, unless excluded" click on "Specify excluded modules" link. Then type the .dll's that are causing issues.
MSDN says this about the StackTrace property of the Exception class:
The StackTrace property holds a stack
trace, which you can use to determine
where in the code the error occurred.
StackTrace lists all the called
methods that preceded the exception
and the line numbers in the source
where the calls were made.
So I know that this information is available. How do I get the line numbers to actually show up in the stack trace? My code is throwing an exception in a very difficult and complex piece of code that goes through TONS of objects, so I don't want to step through a bazillion times to see where the exception is happening. The stack trace of the exception only shows method signatures and no line numbers.
To get the line numbers in the StackTrace, you need to have the correct debug information (PDB files) alongside your dlls/exes. To generate the the debug information, set the option in Project Properties -> Build -> Advanced -> Debug Info:
Setting it to full should suffice (see the Advanced Build Settings Dialog Box docs for what the other options do). Debug info (ie. PDB files) are generated for Debug build configurations by default, but can also be generated for Release build configurations.
Generating PDBs for release builds enables you to ship you code without the PDBs, but to drop the PDBs next to the dlls if you need line numbers (or even to attach a remote debugger). One thing to note is that in a release build, the line numbers may not be entirely correct due to optimisations made by the compiler or the JIT compiler (this is especially so if the line numbers show as 0).
You could try the following, given there is a pdb file for the assembly:
try
{
throw new Exception();
}
catch (Exception ex)
{
// Get line number from the stack trace's top frame for the exception with source file information
int linenumber = (new StackTrace(ex, true)).GetFrame(0).GetFileLineNumber();
}
You have to build the project with pdb files enabled and make sure your deploy the pdb files with your application. You can check if pdb files are in fact being built for you configuration by right clicking on the assembly you require pdb files for, then heading to Properties > Build > Advanced and making sure that under Output Debug Info is set to full.
If you have a web application or web service project using VS2012 or later, changing the build settings will not work. Instead, you should follow the advice in this article:
Visual Studio 2012 Website Publish Not Copying .pdb files
Specifically, you should include the following setting in the
<YOUR_PROJECT>\Properties\PublishProfiles\*.pubxml
file(s) for your project:
<PropertyGroup>
<ExcludeGeneratedDebugSymbol>False</ExcludeGeneratedDebugSymbol>
</PropertyGroup>
Further to the other great suggestions, we were deploying to IIS. We had a staging server and a production server. They appeared identical except staging gave us line numbers and production did not. It turned out that there was an extra DLL in the bin directory of production (it happened to be SqlServerSpatial.dll fwiw) and once it was moved to the system directory line numbers started appearing on production.
The lesson was to ensure that the bin directory of production matches the bin directory of development in every respect (except for XML files).
Seem to have found the solution.
On VS2010 at least, with Output Debug Info set to full I also did not get line numbers within the exceptions. The trick it seems was to turn on line numbers within the editor. (Tools -> Options -> Text Editor -> All Languages -> General -> Display -> Line numbers)
Now exceptions show up with line numbers.
When compiling a library or an application (e.g a Console Application in the Visual Studio IDE), in the Debug folder of the application, apart from the .dll or .exe, there will be one more file with extension ".pdb".
What is the exact usage of this .pdb file?
PDBs contain debugging symbols, so you can ship a compiled binary to your customer without exposing your source code algorithms and other private details to them.
If your app goes wrong on a customer site, you can get a crash dump from them (using DrWatson), bring it back to your dev workstation and debug the crash, the debugger will use the symbols file in conjunction with the crash to show you the source code, data structures etc. In many cases, all you have to do is open the crash dump and the debugger will take you directly to the source code of the exception, and show you variables and threads too.
That's the primary use of them, they're invaluable when a customer reports a crash. The things you need to know about using them though - they are only valid for the build that created them, so if you recompile, your symbols file is next to worthless.
John Robbins has an excellent article why you would use them.
John Robbins has written some really great articles on PDBs lately:
PDB Files: What Every Developer Must Know
Visual Studio Remote Debugging and PDB Files
How Many Secrets do .NET PDB Files Really Contain?
Do PDB Files Affect Performance?
Correctly Creating Native C++ Release Build PDBs
PDB's allow debugging of applications, for examlple when they crash or if you have a minidump. They also allow you to find more detail about errors when outputting exceptions to logging (they will give a more complete stacktrace with line numbers rather than just showing the name of the function where the error occurred).
PDB's are useful when you want to do remote debugging as well.
Keeping the PDB's together with your installed application makes it possible to hook up visual studio remotely to the client's production environment and debug the application when necessary.
Well you've given yourself a big clue in your title.
It's the file Visual Studio needs to be able to debug your application.
This MSDN page has more information.
A program database (PDB) file holds debugging and project state information that allows incremental linking of a Debug configuration of your program.
As far as i know, they contain debugging information, such as line numbers, variable names, etc.
In VS2008 (and earlier if I'm not mistaking) I have dropdown that lets me choose between Debug and Release mode. All well.
When I switch VS to Release, the debug attribute in my web.config files isn't set to false at all though.
Is this the way it is supposed to be? I am bound to forget to set it to the correct value on deploying.. What measures should I take to make sure this is working like it should?
This is one solution to this problem:
http://blog.aggregatedintelligence.com/2009/04/aspnet-never-again-fear-publishing-your.html
Well your web.config would probably be different for debug and release (connection string, passwords, etc...) but if it's not, look at a postbuild event which would copy over a different file.
Also check this blog post from Scott Guthrie.
Changing release mode will not change web.config, however when you build your web app, it will build the dll for only C# files in release mode where else your web.config's debug on/off is used by IIS to build debug/release version of ASPX markup files.
The build flavour just affects how the code is compiled, it does not affect your configuration files. So yes, to answer your question, this is how it is supposd to be.
The element is a good solution if you have access to the machine.config of your server, which hosts only production applications.
I usually modify the web.config file when generating the deployed files as part of the automated build process. For example web deployment projects can perform web.config section replacement. There are a number of reasons I don't like web deployment projects and I tend to do it with a simple VBS file that modifies the file using MSXML.
The answer you selected from Bobby is not correct. Visual Studio builds the files for you in release while you are in VStudio.
IIS compiles the code at startup with that setting when you deploy. Not the bin directory, but the App_Code and the code behind files.
You should precompile your app before deployment which will compile your code behinds and App_Code dir into dlls in the bin directory.
The deployment tools automatically switch that setting if you set the deployment tool to Release
I use web deployment projects. http://weblogs.asp.net/scottgu/archive/2008/01/28/vs-2008-web-deployment-project-support-released.aspx