I wish to build my solution using an alternative toolset (cl.exe, link.exe and so on...) by changing the PATH environment variable.
When I build the solution using "devenv MySolution.sln" it uses the alternative toolset correctly (calling the alternative cl.exe instead of Visual C++ cl.exe). When I build it using MSBuild, it uses the Visual C++ compiler anyway, ignoring my setting of PATH.
Is there any solution to this problem? Does anybody know how can I make MSBuild invoke the compiler by resolving %PATH% (without modifying all my project and solution files, of course).
According to the VCBuild Task Reference you should be able to set the ToolPath parameter to the desired path of your alternative toolset.
Admittedly this isn't as comfortable as setting the PATH environment variable and I didn't try it since I don't have VC++ at hand right now.*
Related
I'm trying to take a couple of projects normally compiled on Windows with Microsoft C++ and compile them with clang instead.
On the upside, there exists clang-cl.exe which is designed to be a drop-in replacement for cl.exe. However, even when I copy clang-cl.exe into the current directory as cl.exe, msbuild still in some cases calls Microsoft's cl.exe.
Is there a way to tell msbuild 'here, when executing Task CL, use this cl.exe instead of the usual one'? msbuild's command line options don't contain anything obvious in that direction.
Also, is there a way to tell it to supply or override command line parameters for cl without changing the project file?
This is easy to do from either command line or project file. The properties you need to configure are $(CLToolExe) and $(CLToolPath).
From the command line:
msbuild MyProj.vcxproj /p:CLToolExe=clang-cl.exe /p:CLToolPath=c:\whatever\path\to\the\tool
Alternatively, inside your .vcxproj file:
<PropertyGroup>
<CLToolExe>clang-cl.exe</CLToolExe>
<CLToolPath>c:\whatever\path\to\the\tool</CLToolPath>
</PropertyGroup>
If you are calling task CL directly inside your .vcxproj file, as opposed to just relying on common targets, just set corresponding parameters ToolExe and ToolPath of the CL task.
Since Visual Studio 2019 16.2, Microsoft provide an integration of MSbuild and ClangCl. So this can be achieved by:
Installing the “C++ Clang Tools for Windows” component
Choosing the "LLVM (clang-cl)” toolset in the IDE
Microsoft's blog post has more information on this: https://devblogs.microsoft.com/cppblog/clang-llvm-support-for-msbuild-projects/
I were using #seva solution for sometime, though in Visual studio version Version 16.10.1 it works for me only if the 'CL' prefix is omitted from the command line parameters. i.e.:
msbuild MyProj.vcxproj /p:ToolExe=clang-cl.exe /p:ToolPath=c:\whatever\path\to\the\tool
I have a weird problem when I want to compile a Visual Studio 2012 solution via msbuild on the command line. Whatever I do, it exits with Specified platform toolset (v110) is not installed or invalid. I have tried launching it via the regular command prompt, the Windows 7 SDK prompt, and all three command prompts included in VS2012. However, compiling in Visual Studio itself works.
where msbuild outputs:
c:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe
c:\Windows\Microsoft.NET\Framework64\v3.5\MSBuild.exe
You have probably solved the problem yourself but perhaps it may help others with a similar problem. Try to set the VisualStudioVersion environment variable before running MSBuild, e.g
SET VisualStudioVersion=11.0
There is a possibility that it helps.
You could also try passing the command line parameter /p:VisualStudioVersion=11.0 to MSBuild, when trying to build your project. It seems to have the same effect as setting the environment variable, in the above answer.
In VS 2008 and VS 2010, one can easily create a solution and modify the "Solution Configuration". We can choose what configuration each project gets built in when we trigger a build at the solution level.
Is such a facility available in the Visual Studio 6.0?
In my experience:
when a configuration is chosen (form the list available) in VS6 for a VC++ project, the dependencies (which themselves have multiple configurations defined) get built in some random order. There is no way to control the configurations of dependencies at build time.
"Batch Build" does come close to this but is not as flexible for my purpose.
I have tried various options in the VS6.
Hope I am clear.
Here is a link on the MSDEV command line.
https://msdn.microsoft.com/en-us/library/aa699274(v=vs.60).aspx
There is a way to control the building of dependencies. Specify /NORECURSE and dependencies will not be built.
I use /REBUILD with /NORECURSE to keep the dependencies from getting built.
And I build each project one at a time inside the workspace in a bat file by doing a chdir to the subdirectory and calling MSDEV just for that subproject:
msdev myproject.dsp /MAKE "myproject - Win32 Debug" /REBUILD /NORECURSE > Build.log
Then I cd to the next project directory one at a time.
On a side note, I had difficulties for several years where NMAKE would not work for my specific tasks. Turns out that the PATH environment variable inside MSDEV (Visual Studio 6.0) is different from the PATH environment variable of a command shell you would run NMAKE on.
The Path used by the MSDEV shell is the %PATH% at the time Visual Studio 6 was installed. We use this and poke the registry as needed for MSDEV to get the correct path setup when switching revisions of our software; however this doesn't help update the %PATH%. The MSDEV path can be queried with a query script. I don't have my example handy.
That is why builds in MSDEV sometimes work when builds using the command line don't, as the path to DLLs differ, and any custom build steps that run .exe will not work outside of the MSDEV environment unless the path is updated.
I have a script somewhere that reads the queries the registry to extract the MSDEV path and update PATH of a shell so that batch scripts doing nmake will work as they would inside the MSDEV shell environment. The problem with the REGISTRY QUERY is that the return arguments differ with different flavors of Windows (XP/SERVER2003/...).
One thing I just discovered is that Incredibuild works with the old VS6.0 MSDEV IDE. This is a game changer. It distributes builds. I'm evaluating it now, but it might be useful to anyone waiting for long VS6.0 builds.
I am trying to specify an additional folder to look for references when doing a command-line compile with MSBuild.
cmd> msbuild LurReports.sln /t:Rebuild /p:AdditionalLibPaths=C:\Radio;TargetFrameworkVersion=v2.0
For whatever reasons, msbuild completely ignores the C:\Radio folder when looking for references. What am I missing here?
This box does not have Visual Studio installed
The .sln is VS2008 and I am compiling it against.NET 2.0.
I also tried double quotes around the path.
I followed this tutorial to make NUnit tests debugable in Visual Studio. In the debugging options I set "Start external program:" to C:\Program Files\NUnit 2.4.8\bin\nunit-x86.exe.
Is there a way to get the program files directory dynamically to avoid problems when other people work with this solution on their system?
The environment variable $PROGRAMFILES holds this. Most properties in visual studio allow you to use environment variable expansion like this: "$(PROGRAMFILES)\NUnit 2.4.8\"
%ProgamFiles% if using in a Windows path.