I've recently been busy working on making proper build scripts for a code library I've been designing, and have been stuck on getting MSBuild to properly compile for my Windows builds. What I'm trying to do is call MSBuild from a batch script without it opening the Visual Studio IDE, which it appears to constantly do if I'm not executing it from the Developer Command Prompt for Visual Studio. My script is simple enough, just calling
start C:\Program Files (x86)\...\MSBuild\15.0\Bin\MSBuild.exe <Project>.sln
Besides a few other specifiers tagged onto the end of it, that's what I'm trying to use to run my Windows builds. The issue here is that whenever this code is called outside of the VS Dev Prompt, Visual Studio itself opens, not building the code at all. I couldn't find anyone else struggling with this same issue either, as it seems to be new to the integration of MSBuild and Visual Studio. Testing with older versions of MSBuild went to show that I could build projects as I wanted to outside of the Dev Prompt. Could I be missing some environment variable supplied in the Dev Prompt that changes the executable behavior? I couldn't seem to find any executable specifiers that would change this, either.
Maybe I'm taking a completely wrong approach to this problem? My end goal is to provide consumers with a collection of build scripts, one for each platform they're targeting, so I am definitely open to other solutions.
The canonical answer:
You can use the devenv command with the /build command line option and the name of your project file.
Alternatively, you can run one of the vcvars*.bat scripts to set up the necessary environment and then use msbuild.
For more info, see https://learn.microsoft.com/en-gb/cpp/build/building-on-the-command-line.
Update: Contrary to the official advice above, this is what works on my laptop with VS2017 community edition.
Setup the environment by running the bat file that is targeted by the "developer command prompt for VS2017". (Right-click on that in the start menu, then select "Open file location" then right-click on the shortcut and select "properties". For me that is "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\VsDevCmd.bat".
You should call this file from your build script.
cd to your project directory and then use msbuild like this:
msbuild My-project.vcxproj /p:Configuration=Release
For some really strange reason I can use the devenv method if I open the official developer command prompt but launching devenv from another command prompt even with the environment variables set does nothing. (And I even compared the set of environment variables in both command prompts and they are equal.)
How to Run MSBuild Outside of the MSVS Dev Prompt?
If the necessary environment not be set correct, then the build command becomes " mysolution.sln". And executing it indeed starts VS. So you should run the vcvars*.bat scripts to set up the necessary environment and then use msbuild. Following is my a batch script, it has been working for some time, you can check it:
#echo OFF
call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\Tools\VsDevCmd.bat"
echo "Starting Build for all Projects with proposed changes"
MSBuild.exe "C:\Users\Admin\Source\repos\MyTestProject\MyTestProject.sln"
pause
echo "All builds completed."
Here is the test sample result:
See How to create a Simple Build Script for Visual Studio from the Command Line? for more details.
Related
I linked Qt5.12.1 with Visual Studio 2017.
I want to use Qt's cmd.exe terminal to qmake an application. But, each time I open the Qt's cmd.exe terminal, it tells that
Setting up environment for Qt usage...
Remember to call vcvarsall.bat to complete environment setup!
So I must to run vcvarsall.bat, and only then I can qmake. But I think that is too troublesome. Are there any ideas to solve that problem, so that I wouldn't need to manually run vcvarsall.bat every time I open the cmd.exe terminal.
See existing Qt bug reports about the same issue you have discovered like 1 and 2. Unfortunately, you can't avoid it in Qt 5 until the issue is fixed (if ever).
But I think you could check properties of the Qt command prompt entry (press right mouse button on top of the entry which you clicked to open the command prompt) in Start menu to see which bat file it's calling and edit that script.
I think you could add something like below to the end of the bat file to get vcvarsall called automatically. Check where vccarsall.bat is located in your VS version and depending on your environment use either x86 or amd64. Note that the following line is only to get you an idea how to call another bat file from a bat file, this line sets VS2015 64bit env.
CALL "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64
I have a Linux project witch I developed in vim and now I'd like to go on developing it in Visual Studio with IntelliSense etc.
It's a Makefile project so I need to build it on the Linux machine.
I already created the project and created the connection and it works but I can't build because I am building with a prefix script so I open a new interactive shell with something like this
set -i
. "/tools/dist/xxxx-2010.0"/etc/profile
I don't think that visual studio can handle such thing.
Is there a way to do it?
I am calling my startprefix script with an alias then it starts the interactive shell and then I enter my make commands for usual but in visual studio it won't build it stops at t he very beginning after executing the first command (which is the startprefix alias)
And another thing is that I don't see any project files in my solution I unloaded and loaded the project but it won't get me the source files. Am I doing something wrong?
The Visual Studio C++ for Linux add-in supports MSBuild, makefile and CMake projects. If you already have the makefile then create a new Linux makefile project in VS, add in the source files and hit F5 to build.
Trying to read between the lines of your question:
C++ for Linux is optional and must be installed
thru the VS installer.
Everything, i.e editing, building, debugging, is run in VS from the
Windows host.
The source resides on the Windows host (although you can do things with shared drives if needed).
The Linux remote is just that, remote.
You might need to interact with the Linux remote to debug an
X-Windows based GUI application but console applications can be
debugged entirely on the Windows host.
If you have other commands that you need to run before and/or after the makefile then you can set these up in the VS project settings. Likewise and parameters you need to pass to make.
I am trying to check if the visual studio compiler exist in my path. I have add vc/bin dir to the system environment path. When I open a windows console terminal I try to call cl.exe from the console. I am receiving the following message:
The program cant start because mspdb140.dll is missing from your computer. Try reinstalling the program to fix this problem.
What exactly is this message stands about? I tried to followed the instructions from this post, I run the bat file, (furthremore I add manually the dll dir in the path). However I am receiving the same message.
I have add vc/bin dir to the system environment path
That certainly isn't enough. Unclear what else you are doing. There are a wholeheckofalot more environment variables that need to be hacked correctly to allow proper compiling and linking. The values of INCLUDE and LIB are critical for example.
There is a .bat file that takes care of it, vc/vcvarsall.bat in the VS install directory. You pass the architecture you want to target, default is x86. Be sure you use the CALL statement if you use a .bat file yourself and that you in fact see the variables being set correctly with, say, SET INCLUDE. Watch out for a broken PATH variable, a very common scourge on programmers' machines. Usually corrupted by a wonky installer.
The VS installer creates shortcuts to run this .bat file. Used to be named "Visual Studio Command Prompt", might be "Developer Command Prompt". Got pretty muddy since Windows 8.
I personally just an entry in the VS Tools menu. Very handy. Use Tools > External Tools > Add button. And fill out the dialog similar to this:
Title = Command Prompt
Command = cmd.exe
Arguments = /k ""C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"" x86
Initial directory = $(ProjectDir)
Tweak 14.0 to the version number of your VS version, that's VS2015. VS2013 = 12.0, VS2012 = 11.0, VS2010 = 10.0
I downloaded the latest Visual Studio to be able to use its command line compiler cl.exe.
When I do:
"<full path to cl.exe>" /I"<full path to my include folder>" "<full path to my .cpp>" /Fe"<Full path to the output .exe>"
I get the error saying that mspdb110.dll is missing.
I did add its folder to the system path, and I don't get that problem if I run my command console "as administrator".
I see other posts suggesting that I use "Developer Command Prompt" (and run it as administrator).
Is there no work around to use my regular command prompt to build my program specifying the necessary options for cl.exe directly? For one thing, I am not able to "Drag and drop" the .cpp into the console window, automatically getting its full path there.
As soon as I open the VS cmd prompt it says "ERROR: Cannot determine the location of the VS Common Tools folder." I'm trying to compile and eventually run my program using a compile.bat and run.bat file.
My program successfully compiled ONCE when I had the following in my compile.bat file:
call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"
FileMgr.sln /rebuild debug
pause
After it worked, I tried adding the path of vcvarsall.bat in the variable "Path" in Environment Variables, hoping I wouldn't need that initial call line in the .bat file. This didn't work so I deleted the newly added path from "Path" but now I'm getting this error.
This can only go wrong if the registry is messed up on your machine or the VS install didn't go well. The .bat file reads the setting from the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\SxS\VS7\10.0 value. Insert Wow6432Node for a 64-bit operating system. Double-check with regedit.exe, the SysInternals' ProcMon utility is always handy to troubleshoot registry problems.
Get your machine stable again, ask questions about that at superuser.com. Try a VS2010 repair to fix the registry first, reinstall next. Shove it out of a 4th story window if all fails.