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
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 use the msbuild to build visual studio project using command line.
I used this commands
SET VCTargetsPath=C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120
msbuild.exe ../../../embedded/ports/visualC12/config-from-host.vcxproj
/p:Configuration=Release /p:Platform=Win32 /t:rebuild
Using IDE : it took around 2 min
Using cmdline: it took around 20 min
In command line it looks like it build a lot of projects that are not built in the IDE
Any suggestions?
In command line it looks like it build a lot of projects that are not built in the IDE Any suggestions?
That because you are using the property /t:rebuild in your command.
This switch performs the same function as the Rebuild Solution menu command within the integrated development environment (IDE)-will clean and then build the solution from scratch, ignoring anything it's done before. So MSBuild will build all projects regardless of whether them were built before or not.
When you build projects in IDE with build option ranther than Rebuild, it will perform an incremental build: if it doesn't think it needs to rebuild a project, it won't. It may also use partially-built bits of the project if they haven't changed. That is the reason for a lot of projects build in command line but are not built in the IDE.
To make the build faster, you can change the property to /t:build in command line or select rebuild option when you build in IDE.
Besides, there are many factors that affect the speed of building, for example, parallel. When we build multiple projects in IDE, the default value of parallel is 8, Tools->options->Projects and Solutions->Build and Run:
MSBuild command line is also support parallel, /maxcpucount Switch
msbuild.exe myproj.proj /maxcpucount:3
So when you compare the build speed between the command line and the IDE, you have to make sure that all the relevant settings are the same for command line and IDE.
Hope this helps.
I have a solution that contains a project with AutoGenerateBindingRedirects set to "true". When I build it via Visual Studio 2013, the .config file in the output directory contains an generated assembly binding redirect for EntityFramework, and the project runs. However, on the build server, which calls MSBuild, this property is not followed, which causes the project to fail to start. Does anyone have any idea on why there might be differences in the build results between the two methods?
For reference, the build server is executing a command like
MSBuild MySolution.sln /p:Configuration=Release,DefineConstants="SOMETHING" /t:Rebuild /tv:4.0
I get the same results when invoking this on my development machine, too, so it seems to be a peculiarity with MSBuild and/or Visual Studio. I've tried variations like
MSBuild MySolution.sln /p:Configuration=Release,DefineConstants="SOMETHING",AutoGenerateBindingRedirects=true /t:Rebuild /tv:4.0
to no avail.
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 have to use a Pre-Build event in Visual Studio in order to either copy a file from template version to compilable version, or to call a tool to translate the file - depending if I am in Debug or in Release mode.
As found here before, I used the debug switch
if $(ConfigurationName) == Debug goto :debug
$(SolutionDir)\Tools\MyTool\Translate -i $(ProjectDir)\Themes\Generic.Template.xaml -o $(ProjectDir)\Themes\Generic.xaml
goto :end
:debug
copy /y $(ProjectDir)\Themes\Generic.Template.xaml $(ProjectDir)\Themes\Generic.xaml
:end
Everything works fine, as long as I use my local Visual Studio. But when building with TeamCity, the Studio macro variables are not set correctly. Visual Studio itself is not installed on the build server. As build script we use f#make, which calls msbuild with the solution file. Calling the build batch locally also runs perfectly, so it seems that TeamCity hides these vars somehow.
Are there any known issues about that?
I do know that there are distinct differences between msbuild and devenv.exe when building against a .sln file. For example, msbuild driven builds will not build Visual Studio deployment projects. I can't say for sure what the effects are within prebuild steps.
I recommend changing your TeamCity build step to use devenv.exe instead of msbuild (probably will need a command line build step) and just see if it works better.
TeamCity provides some built build parameters that can help you find the correct path to devenv.exe on your agent(s). They are env.VS100COMNTOOLS and VS2010_Path.