This question already has answers here:
C# release version has still .pdb file
(6 answers)
Closed 6 years ago.
If I put my C# program exe in a text editor, I can find debug information in it:
How can I remove that?
EDIT: I dont care about the pdb file, i only care about that there is a path to the pdb file in the executable. This path contains my name (coincidence in this example), my question is how i can remove THAT Path from the executable, NOT how to remove the pdb file itself.
OK, so yours is actually a curious question because what you are asking for is really nothing you normally would be concerned about. PDB files are not "personal information" and neither is the path found in the .exe that points to the .PDB file. Your example is pure coincidence. Moving on...
Easiest fix Based on Best Practices
Don't keep your Visual Studio code inside your Windows User Profile Documents folder. Instead move it to one of the following
c:\development or better yet, a folder on a non-OS drive if you can
When you are ready to ship, ensure you build your code on a CI server. In this day and age there is no excuse for not using a CI server in the same way as you should be using source control
That will fix the coincidental username appearing in your exe. Unless of course you are running your build agent in your user context instead of a dedicated build account.
Also, I like to keep Documents for, well documents and not get polluted with code; Git or SVN caches. It just creates noise for real-time back-up apps like CrashPlan.
Alternative
Just build without debug information.
Consider this default debug build, note the path to the associated PDB File:
Release with No debug settings
Settings
Yours is a debug build which you can tell by the path to the PDB file, a file containing debug information about the application. Normally you don't deploy a debug build of your application.
Make a release build of your application. Release builds by default do not generate a .pdb file.
Also, .pdb files don't give away "source code" to avid readers if that is your fear. At most it may list the path to a file, but a filepath doesn't constitute source code content.
See also:
You might want to check this out as to why its a good idea to always deploy PDB files
Related
This question already has answers here:
Disabling the *.vshost.exe and miscellaneous files from being created on build
(2 answers)
Closed 5 years ago.
I have a C#/Winforms project in Visual Studio. I can build it, and all is fine, but it generates a lot of excessive files. Is there any way to avoid this? It is not very intentional, if you want to distribute it to non-technical stakeholders during the process.
I have three files (bold formated) which seems to be required. After some research, I fould a way to avoid the .vshost files (formated as italic), but I still have some files left, which I cannot figure out what does (normal formating).
SomeLibrary.Json.dll
SomeLibrary.Json.xml
SomeAPI.Api.Client.dll
SomeAPI.Api.Client.xml
MyProgram.exe
MyProgram.exe.config
MyProgram.pdb
MyProgram.vshost.exe
MyProgram.vshost.exe.config
MyProgram.vshost.exe.manifest
How do I make a release build without these remaining non-required files?
The xml files contain documentation used to make intellisense work when referencing the dll's with the same name. If these are your libraries, you can go to Project Properties and uncheck XML documentation file. Otherwise, see https://stackoverflow.com/a/2300049/292411
pdb files contain debugging information. You can go to Project Properties -> Build -> Advanced and set Debug Info to none if you don't want to generate this file
The .config files are configuration files generated by Visual Studio probably because your project contains an App.Config file. If you're running the application without the .config files, you might as well delete the App.Config file
Abhishek's comment already contained information that helped you remove the vshost files.
Personally I find it easier to just pick the files myself, especially when you're working in a team you sometimes just want to settle with what everyone's used to.
I use NSIS to create an installer for my project. Wishing to have as small a filesize as I can, I began looking into my project's dlls, included files and prerequesites and noticed the following are all different:
the minimal files required to run, as determined by educated guess + trial and error. I made sure the application works properly with this minmal set of files.
the files exported by the "Publish" fonction for click once deployment (excluding click once specific files)
the files in the release directory (excluding the pdb and vshost files)
It seems VS2015 generates an xml file for every dll. Some dlls I don't use and don't reference are copied as well.
My question is why is there so many unnecessary files and how can I configure VS2015 to not have them in /release?
If you set VS build log level to verbose you will see exactly what happends during build and why a file goes to release folder. Once you determine the reason, you may either change your project file to adjust predefined behavior or add post-build event to remove unwanted files produced by build process.
MSBuild file, located at "C:\Program Files (x86)\MSBuild\12.0\Bin\Microsoft.Common.targets" is very useful to dig into build process details as well.
However, if you indend to distribute the content of release folder to other machines I'd suggest you look at some installation software, like Wix, for example. Once you create a setup project which includes files you do want, there will be no need to fight for release folder content.
So I want to create a C# application that can be transmitted to users which can then run an "exe" file copying the data files. Therefore, the application should contain at least to things:
The "exe" file
The files containing the data
The data in the application will be in most cases a directory with files and subfolders. My concern is how to store this data. I was thinking about storing the data in ".bin" files while being able to read the data with the exe file and place the files/folders in the correct structure, but I don't know exactly how would I do that with files and folders. Does anyone have any suggestions ? Is there a better way? Do you have any recommended reads ?
Thanks!
When you compile in either debug or release mode, there will be an .exe file in the bin/debug or bin/release folder for your project together with all the project files. You can move that to whatever machine with the .NET framework installed and run the .exe.
If you want to make an actualy executable, that's more difficult to do. Check out this post for more inspiration on that.
If your build is meant for distribution, better compile it on Release mode.
You will find the assemblies on your project_folder/bin/Release.
You may want to copy all contents in the release folder by compressing it, or better yet, using an installer compilation tool, like InnoSetup - http://www.jrsoftware.org/isinfo.php/, that is free and will do your application installer just fine.
What is the best/correct way of attaching an external project source code so I can debug it?
I´ve already downloaded the source code of it from CodePlex, so I have all the .cs classes.
I´ve managed to import from a pdb file, but unfortunately, there´s no such file in this project codeplex (SimpleInjector).
After importing the SimpleInjector solution on VS, I could build it and generate the .pdb files, but I wonder whether it is the right way.
If your goal is to step-through debug the binary, then you will need the PDB files. In general, the compiled assembly just doesn't contain the information needed to associate source-code lines with individual IL commands.
The PDB file is a "program database file" which contains lots of useful debugging information; one of those things is the mappings between each compiled IL instruction and the source-code line that generate it. It also keeps a symbol table that lists the names of things that otherwise get compiled out (like local variable names, etc.) The PDB embeds the full path name of each source file, so if your source code is in the same place when you debug as it was when you compiled, the debugger will automatically find it.
If the .pdb file is present but the source code has moved, VS will give you the option to browse to the .cs file. But, if the .pdb file isn't present at all, your options will be rather limited.
The only risk you have is that you are debugging a program that doesn't match your PDB files. Therefore, if you are doing to try to debug the project, you should rebuild, from scratch, in Visual Studio and run that version of the binary.
(Debugging without symbols and source loaded into Studio is, of course, possible, but it's a much harder skill to master.)
What is a PDB file and how can I exclude it from the release folder when I rebuild my solution?
A PDB file contains information for the debugger to work with. There's less information in a Release build than in a Debug build anyway. But if you want it to not be generated at all, go to your project's Build properties, select the Release configuration, click on "Advanced..." and under "Debug Info" pick "None".
I had originally asked myself the question "Do I need a PDB file deployed to my customer's machine?", and after reading this post, decided to exclude the file.
Everything worked fine, until today, when I was trying to figure out why a message box containing an Exception.StackTrace was missing the file and line number information - necessary for troubleshooting the exception. I re-read this post and found the key nugget of information: that although the PDB is not necessary for the app to run, it is necessary for the file and line numbers to be present in the StackTrace string. I included the PDB file in the executable folder and now all is fine.
PDB is an abbreviation for Program-Debug Data Base. As the name suggests, it is a repository (persistent storage such as databases) to maintain information required to run your program in debug mode. It contains several vital information required for code debugging e.g. at what points you have put break points where you expect the debugger to break in Visual Studio (VS).
This is the reason why Visual Studio fails to hit the break points if you remove PDB files from the debug directory. Visual Studio debugger is capable of telling you the exact line number of code file at which any exception occurred along with its stacktrace. It is able to do so with the help of PDB files only. Thus PDB files are very helpful for debugging purposes.
In general, it is not recommended to exclude the generation of PDB files during build process. From production release stand-point, what you should be doing is create the PDB files but don't ship them to customer site in product installer. Preserve all the generated PDB files on a symbol server from where it can be used/referenced in future if required.
It is specially important in scenario where you debug process crash issues. While analysing the crash dump files, Visual Studio will not be able to make out the exact line of code where program is crashing if the original PDB files created during the build process were not preserved.
If you still want to disable generation of PDB files then follow below steps:
Go to properties window of the project. To open properties window, select the project file in solution explorer and press Alt + Enter.
Go to Build tab
Click Advanced
Choose none from Debug Info drop-down box
Press OK as shown in the snapshot below:
Note: This setting will have to be done separately for Debug and Release build configurations.
A PDB file contains information used by the debugger. It is not required to run your application and it does not need to be included in your released version.
You can disable pdb files from being created in Visual Studio. If you are building from the command line or a script then omit the /Debug switch.
Program Debug Database file (pdb) is a file format by Microsoft for storing debugging information.
When you build a project using Visual Studio or command prompt the compiler creates these symbol files.
Check Microsoft Docs