I want to write a native custom visualizer for visual studio debugger. I started from scratch and I am following this example
https://github.com/microsoft/ConcordExtensibilitySamples/tree/main/CppCustomVisualizer/dll
But I am stuck generating the equivalent for "CppCustomVisualizer.Contract.h".
It is required to compile CppCustomVisualizer.dll. I read that vsdconfigtool generates this file, however when I run "vsdconfigtool mymodule.vsdconfigxml mymodule.vsdconfig" it says an input dll is required
"ERROR: No input dlls were specified on the command line. At least one .dll file is required to output a .vsdconfig file."
What is this input DLL?
It turns out there are two syntax, one for generating the header file and another for generating the vsdconfig file, I was mistakenly trying to generate both header and vsdconfig file in the same step. This is the syntax:
synax: VsdConfigTool <input_config> <input_dll> <ouput_config>
-or-
VsdConfigTool <input_config> <output_header>
mymodule.contract.h
If I run vsdconfigtool mymodule.vsdconfigxml mymodule.contract.h it generates the header file mymodule.contract.h.
Then, to generate the mymodule.vsdconfig, after having compiled mymodule.dll, vsdconfigtool mymodule.vsdconfigxml mymodule.dll mymodule.vsdconfig.
Related
I want a run a build step that looks at a .h file, adds some code based on some external params, and hands the resulting file to the preprocessor.
I see the "Custom Build Step" in the project properties. It seems to need an output file. I just want to forward the results to the preprocessor.
It seems like the custom build step wants to do a 1-time process, not per-file or by file type.
The problem is that I don't know how to send my external executable the file currently being processed (eg, "HelloWorld.cpp"). $(InputName) and %(Filename) are blank and docs say it's deprecated. How do I send the filename to my external executable?
But even if I get that working, I don't want to set this per-file. I want all header files to go through this process.
Any ideas?
I've looked at:
https://msdn.microsoft.com/en-us/library/dd293663.aspx?f=255&MSPPError=-2147217396
https://msdn.microsoft.com/en-us/library/hefydhhy(v=vs.90).aspx
https://msdn.microsoft.com/en-us/library/ff770593(v=vs.140).aspx
working on a debug, x64 config on windows.
First of all, No, you cannot modify a file and pass along the results to the next stage (that I could see). I'd need some sort of Program Transformation System.
So I need an intermediate file. That file has to be added to the project, even if it gets overwritten by your code generator. I can associate c++ header files with a custom build tool, and they will all get called one-by-one in the stage of the build specified in the Custom Build Step. The custom build tool will modify the intermediate file(s), and all is well.
The VS 2015 name for the current file being processed is %(Filename). In older versions it has been $(ProjectName) and $(InputName).
When I run the Debug in Visual Studio for a project, fopen function works fine. It tries to open a file contained in the project and that I added in the filter "Resources".
But when I run .EXE file of my project, I get the null pointer exception: 0x000005c.
When I added the file to be in the same directory as my .EXE file, the exception disappeared.
This is the instruction I use :
fopen(&filename, "rb");
I know it is adviced to use fopen_s instead, but the file is not found anyway...
Apparently, the file is searched always in the current directory...
So, how to include the file in .EXE and make the path of the file relative to the .EXE, at a way it will be contained in the .EXE and not added to the directory where there is .EXE?
You can't include the file in the .exe. You just need to make sure that the file is in the same directory as the .exe.
If you really, really want to only use one file, you could either:
Zip the .exe and the text file together and make sure you include in a readme that the text file needs to be in the same location as the .exe
Use an array/struct/some other way of storing the contents of the file in the program itself, and reference that instead of using a file (I assume you don't care about users being able to edit this data outside of an instance of the program since you wanted it bundled with an executable, so the file is unnecessary in that case)
The reason the program only works when you put the file in the directory of the .exe is because the path to the file is defined in the program as something like .\file.txt or file.txt. When the file isn't in the same directory as the .exe, the program will try to find it, and will be unable to, which is why you get the error. It works when you debug because you have a copy of the text file in the same location as the debug .exe.
EDIT: I would also ignore the warnings about fopen_s and other variant's that append a _s to the end of a command - these are windows specific, non-standard, and in most cases, pointless. If you know this program will only be used in windows environments and you're not doing something for school where you are required to write standard code, I suggest you use the _s variants for the sake of security, but it will reduce portability of your code.
I am new to c++ and am making a very simple program. All my program does is call a function from the main function, which reads in a text file and returns. To check that I am reading in the file correctly, I am trying to print out the strings I have read in. The print out (cout) works properly when I run from Visual Studio (f5). However, when I run the executable from command line, none of the print outs from my function show up. Only print outs directly in the main function appear. I cannot find a similar question elsewhere. Any help would be appreciated.
When you run a program from within VC++ the current directory is set to the project directory by default, but the application is by default in a different folder.
E.g. the application may be:
D:\Work\MyApp\Debug\MyApp.exe
But the project directory may be:
D:\Work\MyApp\MyApp\
When you start the program from outside of VC++ you need to take steps to make sure the current directory is correct, or that the executable and any data files it refers to are in the same folder.
The default working directory for an IDE-launched project in Visual Studio is the project folder. This is the folder where you project file resides (the .vcproj or .vcprojx file is the project file).
If the data file you are reading is in the same folder, code like this:
std::ifstream inf("datafile.txt");
will succeed because the current working folder and the folder where the data file resides are the same.
However, if you switch to where the executable was written (typically this is the project-dir/Debug or project-dir/Release folders) and run the same executable from a command-shell, the data file will not be found.
To test this is the case. Do the following:
Open a command prompt.
Switch to the project folder where your data file resides.
Run the executable with a specified path: ./Debug/YourProgram.exe, for example.
Note: you can avoid this by having the program take the data file name as an argv[] parameter. Then your program will simply use whatever file you tell it to at launch-time.
I have a compiled fortran 90 code "NewSourceID.exe"in folder E:\TROUBLESHOOT. This uses input file MAIN.IN in the same folder. I use a batch script run_sa.BAT in the same folder E:\TROUBLESHOOT to run this executable. This batch script is generated at run time by another VB code (this is a requirement and cannot be done away with) and the batch script reads as following.
"E:\TROUBLESHOOT\NewSourceID.exe" "E:\TROUBLESHOOT\MAIN.IN".
There are two scenarios
1. When I go to the folder E:\TROUBLESHOOT and double click the batch script run_sa.BAT the NewSourceID.exe runs correctly without any problem. It runs on the command prompt window showing the path C:\WINDOWS\system32\command.exe.
When I run the same from the VB script by generating the batch script at runtime I get the following error.
"
C:\Documents and Settings\epsuser\My Documents>"E:\TROUBLESHOOT\NewSourceID.exe"
"E:\TROUBLESHOOT\MAIN.IN"
forrtl: severe (29): file not found, unit 31, file C:\Documents and Settings\eps
user\My Documents\MAIN.IN
The code tries to find the input file MAIN.IN on the path C:\Documents and Settings\epsuser\My Documents\MAIN.IN which is not the correct path to look for the file.
This happened when I replaced the NewSourceID.exe with a modified one. Earlier the code used to run correctly even from the VB with the following path. C:\WINDOWS\system32\command.exe -E:\TROUBLESHOOT\run_sa.BAT. How can this be done?
Are you sure, the Fortran program NewSourceID reads the command line argument you pass to it? Especially older Fortran programs (before Fortran 2003) had no standard way to parse command line arguments. I guess, the name MAIN.IN is hardwired in the code you use, and it always uses the MAIN.IN file from the current directory. You could work around this by issuing a change directory command before executing the program. I am not very familiar with Windows, but something like
cd E:\TROUBLESHOOT
E:\TROUBLESHOOT\NewSourceID.exe
in your batch script would probably work.
Alternatively, you could implement proper command line argument parsing in your Fortran code, using the command_argument_count() and get_command_argument() functions. You would need a Fortran 2003 compiler for that.
I have a library and I have generated tcl bindings for the same using swig. The dll thus generated is xyz_tcl.dll if my original lib dll us xyz.dll. but when I try to load the dll its says "invalid command name "MZ"". Can any one tell me what could be reason for it.
The MZ is almost certainly the first few bytes of the DLL (it's the “magic number” of the file format) so at a guess you're trying to do:
source xyz_tcl.dll
That won't work. It contains compiled C code that integrates with Tcl, but not a Tcl script. Instead, you need to do:
load xyz_tcl.dll
Of course, it should be build into a package (which is a directory containing the required DLLs and a file pkgIndex.tcl) which would then let you do something like this instead:
package require xyz
(The pkgIndex.tcl file contains instructions on how to define the package using the other files, through load and source as necessary.)
I think that something (tcl?) is trying to execute the DLL as a script - the first two bytes of a Windows executable file are 'M' and 'Z'.
For historical reasons, every Win32 executable has a small 16-bit MS-DOS header just before the actual Win32 PE header, and the signature bytes for the 16-bit header are "MZ".