I've got an issue with how Visual Studio is displaying my variables during debugging. I develop on two computers, both on VS2012, and they have the same versions of the development libraries installed, and they display the order of variables in a class differently.
Seems inconsequential, but I'm using a math library (GLM) and when I break and inspect a variable, the order they are shown is different:
The type is a glm::vec3, which is defined by 3 floats x, y, z, but the library is designed to be as close syntactically to glsl, so it also contains other names for the variables (rgb, stp) which really are just references(x=r=s, y=g=t, z=b=p). On my other machine, the preview shows x y and z values, which is what I want.
Viewing these is a pain on this machine, as I have to click the drop down to inspect each individual variable, and the lists of vectors I'm working with can be 100's or 1000's of items long. I also can't print them out in the immediate window and inspect that way either because it prints in the same order.
Anything I can change?
edit:
I needed to update the autoexp.dat file, but it doesn't seem to be working for me. I opened a sample file in VS2010 which I have installed, and modified it's autoexp.dat and it worked great.
One thing I did notice is that my VS2012 is installed in C:\Program Files(x86), rather than C:\Program Files(X86)\Microsoft Visual Studio 11.0 (my 2010 is installed in the correct location), so my Common7 folder is C:\Program Files(x86)\Common7
Is that a problem?
In VS2012 and later, autoexp.dat has been superseded by the native type visualization framework (natvis).
This works with an xml file with .natvis extension, which can be put at three different locations :
%VSINSTALLDIR%\Common7\Packages\Debugger\Visualizers (requires admin access)
%USERPROFILE%\My Documents\Visual Studio 2012\Visualizers\
VS extension folders
Your .natvis file should look like this (replace TheType by the name of the class you want to visualize) :
<?xml version="1.0" encoding="utf-8"?>
<AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
<Type Name="TheType">
<DisplayString>x = {x} y = {y} z = {z}</DisplayString>
</Type>
</AutoVisualizer>
On MSDN :
Create custom views of native objects in the debugger
Related
I'm debugging a program in Visual Studio and I'm wondering why my program passes next to a function in a particular unit (source code file).
I thought that the call stack would show this, but this seems not to be the case. Moreover the list of showable entries does not even mention the filename:
Show Module Names
Show Parameter Types
Show Parameter Names
Show Parameter Values
Show Line Numbers
Show Byte Offsets
=> no "Show Filenames", although the presence of "Show Line Numbers" means that the filename should be known.
I'm working with Visual Studio Professional 2017 for Windows Desktop.
Is this a configuration issue, is this not present in my Visual Studio installation (if so, which version has this feature) or is this not foreseen in Visual Studio at all?
For a good understanding, my call stack looks like the following:
<product>.dll!<first_class>::<first_class>(double dFy, double dFx) Line 102 C++
<product>.dll!<subfunction>(double dFv, double dFh) Line 1450 C++
<product>.dll!<subsubfunction>(double dFv, double dFh, int number) Line 1672 C++
...
While I'd like to see something like:
<product>.dll!<first_class>::<first_class>(double dFy, double dFx) File <file1.c> Line 102 C++
<product>.dll!<subfunction>(double dFv, double dFh) File <file2.c> Line 1450 C++
<product>.dll!<subsubfunction>(double dFv, double dFh, int number) File <file2.c> Line 1672 C++
...
As I'm particularly interested in the difference between central source files and project specific source files, I'd like to see the whole path in the filename.
You can stop looking, the option is simply not available.
Hard to guess why Microsoft decided to not provide it, but it is the only debug info that is ambiguous. Something that the softies need to deal with every day, the programs they debug are generally built on a build server from source code that is not located in the same directories.
I'd like to browse through the own files, without needing to open all included individual central files...
That is not necessary, simply double-click the specific entry in the stack trace that you are interested in. If the debugger knows the source file then it will automatically open and position the caret at the statement. Hovering the editor tab displays the path of the file. If the debugger can't find the source file then you'll get a dialog to navigate to the correct directory.
From what I know there is no such option (in any version of Visual Studio). Only thing you can do would be to right-click on call stack and press go to source file. Then you would see source-code and hopefully you will know which version of a file it is. As far as I know there are also no plugins for what you are trying to accomplish.
The "Copy With Source Paths" Context Menu option exists in VS17 (15.9.45), VS19 (16.11.11), and VS22. Unfortunately, there is no documented option in the command window.
The short story: I can generate a CHM file with Doxygen. Launching the CHM file, I observe that the Contents and Index tabs do list the pages, namespaces, classes, and members of those classes. However, clicking on the items in those Contents and Index lists do not display any content.
I am on a computer using Windows 7 Professional SP1, 64-bit.
I use Doxywizard to run Doxygen version 1.8.9.1 on my code. It correctly generates the HTML output; the pages, namespaces, classes, and members appear in the documentation.
I then further want to convert the HTML into a compressed HTML (CHM) file.
I downloaded the Microsoft HTML Help Workshop version 1.31 (i.e., htmlhelp.exe version 4.74.8703 ) from the Microsoft website ( https://msdn.microsoft.com/en-us/library/windows/desktop/ms669985(v=vs.85).aspx ). I ran the installer. As the installer was proceeding, a popup message appeared:
This computer already has a newer version of HTML Help.
However, installation completed successfully. And, the hhc.exe program is there where I told it to install.
I now specify these relevant Doxygen settings:
Wizard --> Output:
HTML is checked
"prepare for compressed HTML (.chm)" option is selected.
Expert --> HTML:
GENERATE_HTMLHELP = YES
CHM_FILE = Foo.chm
HHC_LOCATION = C:\Program Files(x86)\Microsoft\HTML Help Workshop\hhc.exe
When I run Doxygen again, it reports an error:
error: failed to run html help compiler on index.hhp
The Foo.chm file is generated where expected. But, as described above, it is missing a lot of content.
I tried running hhc.exe manually on the HHP file generated by Doxygen. It does not indicate any errors.
C:\Program Files (x86)\Microsoft\HTML Help Workshop>hhc c:\test\html\index.hhp
Microsoft HTML Help Compiler 4.74.8702
Compiling c:\test\html\Foo.chm
Compile time: 0 minutes, 3 seconds
292 Topics
3,855 Local links
83 Internet links
0 Graphics
Created c:\test\html\Foo.chm, 259,580 bytes
Compression decreased file by 1,077,915 bytes.
However, the result is the same: a Foo.chm file that is missing content.
I subsequently found that I had another installation of the HTML Help Workshop on my computer. But, the hhc.exe was the exact same version. So, that is not likely the problem.
Can you suggest what else I can try to get all the documentation content to display in the CHM file?
When I have seen this problem (the html exists and the chm has content but that content is not visible), it has been because windows security has "blocked" the chm file. To see if this is what you are encountering try the following:
From windows explorer, Right click the generated .chm file and select properties.
On the General tab, if you see an Unblock button, click it.
Close the dialog and open the .chm file.
(I have not encountered this problem with locally generated doxygen .chm files, but I am hopeful from your description that this may fix your problem.)
The essential problem was that the CHM file was on a mapped network drive.
When I copied the CHM file to a physical drive on my computer, all the content displays.
In your doxyfile, put the path to hhc.exe in double quotes, since it contains spaces.
Or even better, do not use paths with spaces.
I had a error with a basic hello world from a set of examples from Emscripten/tests/msvc10
I have a error MSB4096 but i don't find the solution of the problem on visual Studio 2012.
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppBuild.targets(817,5): error MSB4096: The item "..\hello_world.c" in item list "ClCompile" does not define a value for metadata "ProgramDataBaseFileName". In order to use this metadata, either qualify it by specifying %(ClCompile.ProgramDataBaseFileName), or ensure that all items in this list define a value for this metadata.
Do you know the reason?
thanks
When trying to compile keep in mind 2 things:
Do no try to compile managed C++ code with emscripten.
the code is running in browser sandbox
The metadata stuff in your code seems really related to the first issue (managed code).
You have to set the 'Program Database File Name' (ProgramDataBaseFileName) Property in the VS C/C++ Options of your Project e.g. to '$(IntDir)$(TargetName).pdb'
ProgramDataBaseFileName exposes the functionality of the compiler's /Fd (Program Database File Name) option.
MSDN ProgramDataBaseFileName
I'm trying to compile a C++ type .DLL for a SierraChart custom study.
(Which is a financial trading application.) Here is the warning I get that I need to fix so it all points to the linker output value:
warning MSB8012:
TargetPath(C:\SierraChart\VCProject\Release\SCStudies.dll) does not match the Linker's
OutputFile property value (c:\sierrachart\data\SCStudies.dll).
This may cause your project to build incorrectly. To correct this, please
make sure that $(OutDir), $(TargetName) and $(TargetExt)
property values match the value specified in %(Link.OutputFile).
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets
Any idea what's wrong?
I believe this warning appears specifically when upgrading a C++ project to VS2010. Visual Studio 2010 C++ Project Upgrade Guide describes some of the caveats encountered during an upgrade. If you're uncomfortable changing project settings, then retaining the older version of Visual Studio, may work for you.
To change the %(Link.OutputFile), open the project properties. Navigate to Configuration Properties -> Linker -> General. You can set the Output File to $(OutDir)\SCStudies.dll, which should take care of your issue. You may need to repeat the change for each Configuration/Flavor you will be building (Debug/x86, Release/x86, Debug/Itanium, etc...).
Based on this answer.
I changed the following property:
Linker -> General -> Output File to
"$(OutDir)$(TargetName)$(TargetExt)"
This prevented the warning to appear and the output was generated successfully.
The original configuration was set like:
Properties -> Linker -> General : $(OutDir)\"<'name fileA>".exe
The program tries to run "<'name_project>".exe and as result error Linked.
You need to set the configuration as:
Properties -> Linker -> General : $(OutDir)\"<'project name>".exe
A different fix which others haven't mentioned is that by default the TargetExt is .exe and for my debug builds I changed it to be _d.exe, where instead you should be doing that in the TargetName path.
The directory specified in General->Output Directory and the directory specified in the path at Linker->Output File have to match.
If you want to change the defaults do things in these order:
You first configure the OutDir in General->Output Directory. E.g.
$(SolutionDir)$(Platform)\$(Configuration)\MyProgram\
Make sure Output File is consistent. E.g. this would work
$(OutDir)\$(TargetName)$(TargetExt)
The comment from Gerardo Hernandez helped me.
The directory specified in General->Output Directory and the directory specified in the path at Linker->Output File have to match.
In my case I was importing a large project from Visual Studio 6 and
C:\Project\myproject\OneOfMyDlls\.\Debug\OneOfMyDlls.dll
was not equal to
C:\Project\myproject\Debug\OneOfMyDlls.dll
but
C:\Project\myproject\OneOfMyDlls\..\Debug\OneOfMyDlls.dll
would have been, after path reduction.
The problem was that the Visual Studio 2017 import had changed the output directory from
..\Debug to .\Debug assuming that the unconventional parent directory use was a mistake. In a large project with 13 DLLs of our own, (never mind second and third party DLLs too), it makes sense to collect all the DLLs in one place and ..\Debug was correct.
So while others might have had to change Linker->Output File, in my case it was General->Output Directory which needed to change as it had been corrupted by the import from Visual Studio 6.
Something like ..\Debug had become something like .\Debug after import. (The real project specific names have been removed .)
Looks like it's not significant for the program:
Odd Visual Studio error when following the custom study video
If, like me, you return to Visual Studio after 20 years, you may not know where the project properties are. In VS 2012: top of the screen "FILE EDIT VIEW PROJECT BUILD..." : choose PROJECT. Properties is the last item in the menu. Indeed for me there was a mismatch in the target name, too.
I've just migrated from VS2005 to VS2010 and it fails to compile a simple program.
#include <iostream>
using std::cout;
using std::endl;
int main()
{
cout << "Hello Visual Studio 2010 :)" << endl;
}
Errors -
1 error TRK0005: Failed to locate: "CL.exe". The system cannot find the file specified.
2 IntelliSense: cannot open source file "iostream"
3 IntelliSense: name followed by '::' must be a class or namespace name
4 IntelliSense: name followed by '::' must be a class or namespace name
5 IntelliSense: identifier "cout" is undefined
6 IntelliSense: identifier "endl" is undefined
PS: I'm completely new to using VS2010 but have experience in VS 2005.
Here are lists of directories that I added from VS2005 to VS2010 under 'user property sheet'
Executable -
$(VCInstallDir)bin; $(VSInstallDir)Common7\Tools\bin; $(VSInstallDir)Common7\tools; $(VSInstallDir)Common7\ide; $(VSInstallDir); $(VSInstallDir)\SDK\v2.0\bin
Include -
$(VCInstallDir)include; $(VCInstallDir)atlmfc\include; $(FrameworkSDKDir)include
Library -
$(VCInstallDir)lib; $(VCInstallDir)atlmfc\lib; $(VCInstallDir)atlmfc\lib\i386; $(FrameworkSDKDir)lib; $(VSInstallDir); $(VSInstallDir)lib
Source -
$(VCInstallDir)atlmfc\src\mfc; $(VCInstallDir)atlmfc\src\mfcm; $(VCInstallDir)atlmfc\src\atl; $(VCInstallDir)crt\src
I've run into the same issue on a couple of different machines where there were other versions of VS (2005, 2008) already installed. I ended up also getting all sorts of strange errors.
I found the following trick worked for me, maybe it will work in your case too:
- Open a new instance of VS2010
- Create new console application with the def settings.
- Try compile: there should be some errors
- Open the "Property Manager"
- Bring up the Microsoft.Cpp.Win32.user property sheet of the project
- Click on VC++ Directories
- Click on the "Executable Directories" field. That should display a drop down, click on the drop down and select "Edit". You should see a bunch of inherited values that supposedly contain all the required directories similar to the ones you listed above. Uncheck the "Inherit from parent or project defaults" option. Recheck it and click "Ok".
- Repeat this for the includes, library directories, etc.
-Click on "Apply" and "Ok"
- Rebuild the project and check if this worked.
I only needed to do this once. After closing VS and creating a new project, I could just compile. Before I discovered this, I manually removed all inherited values and added absolute paths to all the VS and SDK directories. That also worked, but was a lot more work.
The system could not find the Visual C++ compiler (CL.exe)...
Things you should try:
Rerun the Visual Studio 2010 installer and make sure you selected to install Visual C++ tools for your platform (either x86 or amd64).
Run the installer in repair mode.
If this does not solve your problem:
Try to run Visual Studio 2010 Uninstall Utility (by Microsoft) and then try installing VS 2010 again.
I had the same problem and found this page via a search, but I didn't quite grasp Ralf's answer about the user property sheet, and had no luck with re-installing. I think Ralf's answer would have worked for me, but I was looking at the "Property Pages" dialog that comes up when you right-click on a project in the Solution Explorer and choose "Properties". I didn't realize that it was different from the "Property Manager".
So, I asked on the msdn forum and got an answer and a nice explanation of property sheets. The solution that worked for me was to edit the user property sheet in a text editor and delete all the paths, leaving it empty like this:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
</Project>
The user property sheet is Microsoft.Cpp.Win32.user.props under
<localappdata>\microsoft\msbuild\v4.0 where <localappdata> is
c:\users\<username>\appdata\local under Win7.
I have no idea why this worked but I was getting this error and installing Visual Studio Power Commands solved this for me. This extension adds the Configuration Properties -> VC++ Directories that allows you to directly modify the ExecutableDirectories macro, it might have something to do with that.