For C++ projects I can do this:
SET CL=/DMYDIRECTIVE
devenv.exe MySolution.sln /rebuild
What is the C# version (visual studio 2008) of this trick?
Go to the Build tab in Project Properties
On the command line, csc /define:MYDIRECTIVE
The following command lists you the options of the C# compiler
csc.exe /?
The respective option is
/define:<symbol list> Define conditional compilation symbol(s) (Short form: /d)
However, for command-line building a C# project you might prefer MSBuild. With MSBuild, it is probably easiest to create a configuration using Visual Studio's Configuration Manager that already defines appropriate conditional compilation symbols. You can then select one of the configurations from the MSBuild command line:
MSBuild MySolution.sln /t:Rebuild /p:Configuration=ReleaseWithMyDirective
Related
I have the following solution:
MySolution\
MySolution.sln
MyCSProject\
MyCSProject.csproj
MyCPPProject\
VC11\
projfile.vcxproj
VC8
projfile.vcproj
MyInstallationProject
MyInstallationPackage.vdproj
In Visual Studio I have MyCSProject set as main project. But for automated build I need to build MyInstallationProject with dependencies. MyInstallationProject depends on MyCSProject and MyCSProject depends on MyCPPProject. If I build from Visual Studio, it works.
But for MSBuild I can't compose correct command. Neither of the following worked:
"...\MSBuild.exe" MySolution.sln /t:MySolution\MyInstallationProject /p:Configuration="Release" /p:Platform="x64"
"...\MSBuild.exe" MySolution.sln /t:MySolution\MyInstallationProject.vdproj /p:Configuration="Release" /p:Platform="x64"
"...\MSBuild.exe" MySolution.sln /t:MyInstallationProject /p:Configuration="Release" /p:Platform="x64"
"...\MSBuild.exe" MyInstallationProject\MyInstallationProject.vdproj /p:Configuration="Release" /p:Platform="x64"
and so on, with various errors, mainly "The target *** does not exist in the project"
How to know correct command and or the name of target, associated with the project?
In fact, one of the third and the fourth msbuild command line should have worked in your side. Also, there is a document about it.
The truth is that MSBuild cannot build the vdproj file. It is from VS installer project extension and the build tool is a separate tool from the extension rather than in the MSBuild. You can easily open the vdproj file and could find that it is not a xml style.
MSBuild can only build the xml sytle proj file.
To test it, you could try the same msbuild command line for MyCSProject project to get the difference.
So the right way is to use VS IDE build or use devenv build command line which means you have to you have VS IDE on your local.
Try the following command line:
1) open Developer Command Prompt for VS:
2) run:
cd xxx\xxx\MySolution
devenv MyInstallationProject\MyInstallationProject.vdproj /build
I'm trying to build V8 as part of ArangoDB using the official build scripts and following the official Windows build instructions.
The compilation fails for all v8* targets (v8-build.bat):
msbuild All.sln /t:v8 /p:Configuration=Release /p:Platform=x64
msbuild All.sln /t:v8_libbase /p:Configuration=Release /p:Platform=x64
msbuild All.sln /t:v8_libplatform /p:Configuration=Release /p:Platform=x64
error MSB4057: The target "v8" does not exist in the project.
If I open the solution file in Visual Studio, it looks like this:
I can build v8, v8_libbase and v8_libplatform just fine in VS.
Windows 7 64bit
Visual Studio 2013 Ultimate
Cygwin 2.2.0
cmake 3.3.1
You can run
set MSBuildEmitSolution=1
msbuild All.sln /t:v8
Then search in the generated All.sln.metaproj file the exact target names (<Target Name="">) of all projects you want to build. v8 can have a name like _tools_\_gyp_\v8. After that you can build projects
msbuild All.sln /t:"_tools_\_gyp_\v8" /p:Configuration=Release /p:Platform=x64
The correct way to specify a target/project if it's in a solution folder is:
msbuild all.sln /t:PATH\TO\PROJECT
But in case of (tools) and (gyp) it's simply not possible, because msbuild can't handle parentheses in the target parameter /t.
So either remove ( ) and specify the path like tools\gyp\v8, or get rid of the solution folders entirely. If the solution is flat, /t:v8 will work.
Unfortunately, both the wrapping of folder names with brackets as well as the generation of non-flat .sln are hardcoded in gyp, which generated my all.sln. There is no switch to control whether solution folders are created or not. It will create them if the target version of Visual Studio is known to support this kind of nesting.
Workaround: Force flat solution generation in gyp, see
https://github.com/arangodb/arangodb/commit/796d2d263db6271142d954c8c99b9dec0fbe75e9
Reported errors to Microsoft/msbuild and Google/gyp:
https://github.com/Microsoft/msbuild/issues/157
https://code.google.com/p/gyp/issues/detail?id=494
#dothebart and this post helped me a lot to figure it out, thank you!
In VS2013 use
msbuild All.sln /p:Project=v8;Configuration=Release;Platform=x64
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
Found online the way to use MSBuild to build a Visual Studio 2008 project within a solution, using the following syntax:
msbuild Solution.sln /t:"ProjectName:Rebuild"
However my project name contains a space, so I've tried:
msbuild Solution.sln /t:"Project Two:Rebuild"
msbuild Solution.sln /t:"Project Two":Rebuild
msbuild Solution.sln /t:""Project Two":Rebuild"
msbuild Solution.sln /t:"Project Two" /t:Rebuild
It definitely has to do with quotes. Either it takes the Rebuild as part of the project name and fails, complains about syntax, or if Rebuild is separated out it rebuilds the entire solution as a separate target. If I just remove the Rebuild target from the command it works fine.
msbuild Solution.sln /t:"Project Two"
But that means I cannot select Build or Rebuild in my script, I have to live with the default.
Is there a way?
Thanks
Under vs10 msbuild.exe how can a specific project within a solution.sln be Ignored?
I am building a large project that is moving to Visual Studio 10.0. In the IDE I can uncheck a project within the configuration manager and it will not build it. I need to mimic that behavior with a command line call to msbuild.exe.
The project I want to bypass is an *.dll plugin with a link error. I am stuck on stupid with the link error at the moment and since it stands alone, I can run the main program with out it and just live with a warning at run time that it isn't present.
I need some switch magic concerning calls to msbuild.exe.
If you have a certain configuration in the sln (configured in VS Configuration Manager) that you want to build with MSBuild, you can do so with the following command line:
msbuild /p:Configuration=MyConfiguration MySolution.sln