When I compile a project in VB i get the following files:
<ProjectName>.exe
<ProjectName>.exe.config
<ProjectName>.pdb
<ProjectName>.vshost.exe
<ProjectName>.vshost.exe.config
<ProjectName>.vshost.exe.manifest
A quick search of them all gives info about them holding information of debugdata and such. But how do they help me? Do you guys ever use these files?
Let's say I'll make a program and send it away to a friend, what is recommended to send? Just the .exe file or something more?
Your project output (here the exe, but could be a DLL if the project type is a library for exemple) and the config files are needed to use the program, plus any dependency you could use in your project (external libraries for example)
The pdb and vshost files are used by your programs for debug, not directly by yourself. And they are only generated in the debug configuration (edit: can also be generated in release, depending on your configuration).
More SO questions about those files: see ClickRick links in comments & other links:
About PDB:
What's the PDB file?
How do I use PDB files
About VSHOST files:
What is the purpose of the vshost.exe file?
http://geekswithblogs.net/pavelka/archive/2006/08/11/WhatIsTheVshostExeDoing.aspx
You can find everything explained here:
What is the purpose of the vshost.exe file?
To quote Daniel Brückner:
.exe - the 'normal' executable
.vshost.exe - a special version of the executable to aid debuging; see
MSDN for details
.pdb - the Program Data Base with debug symbols
.vshost.exe.manifest - a kind of configuration file containing mostly
dependencies on libraries
Related
I have thinking that release mode does not have .pdb file . Recently I publish .Net core web app using command line and it includes pdb files. This is bit strange for me.
It is confiugrable in project properties as many other aspects of code building (optimization level, enabling/disabling conditional compilation switchers etc.).
In many cases PDB brings you additional information which you would not have without it: line numbers in stack trace (in case of unhandled expception error wroted to the log). There is a long tradition to public pdb with release versions on MS dev platform. Actually you should have a strong reason to do not puplish them (I always do).
Given the following:
the 32-bit DLL code file of some old Firefox plugin (i.e. a DLL containing among other a Typelib, XSD and XSL entries), without source code or debug info, originally coded in C++ and compiled with Visual Studio,
the name and parameters of an exported function/method in this DLL (a function of the Firefox plugin, accessable in JS code),
Visual Studio Community 2013 running on Windows 7,
experience in C++ development, but not with COM or Firefox,
experience with debugging Intel assembler code,
a code license which does not prohibit disassembling the DLL,
I would like to do this: Load the DLL into some C++ code, and step on CPU level into the code of the function to find out what it exactly does.
Can you give me any hint on where to start and how get this done? I guess the DLL may need some Firefox-specific initialization before I can call the function which I would like to debug. Could this be done with the Firefox SDK, without source code and debug info for the DLL? Or may I succeed in "nakedly" loading the DLL, finding the entry point of the - rather simple - function (how?) and calling it?
Thanks for any hints.
If no pdb file or source code, it is hard for you to debug the dll file, since the debugger loads debugging information from the PDB file and uses it to locate symbols or relate current execution state of a program source code. Visual Studio uses PDB files as its primary file format for debugging information during debugging. If no those files, you couldn't debug that library.
Update:
We are dynamically loading a dll to one project using LoadLibrary() function, but if you want to step into your dll file, it really require the pdb file. A simple sample is that you could create and place one pdb file in the same folder as one simple custom dll library project located. I think Visual Studio will automatically search the directory and load them, you could find the information in your Debug modules windows.
The following case is not the same issue as yours, but it also shared us that it would load the pdb file if the dll file was really called by one project/process:
Does winbase::LoadLibrary() load .pdbs?
I compiled a .dll file in ironpython, by using the following code:
import clr
clr.CompileModules('C:/example.dll', 'C:/example.py')
It essentially compiles the .py file to .dll.
The only problem with this is that it creates a file with no information about the Company, Language, File Version etc. In fact the File Version is always: 0.0.0.0.
I was wondering if there is a way to at least alter the File Version (change it to something other than 0.0.0.0). I googled and found a similar topic in here on stackoverflow.
I tried three methods:
1) One with Visual Studio (File->Open-> find .dll, Edit->Add Resource->Version click New. In the new Version tab, change FILEVERSION and PRODUCTVERSION)
2) Another one by using the Change version 2012 application
3) And third one by using: Simple Version Resource Tool for Windows 1.0.10
None of them worked.
For some reason looks like the structure of the .dll assembly created with ironpython is different than the .NET one created with VB or C#.
Does anyone know how to change the File Version from 0.0.0.0 to something else?
Thank you.
You can use the pyc.py file packaged into IronPython to compile your file into a .dll file. The file is located in the directory IronPython 2.7\Tools\Scripts.
If we open pyc.py for editing, you'll see the different things it can do.
pyc: The Command-Line Python Compiler
Usage: ipy.exe pyc.py [options] file [file ...]
Options:
/out:output_file Output file name (default is main_file.<extenstion>)
/target:dll Compile only into dll. Default
/target:exe Generate console executable stub for startup in addition to dll.
/target:winexe Generate windows executable stub for startup in addition to dll.
#<file> Specifies a response file to be parsed for input files and command line options (one per line)
/file_version:<version> Set the file/assembly version
/? /h This message
EXE/WinEXE specific options:
/main:main_file.py Main file of the project (module to be executed first)
/platform:x86 Compile for x86 only
/platform:x64 Compile for x64 only
/embed Embeds the generated DLL as a resource into the executable which is loaded at runtime
/standalone Embeds the IronPython assemblies into the stub executable.
/mta Set MTAThreadAttribute on Main instead of STAThreadAttribute, only valid for /target:winexe
/file_info_product:<name> Set product name in executable meta information
/file_info_product_version:<version> Set product version in executable meta information
/file_info_company:<name> Set company name in executable meta information
/file_info_copyright:<info> Set copyright information in executable meta information
/file_info_trademark:<info> Set trademark information in executable meta information
Example:
ipy.exe pyc.py /main:Program.py Form.py /target:winexe
One thing that I personally like to do is move pyc.py from the Scripts folder to the IronPython folder along with my python file as well.
Assuming you also do this, you would open command prompt as administrator and navigate to the IronPython folder.
cd "Program Files (x86)\IronPython 2.7"
Then you would want to compile your python file as a .dll and set the file version using pyc.py. To do that, you're going to want to type in:
ipy.exe pyc.py /main:example.py /target:dll /file_version:0.0.0.1
If you want to add a company name, and other items as well, you simply have to pass those option to the pyc.py script.
ipy.exe pyc.py /main:Program.py Form.py /target:winexe /file_info_company:Company
Is it possible in MSBuild 4.0 and/or 4.5 to specify additional files to be treated as a manifest output of a project by its dependencies, and copied with the binary project output, whenever that is copied? Ideally, I want to create some files beside a .dll during build, and would like these files to stay in the same folder as the .dll whenever it is copied to a directory of a project depending on it.
If this is not clear, I am thinking of .pdb and documentation .xml files created by the C# compiler. These files treated specially: Whenever another project requests the .dll be copied locally into its binary directory, these files go with the .dll. Can I augment this set with my own special files?
This is not possible, and here is why. Actually, there is no concept of project output accessible externally between MSBuild projects. Rather, when a reference to a project is added, the SDK-provided build framework (based on MSBuild scripts) looks for a few specific files matching the name of the referenced DLL, and copies these files with the DLL itself into the current project output directory (assuming CopyLocal is set, which is probably true for a referenced project).
In framework v4.0, this is done by the task ResolveAssemblyReference which is called from an identically named target from the file %windir%\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets. The task looks for specially named files placed beside the target DLL, including its matchin PDB files and an XML documentation file. Other files are also discovered, as I infer from the decompiled source.
So nothing in a given project specifically marks these files as somehow "exported" from the project. The magic happens on the pulling side.
I'm using cmake to configure my project. It seems QtCreator only show those files referred by add_executable, add_library and configure_file. Other files in project directory are not visiable in the Projects panel.
Although we can still visit those files by file->open, it make me feel bad that many important source files are not visiable in the Projects panel. So...
How does QtCreator decide whether to show a file?
Is there any cmake command that can make arbitrary file to be visiable in QtCreator?
=======================
Some additional info:
My project is a C++ library with PerlXS interface. XS code is preprocessed into C code by xsubpp, and this action is added into cmake project via add_custom_target. However, the XS file is not added into Porjects panel by QtCreator. Besides, a project can have non-source text files such as README, Changes, etc..
I see no reason to put something specific with project, when you can switch to "File System" browser in QtCreator.
But anyway, the answer still the same. If you wish to see something in project - add it to add_executable, add_library.
For example
set(DATA_FILE ${PROJECT_SOURCE_DIR}/build/README.txt)
...
add_executable(${TARGET_NAME} ${SRC_FILES} ${GLB_HDR_FILES} ${DATA_FILE})
And now we can see README.txt in project
Same trick can be done for other files. Just add them to DATA_FILE variable.