While searching through my file directories, I came across a batch file that I had not created. While running the program, (after safety removing all external devices and logging out of all possible accounts) A CMD box would open for a brief second and then close. Upon editing the code so the CMD box would pause, I discovered what its doing.
Below is the original text from the batch file:
PUSHD .
cd %windir%\system32
#setlocal
#set logfile="%temp%\bcm_vc80redist.log"
#echo [%date% %time%] START vcredist_x86.exe /q:a /r:i /c:"msiexec /i vcredist.msi /qn" >> %logfile%
vcredist_x86.exe /q:a /r:i /c:"msiexec /i vcredist.msi /qn"
#if errorlevel 0 echo vcredist_x86.exe exited with errorlevel=%errorlevel% >> %logfile%
#echo [%date% %time%] END vcredist_x86.exe /q:a /r:i /c:"msiexec /i vcredist.msi /qn" >> %logfile%
#endlocal
POPD
{Pause}--This isnt part of the original code, this is added to stop the CMD box from closing.
It appears that some point you installed a "Visual C++ Redistributable Package" and the batch file is a leftover from the installation.
You can look in %temp%\bcm_vc80redist.log to see exactly what was installed.
Source Developer Tools
Visual C++ Redistributable Packages for Visual Studio 2013
The Visual C++ Redistributable Packages install run-time components
that are required to run C++ applications that are built by using
Visual Studio 2013.
The Visual C++ Redistributable Packages install run-time components
that are required to run applications that are developed by using
Visual Studio 2013, on computers that don't have Visual Studio 2013
installed. These packages install run-time components of these
libraries: C Runtime (CRT), Standard C++, ATL, MFC, C++ AMP, and
OpenMP.
Related
I am running tcl/tk (8.5) with an external c library to interface to an d2xx USB library. I am running Windows 8 and trying to compile the library using the VS 2012 Native Tools Command Prompt. When I start the command prompt my PWD is:
\Program Files (x86)\Microsoft Visual Studio 11.0\VC
The c library (tclftd2xx.c) comes with nmake files for virtual studio that properly sets up the environment to link to the required tcl libraries and with the d2xx header.
In the VS command window, I CD to the directory containing the makefile.vc and type:
nmake .....
and I get my tclftd2xx.dll.
tclftd2xx.dll calls msvcr110.dll. When both of these are properly placed in /Tcl/lib, they work great on my Windows 8 system, and on Vista and Windows 7.
However, when installed on Windows XP, windows cannot load the tclftd2xx.dll.
I did some searches and discovered that I have to configure VS2012 for v110_xp toolset. The link (http://blogs.msdn.com/b/vcblog/archive/2012/10/08/10357555.aspx) has this note:
Visual Studio 2012 solutions and projects which have been switched to
the v110_xp toolset can be built from the command line using MSBuild
or DEVENV without additional steps.
However, if you wish to use CL and Link directly, additional steps are
needed. Note that the steps below may be automated by creating a batch
script.
Which I did here:
REM set include and path variables
set INCLUDE=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Include;%INCLUDE%
set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH%
REM When targeting X86, set the lib path as follows:
set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib;%LIB%
REM set the compiler options
set CL=/D_USING_V110_SDK71_;%CL%
REM When targeting x64, set the lib path as follows:
REM set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib\x64;%LIB%
REM Specify the correct subsystem and subsystem version for the linker based on the type of
REM application you are building. Applications targeting the x86 version of Windows XP must specify
REM subsystem version 5.01, and applications targeting x64 must specify version 5.02.
REM For x86 console applications:
set LINK=/SUBSYSTEM:CONSOLE,5.01 %LINK%
REM For x64 console applications:
REM set LINK=/SUBSYSTEM:CONSOLE,5.02 %LINK%
To build the xp version, from a VS command line I
1) ran the .bat file
2) nmake .....
I get a .dll that is exactly the same size as the windows 8 targeted dll.
So I have two questions:
Is there some other magic configuration script or environment variable I have to run to enable the v110_xp toolset in addition to executing the .bat file, or does executing the .bat file do the full configuration?
Is there some way to confirm that the .dll is indeed targeted for an XP system other than trying to load it on the XP system?
I came up with the following batch script to set the variables. It seems, I will have to include this with my project to let people build my code with visual studio 2012.
#echo off
goto :start
:check_dir
if not exist "%~1" (
echo Directory "%~1" does not exist.
echo Things may not work as expected.
)
goto :eof
:start
setlocal
if "%PROCESSOR_ARCHITECTURE%" == "x86" (
set "ProgramFiles(x86)=%ProgramFiles%"
)
set "BINDIR=%ProgramFiles(x86)%\Microsoft SDKs\Windows\v7.1A\Bin"
set "INCDIR=%ProgramFiles(x86)%\Microsoft SDKs\Windows\v7.1A\Include"
set "LIBDIR=%ProgramFiles(x86)%\Microsoft SDKs\Windows\v7.1A\Lib"
set "SUBSYS=CONSOLE,5.01"
REM for x64 instead of x86:
REM set "LIBDIR=%ProgramFiles(x86)%\Microsoft SDKs\Windows\v7.1A\Lib\x64"
REM set "SUBSYS=CONSOLE,5.02"
call :check_dir "%%BINDIR%%"
call :check_dir "%%INCDIR%%"
call :check_dir "%%LIBDIR%%"
endlocal & (
set "CL=/D_USING_V110_SDK71_;%CL%"
set "LINK=/SUBSYSTEM:%SUBSYS% %LINK%"
set "LIB=%LIBDIR%;%LIB%"
set "PATH=%BINDIR%;%PATH%"
set "INCLUDE=%INCDIR%;%INCLUDE%"
)
You should not have to include both the msvcrt and the tclftd2xx dlls. The compiler generates a manifest that prodvides the necessary information to the runtime loader to state which C++ runtime should be loaded. The error you are seeing is that the rules.vc file needs updating to support the newer compilers. Once this is done the makefile variable _VC_MANIFEST_EMBED_DLL will get set to the command required to merge the compiler manifest file into the resulting DLL.
I've updated the project at github so this should no longer be a problem.
What's the difference between "visual studio x64 win64 command prompt", "visual studio x64 cross tools command prompt", and "visual studio command prompt" appearing in the Visual Studio 2010 menu in the Start button?
For the most useful answer, let us be clear about my ignorance level: I'm closer to noob than guru at anything Microsoft or IDEs in general. Long time expert at Linux, editing source in a plain text editor, handmade Makefiles, etc.
I'm sure the differences are simple, perhaps "obvious" to anyone with modest experience at VS2010.
The different batch files adjust PATH, LIB, INCLUDE and LIBPATH so that you can run cl.exe and other build tools easily.
This answer focuses mostly on VS2013. Microsoft's documentation http://msdn.microsoft.com/en-us/library/ms229859%28v=vs.110%29.aspx states:
Starting with Visual Studio 2010, you may see multiple command prompts, depending on the version of Visual Studio and any additional SDKs you've installed. For example, 64-bit versions of Visual Studio provide both 32-bit and 64-bit command prompts. (The 32-bit and 64-bit versions of most tools are identical; however, a few tools make changes specific to 32-bit and 64-bit environments.)
It adds, rather unhelpfully:
Check the documentation for the individual tools to determine which version of the command prompt you should use.
The page http://msdn.microsoft.com/en-us/library/jj153218.aspx lists five such command prompts:
Developer Command Prompt for VS2013
VS2013 ARM Cross Tools Command Prompt
VS2013 x64 Cross Tools Command Prompt
VS2013 x64 Native Tools Command Prompt
VS2013 x86 Native Tools Command Prompt
On my machine, only the 1st, 3rd, and 5th of these are present, and they launch, respectively:
%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\VsDevCmd.bat""
%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat"" x86_amd64
%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat"" x86
To check the environment variables, running the set command for first and "x86 Native" shells gives identical results on my machine. And mmohamad's answer tp Difference between VsDevCmd.bat & vcvarsall.bat in VS2012 agrees with this.
But "x64 Cross" is different: the difference is (excluding Path and LIBPATH for brevity):
+ CommandPromptType=Cross
+ FrameworkDIR64=C:\WINDOWS\Microsoft.NET\Framework64
+ FrameworkVersion64=v4.0.30319
+ Platform=x64
- LIB=C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\LIB;C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x86;
+ LIB=C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\LIB\amd64;C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x64;
I just installed Windows SDK 7.1 on Windows XP Professional with SP3. Now I'm checking to see if the installation is OK and, already, I'm having a problem. I still cannot get cl.exe compile a simple hello world C++ code from the Windows SDK 7.1 Command Prompt. Here is a snapshot of command prompt output:
Setting SDK environment relative to C:\Program Files\Microsoft SDKs\Windows\v7.1\.
Targeting Windows XP x86 Debug
C:\Program Files\Microsoft SDKs\Windows\v7.1>cd /d "D:\My Documents\Sources"
D:\My Documents\Sources>cl /EHsc /FeD:\Target\hello hello.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
hello.cpp
Microsoft (R) Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
LINK : fatal error LNK1104: cannot open file 'C:\Documents'
I tried moving hello.cpp to D:\ and ended up with the same result. CSC.exe, on the other hand, compiled a hello world C# code in the same command prompt without a hitch. What should I do now?
Note that I do not have any version of Visual Studio installed. I installed Windows SDK so that I can use Qt Framework 4.8.0 for VS2010 in Qt Creator and learn a little bit of C# in SharpDevelop.
Some people adviced me to wrap all environment variable values containing C:\Documents and Settings\ in double quotes, e.g.: Set ALLUSERSPROFILE="C:\Documents and Settings\All Users", Set USERPROFILE="C:\Documents and Settings\Ant Luc", and so forth. There was no sane way to perform the modification, except for %TEMP% and %TMP%, since they were not available for editing through System Properties > Advanced > Environment Variables. So I edited C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd and added the following lines right below #ECHO OFF:
SET ALLUSERSPROFILE="C:\Documents and Settings\All Users"
SET USERPROFILE="C:\Documents and Settings\Ant Luc"
SET HOMEPATH="C:\Documents and Settings\Ant Luc"
SET APPDATA="%USERPROFILE%\Application Data"
SET TEMP="%USERPROFILE%\Local Settings\Temp"
SET TMP="%USERPROFILE%\Local Settings\Temp"
But I then got Error C1083 when compiling the hello world code with cl.exe. In desperation, I edited C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd again, and changed the value for %TMP% to D:\VSTEMP, created a directory called VSTEMP in D:\, tried to compile the source code again, and sighed in relief because it finally compiled successfully.
I decided to grab and install Visual Studio 2010 Express out of curiosity, opened Visual Studio Command Prompt, tried to compile the same hello world code, and was faced with the same set of problems which I fixed with the same workaround. Conclusion: the compiler (or linker) cannot properly handle whitespace in %TMP% -- assign a directory without a single whitespace to it.
I still do not know what is wrong with my setup, but all this hassle seems stupid anyway. FWIW, this is the first toolchain that made me jump through hoops just to get a hello world code compile successfully.
This is probably easy but I am getting stuck: when I build a solution in Visual Studio - how do extract the exact cmd line for the current build command in order to be able to do the same build from VisualStudio console?
In the output window I can see the single projects in the solution build commands but not the one for the whole solution.
I am on VS2005.
Any help would be appreciated
Navigate to your Programs menu > Microsoft Visual Studio 2005 > Visual Studio Tools > Visual Studio 2005 Command Prompt.
this command prompt has all the necessary .NET environment variables set for the the command line session. You can change directory to your solution directory (e.g. c:\projects\mySolution) and run
Msbuild.exe mySolution.sln
You can see the various options available using msbuild /?
Msbuild is located at C:\Windows\Microsoft.NET\Framework\v2.0.50727
On top of msbuild /? quick-option check, you may reference the MSBuild Command Line Reference page for more explanations on its usage. And how to build specific targets in solutions.
In addition to what #JohnIdol says correctly, I've found that you need to setup a number VS environment variables. I don't have the name of the batch file in front of me, but you can modify or 'I think' use it. It is in VS program files tree somewhere. Also, as I remember you don't want to be in a standard shell but a .NET setup shell for some paths and such. I'll add details later when I'm at a Windows PC with VS.
EDIT: The batch file mentioned is a shortcut in ProgFiles menu. Here is the details of its properties.
%comspec% /k ""C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat""x86"
Here is my batch file, using MSBuild to call the solution.
#echo off
:: setup VS2005 command line build environment
set VSINSTALLDIR=C:\Program Files\Microsoft Visual Studio 8
set VCINSTALLDIR=C:\Program Files\Microsoft Visual Studio 8\VC
set FrameworkDir=C:\WINDOWS\Microsoft.NET\Framework
set FrameworkVersion=v2.0.50727
set FrameworkSDKDir=C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0
set DevEnvDir=C:\Program Files\Microsoft Visual Studio 8\Common7\IDE
set PATH=C:\Program Files\Microsoft Visual Studio 8\Common7\IDE;C:\Program Files\Microsoft Visual Studio 8\VC\BIN;C:\Program Files\Microsoft Visual Studio 8\Com
mon7\Tools;C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\bin;C:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\bin;C:\Program Files\Microsoft
Visual Studio 8\SDK\v2.0\bin;C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;C:\Program Files\Microsoft Visual Studio 8\VC\VCPackages;%PATH%
set INCLUDE=C:\Program Files\Microsoft Visual Studio 8\VC\ATLMFC\INCLUDE;C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE;C:\Program Files\Microsoft Visual
Studio 8\VC\PlatformSDK\include;C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\include;%INCLUDE%
set LIB=C:\Program Files\Microsoft Visual Studio 8\VC\ATLMFC\LIB;C:\Program Files\Microsoft Visual Studio 8\VC\LIB;C:\Program Files\Microsoft Visual Studio 8\VC
\PlatformSDK\lib;C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\lib;%LIB%
set LIBPATH=C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;C:\Program Files\Microsoft Visual Studio 8\VC\ATLMFC\LIB
echo %0 %*
echo %0 %* >> %MrB-LOG%
cd
if not ""=="%~dp1" pushd %~dp1
cd
if exist %~nx1 (
echo VS2005 build of '%~nx1'.
echo VS2005 build of '%~nx1'. >> %MrB-LOG%
set MrB-BUILDLOG=%MrB-BASE%\%MrB-WORK%.%MrB-NICEDATE%.%MrB-NICETIME%.build-errors.log
msbuild.exe %~nx1 /t:Rebuild /p:Configuration=Release > %MrB-BUILDLOG%
findstr /r /c:"[1-9][0-9]* Error(s)" %MrB-BUILDLOG%
if not errorlevel 1 (
echo ERROR: sending notification email for build errors in '%~nx1'.
echo ERROR: sending notification email for build errors in '%~nx1'. >> %MrB-LOG%
call mrb-email "Mr Build isn't happy about build errors in '%~nx1'" %MrB-BUILDLOG%
) else (
findstr /r /c:"[1-9][0-9]* Warning(s)" %MrB-BUILDLOG%
if not errorlevel 1 (
echo ERROR: sending notification email for build warnings in '%~nx1'.
echo ERROR: sending notification email for build warnings in '%~nx1'. >> %MrB-LOG%
call mrb-email "Mr Build isn't happy about build warnings in '%~nx1'" %MrB-BUILDLOG%
) else (
echo Successful build of '%~nx1'.
echo Successful build of '%~nx1'. >> %MrB-LOG%
)
)
) else (
echo ERROR '%1' doesn't exist.
echo ERROR '%1' doesn't exist. >> %MrB-LOG%
)
popd
For VS .NET 2003 you can use devenv.exe to build the solution/project from command line.
devenv solutionfile.sln /build solutionconfig
E.g. usage in batch file:
call "C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\vsvars32.bat"
devenv Tools.sln /build "Release"
If you want to see the exact command line as provided by VS (rather than work it out) then you could try replacing the MSBuild.exe with your own console app that prints out all the parameters to a file.
You could also write out all the environment variables supplied to check which ones VS provides in the background.
I just want to thank the Bejoy on the example. I had big problems with solution rebuild on setup pre build event because they removed most of the macros and this helped me a lot.
Here is my solution based on Bejoy's (considering that .bat file is located in setup root folder which is part of solution):
call "%VS100COMNTOOLS%\vsvars32.bat"
devenv "%CD%\..\soulutionfile.sln" /build "Release"
You can start msbuild from the command line. msbuild understands .sln (solution) files. You can specify the .sln file and the build configuration (debug, release etc.) from the command line.
http://msdn.microsoft.com/en-us/library/ms164311.aspx
Here is the documentation on what you can do with msbuild. MSBuild.exe is installed with the .net framework, not with visual studio. You can find it in c:\windows\microsoft.net\framework\v3.5 (or v2.0.50727)
I searched a bit and found that you can also do a command line build with visual studio using devenv.exe /build, more info here:
http://msdn.microsoft.com/en-us/library/xee0c8y7(VS.80).aspx
How do you turn a Visual Studio build that you'd perform in the IDE into a script that you can run from the command line?
With VS2008 you can do this:
devenv solution.sln /build configuration
\Windows\Microsoft.NET\Framework\[YOUR .NET VERSION]\msbuild.exe
Lots of command line parameters, but the simplest is just:
msbuild.exe yoursln.sln
Simplest way: navigate to the directory containing the solution or project file, and run msbuild (assuming you have Visual Studio 2005 or newer).
More flexible ways:
Read up on the MSBuild
reference. There are tons of
customization, especially once
you've installed the MSBuild Community Tasks Project.
Use NAnt. It has existed
for longer than MSBuild and has more
community support, but requires you
to start a project file from
scratch, rather than extending the
existing, Visual Studio-created one.
Here is the script I'm using to completely automate the command line build of x86 AND x64 configurations for the same solution through batch scripts.
This is based on DevEnv.exe as it works if you have a Setup project in your build (msbuild doesn't support building Setup projects).
I'm assuming your setup is 32bit Windows 7 with Visual Studio 2010 setup using the x86 native compiler and x64 cross compiler.
If you're running 64bit windows you may need to change x86_amd64 to amd64 in the batch script depending on your setup.
This is assuming Visual Studio is installed in Program Files and your solution is located in D:\MySoln
Create a file called buildall.bat and add this to it:
D:
cd "D:\MySoln"
if "%1" == "" goto all
if %1 == x86 goto x86
if %1 == x64 goto x64
:x86
%comspec% /k ""C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86 < crosscompilex86.bat
goto eof
:x64
%comspec% /k ""C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86_amd64 < crosscompilex64.bat
goto eof
:all
%comspec% /k ""C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86 < crosscompilex86.bat
if %ERRORLEVEL% NEQ 0 goto eof
%comspec% /k ""C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86_amd64 < crosscompilex64.bat
goto eof
:eof
pause
Now create 2 more batch scripts:
crosscompilex86.bat to build the Release version of a x86 build and include this
devenv MySoln.sln /clean "Release|x86"
IF %ERRORLEVEL% NEQ 0 EXIT /B %ERRORLEVEL%
devenv MySoln.sln /rebuild "Release|x86"
IF %ERRORLEVEL% NEQ 0 EXIT /B %ERRORLEVEL%
crosscompilex64.bat to build the Release version of the x64 build and include this
devenv MySoln.sln /clean "Release|x64"
IF %ERRORLEVEL% NEQ 0 EXIT /B %ERRORLEVEL%
devenv MySoln.sln /rebuild "Release|x64"
IF %ERRORLEVEL% NEQ 0 EXIT /B %ERRORLEVEL%
Now place all 3 batch files along in your solution folder along with MySoln.sln.
You can build both x86 and x64 Release versions by creating a Shortcut on your desktop which run the following commands:
Build All -> D:\MySoln\buildall.bat
Build x86 Release Only -> D:\MySoln\buildall.bat x86
Build x64 Release Only -> D:\MySoln\buildall.bat x64
If you're using another configuration like AnyCPU etc you would need to customize the above scripts accordingly.
NAnt and MSBuild are the most popular tools to automate your build in .NET, and you can find a discussion on there of the pros/cons of each in the Stack Overflow question Best .NET build tool.
Look into build tool NAnt or MSBuild. I believe MSBuild is the build tool for Visual Studio 2005 and later. I am, however, a fan of NAnt...
Take a look at UppercuT. It has a lot of bang for your buck and it does what you are looking for and much more.
UppercuT uses NAnt to build and it is the insanely easy to use Build Framework.
Automated Builds as easy as (1) solution name, (2) source control path, (3) company name for most projects!
http://projectuppercut.org/
Some good explanations here: UppercuT
Here is my batch file using msbuild for VS 2010 Debug configuration:
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe"
iTegra.Web.sln /p:Configuration=Debug /clp:Summary /nologo
As of Visual Studio 2005, all of the project files (at least for .NET based projects) are actual MSBuild files, so you can call MSBuild on the command line and pass it the project file.
The bottom line is that you need to use a "build scripting language" like NAnt or MSBuild (there are others, but these are the mainstream ones right now) if you want to have any real control over your build process.
I had to do this for a C++ project in Visual Studio 2003 so I don't know how relevant this is to later version of visual studio:
In the directory where your executable is created there will be a BuildLog.htm file. Open that file in your browser and then for each section such as:
Creating temporary file "c:\some\path\RSP00003C.rsp" with contents
[
/D "WIN32" /D "_WINDOWS" /D "STRICT" /D "NDEBUG" ..... (lots of other switches)
.\Project.cpp
.\Another.cpp
.\AndAnother.cpp
".\And Yet Another.cpp"
]
Creating command line "cl.exe #c:\some\path\RSP00003C.rsp /nologo"
create a .rsp file with the content between the square brackets (but not including the square brackets) and call it whatever you like. I seem to remember having problems with absolute paths so you may have to make sure all the paths are relative.
Then in your build script add the command line from the BuildLog.htm file but with your .rsp filename:
cl.exe #autobuild01.rsp /nologo
(note there will also be a link.exe section as well as cl.exe)
A more simple way is to change VS 2015 Projects & Solutions configuration:
Go to the Tools tab -> Options -> Projects and Solutions -> Build and Run -> On Run, when projects are out of date (choose Always build). VOILA!
Now your IDE will automatically build your project when you run (F5) it. Hope this helps, any feedback are welcome.