I have made a program on visual studio (2019) and want to run it without using the debugging mode without visual studio open.
Debug > Start without Debugging.
The shortcut is Ctrl-F5.
Edit: After building, you can simply launch the executable code in the build output folder. For example, for an executable C# .NET project, this will be something like /MyProject/bin/Debug/MyProject.exe
where MyProject is your project's name, and Debug will be the configuration name (e.g. Debug, Release, x86, etc).
Related
I was a CLION user for long, and until recently I switched to visual studio 2017 since CLION uses too much memory.
In CLION, basically I can cmake the whole project with the top-level cmake file and generates multiple targets to select from a drop-down button.
I did the same in visual studio except in visual studio I need to run the cmake first to generate a .sln file and open it in visual studio.
After open this, I can see different class instances(my targets) in the solution explorer, but I do not know where to specify which target to run. Each of my target has its own main function. Also, I have integrates all my targets into a top level object called BUILD_ALL. I can build this build_all which builds all of my individual target. But still i dont know how to run each one.
I tried by using the right-click and start a new instance, but it rebuilds the target everytime which is not wanted. In Clion, this is not a problem.
Could someone help on this?
Thanks in advance.
I would suggest using the Set as Startup Project option. This will make it so the build and debug shortcuts target the selected project.
Right click on the project in the solution explorer and choose Set as Startup Project
Another option is to just build and or debug the project directly from the right click context menu.
Depending on how much you work with CMake and Visual Studio you may want to look into VS_STARTUP_PROJECT
When using Visual Studio 2008 under MPI cluster debugger, each execution is launched without moving the generated binaries (.exe, .lib).
When using Visual Studio 2010 under MPI cluster debugger, each execution is launched by moving the generated binaries (.exe, .lib) in two directories :
- all the .lib are first copied inside the .exe directory
- once done, all the .exe directory is copied inside a temporary directory containing by default the user login name.
So with Visual Studio 2008, each execution of a medium size C++ project takes a few seconds to be launched.
With Visual Studio 2010, each execution of a medium size C++ project takes several minutes.
Is there a way to change the behaviour of Visual Studio 2010 in order to work like Visual Studio 2008 did ?
Or if not possible, is there a way to improve the launching time of each execution ?
I am using MPICH2 for MPI and execute my project only locally (localhost/2 environment with -localonly mpiexec argument), for Visual Studio 2008 and Visual Studio 2010.
Thanks for any help.
Do review the MSDN page that describes the MPI debugger configuration. Note how the descriptions of the Deployment Directory and Working Directory properties describe what you see.
However, you are not actually debugging on a cluster so you don't need to have these copies made. Without otherwise knowing what your config looks like, or any way to test it, I'd guess that you have these properties set wrong. As documented on the page, for local debugging you should select:
Deployment Directory: none
Working Directory: the output directory of your project.
Which should avoid the copying.
Today I have upgraded a VS 2008 project to VS 2010 simply by opening the solution file (right click -> open with -> Visual Studio 2010).
I have successfully built the project (debug and release configurations). When I run the project within Visual Studio I get the following weird error:
Notice that \.\? The actual path on my computer is C:\xxxxxx\Application\Debug
What is the cause of path being messed up? And how to fix it? Anyone knows?
BTW. The executable is in \Debug folder and runs fine if I click on it
EDIT
Language: C++ (MFC)
The Output Directory was hardcoded in VS2008 configuration properties to:
Output directory: .\Debug\.
Intermediate directory: .\Debug\tmp\.
If I change that to $(SolutionDir)$(Configuration)\ and $(Configuration)\ respectively the output folders are messed up completely: the \Debug folder is full with .sbr files and all the object files are located in \Debug\tmp after I build the solution. Even though when I build (after changing the output configurations) it says successfully built, but it can't find the .exe file
There are several third party libs but I don't see how that would affect it in any way.
[SOLVED]
VS 2010 apparently handles the project configurations differently than VS 2008. Having the output path hardcoded in the 2008 configurations caused confusions for 2010. I have replaced the hardcoded paths with VS defaults (using variables instead) and the problem was solved
I've been using CMake for quite some time to generate VS 2008 solutions to build a program, its installer, and its packager (as well as several test programs). In order to run, the program needs several dlls which the install project puts into a bin directory, along with the generated executable. Under VS 2008, if I want to debug the created program, I build the INSTALL project, and then click Debug->Start Debugging. The first time I do this after generating the solution, this presents me with a dialog from which I can browse to the bin folder and then the desired executable.
However, under Visual Studio 2010, after clicking Debug->Start Debugging, I do not get the dialog, but rather get the message that it can't find the ALL_BUILD program (which does not, and should not, exist). I can change the start up project to be the executable in question (or right click on it and choose debug), but then that loads the executable from the wrong path and is therefore unable to find the dlls. I know that I could either add the dlls to my system path or copy the dlls into the same directory where the executable is initially created, but these are less-than-ideal solutions (for testing and portability reasons), and these steps were not required in VS 2008.
This is the exact same CMakeLists.txt file for both cases, and the exact same source code. The only difference is that CMake is run with the "Visual Studio 9 2008" generator in the first case and the "Visual Studio 10" generator in the second case.
I can run the generated program from the bin directory using Windows Explorer, but I am not able to debug it (e.g., step through a problem area line-by-line).
You need to edit the debug properties of your start up project so the command line and working directory match your install location.
In Visual C++ inside Visual Studio, one of the project subtypes is a "Makefile Project".
But there doesn't seem to be an equivalent for Visual C# inside Visual Studio?
BTW, a Makefile project is:
If you have a project that you build from the command line with a
makefile, then the Visual Studio development environment will not
recognize your project. To open and build your project using Visual
Studio, first create an empty project containing the appropriate build
settings using the Makefile Project Wizard. You can then use this
project to build your project from the Visual Studio development
environment.
The project displays no files in Solution Explorer. The project
specifies the build settings, which are reflected in the project's
property page.
The equivalent of make in Visual Studio world is msbuild. Visual Studio does not use make. .csproj, .vbproj etc. are input files for msbuild. You can do pretty much the same stuff in them as in conventional makefiles, including command line building, custom targets etc.
There's nothing C++-specific about the Makefile project type; it just runs a command line. It's just that it's listed along with the Visual C++ project types. You can add one to a solution that otherwise contains nothing but C# projects.
Alternatively, you could set up a pre-build step in your C# project that directly runs nmake, msbuild or even NAnt.
Msbuild is what is used to build your projects when you hit the Play button. Personally I like NAnt + NantContrib it was easier for me to pick up and start using right away. For all new projects I use tree surgeon this tool creates a default build script and proper build tree with testing project and code coverage report.