I'm currently working on a large project with a lot of potential bugs and glitches. I enlisted a few of my friends to help me test the program to find potential bugs but a lot of them aren't very tech savvy and have no idea how visual studio works.
Is there a way I can compile my project so it could run as a stand alone executable? I tried building it and getting the vcxproj file but I still have no idea how to make that a click to run type of program. Any help?
As far as I'm concerned, there is no way to "publish" C++ code.
I suggest you could refer to the link: https://social.msdn.microsoft.com/Forums/en-US/6998eadb-36fb-4a97-bba5-0de49d533732/how-can-i-publish-a-visual-c-project-?forum=vsclassdesigner
If you want to make a stand alone .exe file. I suggest you could try to use "Release" to build a stand alone .exe file. Check the .exe program Configuration Manager, ensure your set Release for your .exe program. (open your .exe program under Solution Explorer, right-click solution and select Configuration Manager).
Related
Basically, I have a Visual Studio project that builds a DLL (a VST audio plugin). Where this type of project scenario has been set up for me in the past, I would be able to build, run, and debug the plugin. Visual studio would automatically launch whichever program I was using to host the plugin. I am trying to achieve the same effect in my current project, but I don't know how to set that up. Currently when I build and run my DLL in Visual Studio, I get the error "Unable to start program". The DLL still builds, and I can still run it, but I can't debug it from Visual Studio, because I don't know what I need to do in my project settings to make this happen. How can I do this?
MORE INFO:
What I do know is that, in projects where this sucessfully works, there are some modifications made to the Visual Studio project settings under fields marked 'pre-build events' and 'post-build events', so presumably what I want to do is edit these in some way to tell Visual Studio the following: "Hey, before you try and run and debug this DLL, you have to launch another program (my program is called Max.exe), and then you have to wait until that program loads the DLL. Then you can debug! Don't be a stupid computer and try to debug it before it's even loaded in Max.exe..."
What I do not know : EVERYTHING ELSE. This is literally all I know about what I'm trying to do, hense the colourful attempt to talk to a computer in English.
Currently when I build and run my DLL in Visual Studio, I get the error "Unable to start program". This is unsurprising seeing as the project knows nothing about the environment I want to use to test the DLL, but the problem is that I don't have a clue what Visual Studio needs to know. I really don't know enough about programming to understand the implications of what I'm trying to do either. Yes, I did mention those fields marked pre-build and post-build because I remember them being important, but I don't know exactly what or how to write in those fields, and I also do not know if there will be more things I need to tell Visual Studio before this will work.
Q.E.D I'm not actually sure what pre and post build events are, or how they work. And I barely know the first thing about customizing VS project settings. All I know is how to write audio processing code. I felt the need for this disclaimer because typically my questions are met with angry programmers who think I don't do my own research; they fail to realize I am an audio engineer who skipped programming 101. Yes, how to debug a dll is a common question I'm sure, but answers to those questions tend to assume pre-requisite knowledge that I do not have.
You will want to edit the Command field in your project's Debugging properties. Right-click on your project in the solution explorer and click Properties (it's generally the last item). Open the Debugging page under Configuration Properties. The Command field indicates which executable to launch when debugging.
By default this contains $(TargetPath) which refers to the final binary your project compiles. This is useless for DLLs since DLLs are not executable. Change this to the path of whatever third party application you are writing a plugin for.
With this change, launching with debugging will actually launch the third party application and attach the debugger to it. Once the application loads your plugin, you will be able to debug it normally.
For Visual Studio,
In Solution Explorer, right click on project and select Properties.
In Properties, choose Configuration Properties -> Debugging.
For Command, enter the full path of the executable that will be loading your DLL. Fill in the Command Arguments and Working Directory accordingly.
In addition, you need to make sure that the executable actually loads the DLL you are building. A mistake that a lot make is to launch their executable, and not realize the executable is loading another version of the DLL they are trying to debug. This can happen due to Windows searching for the first DLL that it finds using the DLL searching logic (exe directory, path, etc.).
I have a large project that I have to load and work on. Nothing I can do about it - just load the solution and all projects within it.
Problem is that first several minutes VS loads project one by one and it constantly inform me about it by constantly displaying some "Loading project is required..." window. Sure, I know it is required, but cannot it be somehow done in the background? I would be content if I could just open some text editor and tune configs or read documentation without popups stealing the focus.
It happens on all project regeneration (we use GYP) - since VS solution and projects are generated each time I have to work on new C++ defines/flags/dependencies settings I have to sit and watch VS spamming those little windows.
It has another drawback - if right after project regeneration I'll try to build it VS will "block" - it will complain that it cannot close the project when build is running and I have to terminate the build in order to "close" the project. I understand that what it really does is close and reopen it in order to update settings... but popup that locks whole IDE certainly makes it more annoying.
I know that I can disable automatic reload of source file when it was edited outside by e.g. Sublime Text. Are there some solutions that would allow me to do the same for projects? Some settings, plugins or register entries that would prevent those windows from spamming or which would reload project when it suits me? It's really annoying when I have to switch to ST each time I regenerate and build projects because Visual Studio will stay locked until the build is finished.
I have a similar issue with CMake-generated Visual Studio solutions. While I don't have a solution, I've found a workaround which works just fine for me - close the solution before re-running the generator, and open it again when the re-run's finished. Under normal keymappings, it's Alt+FT to close, and Alt+FJ1 to open again.
Disable Intellisense, Visual Studio usually takes a great deal of time during project load parsing headers and building up its intellisense database. Disable that and see if your load times improve.
Might not be applicable if you can't change your solution, but I'd try to move less important modules/projects to DLL or prebuilt libraries. Candidates for this are 3rd party / external libraries that you don't plan on changing or potentially really stable sections of your code base.
Good luck.
The VS system records the last solution associated with each project in the .SUO files. If you delete the .SUO files, you will then be able to open the project files individually, and then save a solution containing just the projects you want to open.
i am using c++ in eclipse, a project which contains many header files , cpp files...etc when finally done, how does it actually get implemented in the real world once it is done? Does an .exe file get created ? Or how can users install the program on their computers?
Can you share your experience with me ?
Also can you tell me what IDE you use for C++ development ?
I tried to look through some documentation but could not find anything.
When you compile the code, it will output an executable file (.exe) that can then be run from a command line, double-clicked, or put into an installer. The executable files name will be .exe and placed in the output directory as specified in your project settings.
As mentioned, this can be bundled in an installer but that is very likely overkill and way beyond what you want. So long as you have used standard C/C++ libraries that come installed on a user's system, they can just invoke the program from a command line or simply double-click the executable. If your program doesn't have any interface and simply prints messages, then they person will want to run it from the command line. Finally, if you have used other libraries that you need to include with your program, then an installer may be what you need in order to make sure the end user has everything they need to run your program.
As far as IDE's go, I've used both Eclipse and Visual Studio. Visual Studio is better tailored to C/C++ development (this is assuming you are programming on a Windows machine) but has the downside of costing money if you don't get it through your employer or school. If you can get access to it through either of those channels, I would choose it over Eclipse. Eclipse will do what you want and is free, but Visual Studio might be a bit better. Also, if you are going to spend money anyway, I suggest looking a SlickEdit. I use this at work and really like it for C/C++ development.
I'm having a weird problem with Visual Studio. Whenever I change my code and build, even though I get the notification that the built was successful (and if any, it also shows errors in code and doesn't build) the executable is actually the previous build. This is getting really annoying and frustrating.
If I put a breakpoint on the new lines, the breakpoint gets disabled and it says
The breakpoint will not currently be hit. No executable code is
associated with this line. Possible causes include: preprocessor
directive or compiler/linker optimization
If I put a breakpoint on old lines of code, it stops processing but shows me this message
The source is different from when the module was built. Would you like
the debugger to use it anyway?
I never had this problem before and the source code in on my laptop's hard drive. It saves right away. The only way to get around this to Clean the entire solution manually every time, instead of basically pressing F5.
Thanks everyone for their suggestions. My mistake was that I defined the classes inside .cpp files, this somehow caused the linker to do weird (caching probably) stuff and link the old objects. I renamed the file to .h and everything's working as expected.
Perhaps your code is not built, or is built in a way you don't expect.
You might check by inserting a #error foobar preprocessor directive somewhere. If no error shows when building, you know you are in trouble!
But I never used Visual Studio (I'm only using Linux) so I cannot help more.
It might be that you have set main project some other project and building that.
make your project that you want to work on as "Main Project " by set main project available in menu bar.
I think you are using source files from another project (ex: if you are using a dll say, my.dll (which was built using some source files say, mycpp.cpp ); in your current project).
When you debugged into the file (mycpp.cpp), maybe you modified it.
Hence you need to rebuild the dll (my.dll) first in the project in which you created my.dll .
Or
Maybe you have opened a instance of mycpp.cpp in a window & debugging in another window.
you should rebuild the dll.
If you are not using files from another project, then I cant guess the cause...but still I would recommend using rebuild rather than clean & build.
please clarify your Question a bit.
#David expecting a reply from you...
I was looking for an answer to this issue since I was also stuck with it. A colleague of mine just gave me a solution that works. Yes, it seems really stupid, but it did the trick for me.
Our solution has many projects. He told me to select the project that I wish to break into and set it as the startup project (right-click on the project name and pick "Set as startup project"). I was desperate, so I tried. To my amazement, it works.
Since I have this window opened, I thought I'd share it in case someone else is stuck with the problem.
I faced the same problem. But reason was not as yours.
Then I just restarted the visual studio and it ran as expected.
I am a professional working for a software firm.In my past company basically i was working on C & C++ on unix.Now i suddenly shifted to C++ on Windows and i feel like i am in a completely different world.Basically i am working on a very big application which was totally written in C++.To keep it simple ,i dont have the source code .I have the exe of the application and several other dependent files.it is a GUI application(several windows,reports,graphs and huge mathematical calculations are done by this application).Now i finally have the source code of the application which includes some headers,some vcproj files,some dsw files and several other which i dont even understand why the hell are they present.
Now as i C++ programmer my responsibility is to make all the BUGS that the clients identify replicate and fix them.
If its a bug on unix i can simply use the binary and source code and run gdb/dbx and find out the issue in some or other way like adding adding some printf statements.
But given the files i mentioned above.how could istart debugging an application in VC++ in VISUAL STUDIO.
Is it very difficult for a C++ programmer to shift from Unix to Windows.
Is ther any good resource which i could refer for this kind of change where i could grasp things quickly?
given the exe and the source code of the application how can i start debugging a program by running the application in VS C++-(BTW i am using VS 2005)
The main difference is that on Unix, you'll have Makefiles, which you won't find on Windows. Visual Studio organizes your code in projects and solutions, and those project files contain all the information VS needs to compile&link your projects.
If you have a *.sln file, just double click it to open it in VS. Then build the source (usually by pressing F6) and run in debug mode (usually F5).
More details:
A project is a collection of source files that result in 'something', usually a LIB, a DLL or an EXE.
A solution is a collection of projects. Useful when e.g. one project creates a LIB that is used by another project. When you set dependencies between projects, VS will build the projects in the right order.
Extensions used:
*.vcproj : Project file for C/C++ sources
*.vcproj..user : contains which windows are open in the GUI.
Can safely be deleted.
*.sln : Solution file
*.ncb : Intellisense database for a solution. Can safely be deleted.
*.suo : contains which windows are open in the GUI. Can safely be deleted.
*.dsw : Visual Studio 6.0 related file - not used in VS2005. (Replaced by *.sln IIRC)
./Debug/* : folder with all
intermediate files for a Debug build
(can be changed)
./Release/* : folder with all
intermediate files for a Release
build (can be changed)
That's all I can think of at the moment.
If you only have a .DSW file and not a .SLN file, then it means that the project was probably last worked on with VC6 and not one of the later Visual Studio versions.
That's a shame, because there have been lots of changes to the C++ compiler since VC6, and you're probably going to find the project doesn't compile with VS2005 without needing some minor changes to source code.
Do you have a .SLN file - if so, what's the version number at the top of the file (it's a text file)? If you don't have a .SLN file, can you get hold of VC6?
I would always try to get stuff going on an unfamiliar platform with the best matching tools, before I tried to bring it forward to later versions.
I understand your pain; I took the same path a few months ago.
You probably figured it out, but Visual Studio is not the exact alternative of gcc/g++. It embeds a text editor, a debugger, and so on.
Usually, you have two compilation "modes", debug and release. (you can add your own)
When in debug mode, all optimization are disabled and you can execute your program in the debugger, use step by step, add breakpoints, ...
Just start it using the F5 key.
More notes on the additional files:
In the Visual Studio world, .vcproj files represents "projects": a bunch of file that belongs to the same project (source files, headers, resources, ...).
A .dsw (old name for current .sln files I believe) is a "solution" file: a group of one or several projects which can have internal dependencies. Example: you can have in the same solution, a library and a software that depends on it. So that when you compile the whole solution, things are built in the correct order.
First thing you should try is to attach to the process while it's running (Ctr-Alt-P and select the process) if you have the .pdb (debug information) files you should be able to debug the process without re-building it.
If that fails try to un-check the "Require source files to exactly match the original version" option in Tools -> Options -> Debugging.
If that too fails you'll have to build the application again (by opening the .sln file and performing a build) so that the binary matches your source files.
Good luck.
Compile the code with debug info and press f5 (Start Debugging). I don't see where is the problem. On linux is sort of the same.
VS2005 can convert the dsw file for you to a sln file, but you need all of the original VC6 files in order for the conversion to be successful. For debugging please check out following msdn link, I hope this will help you.
http://msdn.microsoft.com/en-us/library/sc65sadd.aspx
Please select hyperlink "Debugging Native Code" for C++ specific.