When I compile my project using msbuild command with useenv option to include directory I cannot compile my project. It doesn't include the directory in INCLUDE environment variable. My script is as follows,
cd /d C:\Program Files\Microsoft Visual Studio 10.0\VC\bin
call vcvars32.bat
SET INCLUDE="C:\Program Files\CA\SCM\HSDK\include";%include%
SET LIB="C:\Program Files\CA\SCM\HSDK\lib";%lib%
cd /d D:\vivilk\H12_Upgrade
echo "Building H12Int"
cd Source\H12Int
msbuild H12Int.sln /p:UseEnv=true;Configuration=Release /t:Clean,Build
This give the error,
fatal error C1083: Cannot open include file: 'hsdk.h': No such file or directory
hsdk.h is a file in C:\Program Files\CA\SCM\HSDK\include. So that means it has not identified the include path.
But If I compile this project using Visual Studio 2010 IDE by setting this include and lib directory in Property pages it works. Whats wrong with my build script?
At last I could solve the issue by removing quotation marks around include directory (C:\Program Files\CA\SCM\HSDK\include).
Related
I am trying to build Lua (version 5.3.5) with Visual Studio 2019. For this, I am following the instructions given here. The steps that I have followed are as follows:
Set up environment variables as mentioned below
UTIL_DIR = C:\Program Files\utility
LUA_DIR = C:\Program Files\lua\5.3
LUA_CPATH = ?.dll;%LUA_DIR%\?.dll
LUA_PATH = ?.lua;%LUA_DIR%\?.lua
SDK_DIR = Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133
INCLUDE = %SDK_DIR%\include;%SDK_DIR%\include\usr
LIB = %SDK_DIR%\lib;%SDK_DIR%\lib\usr
Created the folders required, as mentioned in the environment variables
C:\Program Files\utility
C:\Program Files\lua\5.3
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\usr
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\lib\usr
Added C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin to the environment path variables
Downloaded lua-5.3.5 from here, untarred it and stored in C:\dev\
Added the build.bat file given in this image in C:\dev\lua-5.3.5\src\folder with the 5.1s replaced by 5.3s
In the command prompt, executed the command C:\dev\lua-5.3.5\src>build
I am getting error for every line of build.bat. The entire error screen is shown here.
Please tell me what is going wrong and how to resolve that.
**P.S. - ** I think my SDK_DIR variable is not pointing to the correct folder.
However, I don't know what the correct folder should be. There are
many bin, include and lib directories in Microsoft Visual Studio\2019\Community\.
I am seeing some weird behavior with the latest 15.8.2 Visual Studio 2017 Build Tools. After installing the tools and ensuring that it has installed all workloads and components, I attempted to build our master solution from a batch file with the following command:
msbuild %~dp0\..\..\Master.sln /verbosity:quiet /ds /p:Configuration=Debug;Platform=x64 /m /fl1 /fl2 /fl3 /flp1:LogFile="%~dp0\MSBuild.log";Verbosity=normal /flp2:LogFile="%~dp0\ProjectWarnings.log";WarningsOnly /flp3:LogFile="%~dp0\ProjectErrors.log";ErrorsOnly
One of the very first projects fails with the following error:
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\TextTemplating\Microsoft.TextTemplating.targets(340,5): error : System.IO.FileNotFoundException: Could not find a part of the path 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\140\Microsoft.SqlServer.TransactSql.ScriptDom.dll'.
If you'll notice, the path that can't be found is looking for the "Enterprise" directory, which obviously doesn't exist because we installed the Build Tools. The .dll in question is there in the correct directory, just under the "BuildTools" folder and not "Enterprise". In the project itself, we have this line for the above .dll:
<HintPath>$(VSInstallDir)\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\140\Microsoft.SqlServer.TransactSql.ScriptDom.dll</HintPath>
When looking at a developer command prompt on the system with just the Build Tools installed, running set, the variable VSInstallDir maps correctly to the BuildTools folder:
VSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\
My question is this: where in the world is MSBuild getting the "Enterprise" directory from? We are not referencing it in ANY project, instead using $(VSInstallDir) when necessary. I have grepped the entire BuildTools directory for references to "Enterprise" and I'm finding nothing in .targets files or .props (or really any other files) that would indicate the variable would resolve to "Enterprise" rather than "BuildTools".
I run MSys/Bash as distributed in Git for Windows. I added the folder C:\Windows\Microsoft.NET\Framework\v4.0.30319 to my path, so I could run msbuild but it doesn't work
$ msbuild
C:\Program Files (x86)\Git\bin\sh.exe: msbuild: command not found
Yet msbuild.exe does:
$ msbuild.exe
Microsoft (R) Build Engine version 4.0.30319.17929
Yet the command explorer resolves fine. What's going on?
It's a bug in MSys where the same name is shared by a folder and a file (minus the extension). In this case:
File C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
Folder C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild
You'll have to workaround by writing msbuild.exe
If the exe file outputs not found, do copy C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe ProjectPath
And then run msbuild.exe
If msbuild.exe cannot be found, it needs to be configured.
Open a command prompt and run the file vsvars32.bat located in your Visual Studio Common7/Tools folder..
i.e C:\Program Files x86\Microsoft Visual Studio 12.0\Common7\Tools\vsvars32.bat
This will correctly setup all the neccessary variables for msbuild.exe to be found.
Include directories aren't configurable via Tools/Options anymore. I see no way to do that via Solution Properties also. I have set INCLUDE environment variable, restarted VS but cl.exe (rc.exe really) still misses a header file.
fatal error RC1015: cannot open include file 'winres.h'.
C:> echo %INCLUDE%
C:\Program Files\Microsoft Platform SDK\Include\mfc
C:> ls "C:\Program Files\Microsoft Platform SDK\Include\mfc\WINRES.H"
WINRES.H <-- it exists
I'm using EditBin to increase the stack size of an application I'm writing. I have this in the post-build event command line for Visual Studio:
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\editbin.exe" /STACK:268435456 "$(TargetPath)"
When I build my project, I get this error:
Error 470 The command ""C:\Program
Files (x86)\Microsoft Visual Studio
10.0\VC\bin\editbin.exe" /STACK:268435456 "[Target Executable]"" exited
with code -1073741515.
I have both of the following in my PATH environment variable:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin
The command also works when I run it manually with cmd.exe. Does anyone know what the problem is here?
I had the same issue, how I resolved it:
Ran msbuild.exe <my.sln> /t:<mytargetproject> from a VS2010 command prompt, where <my.sln> is your solution name and <mytargetproject> is the project you are trying to build. For e.g. msbuild.exe helloworld.sln /t:mainproj.
When you do this or at least when I ran this, a dialog box popped up and said "foo.dll" cannot be found, I added the path of that dll to my "PATH" environment variable and the problem was solved! See ChrisF's comment to the question, as it says, the error is that some dll/component is missing.
From the dll name it complained about, I believe this is not contained to VS2010 libs/dlls, for me it was a third-party dll (which I am using and supposed to be available during the build) it was complaining about.
The best solution is to run the vcvarsall.bat located in the root of the visual studio install folder(C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC). That sets up the search folders for all MSVC compiler related tools.
I got this to work for now by copying mspdb100.dll into the same directory as editbin.exe, but this is not an optimal solution because every developer on my team will need to do the same thing.