When Visual Studio runs a build, it runs MSBuild to do the majority of the work. If you pass the .sln file to MSBuild, with appropriate Configuration and Platform properties, it will build your solution similarly to how Visual Studio would.
msbuild mysolution.sln /p:Configuration=Release /p:Platform="Any CPU"
However, there are differences: sometimes a build will error through MSBuild and not through Visual Studio, or vice-versa.
What parameters does Visual Studio pass into MSBuild to influence the process? Is there some way to see the parameters it's passing as a build is is executed?
Visual Studio does not execute MSBuild.exe, but hosts the build engine itself (by means of the Microsoft.Build.* assemblies) - at least that is the case for the default C# project system. Other languages, addins, packages, etc. might do it differently.
Actually, there was a post series on the Microsoft blogs about this, I'm trying to find them and update this answer.
UPDATE: Found it again. Look for the "MSBuild in Visual Studio" posts here.
Concerning your original question, this page might help you further. Also you could go to "Tools", "Options", "Projects and Solutions", "Build and Run" and increase the MSBuild output verbosity. With "Diagnostic" you should basically see every property that is set upon starting the build.
First off, you can run msbuild with the /v:diag argument to get diagnostic-level logging. This can really help in figuring out why a build is failing.
Otherwise, yes, if you use Process Monitor, you can monitor for process start events where you can see the specific command-line sent to the process.
Specifically:
Run Process Monitor
Filter » Filter...
Operation is Process Create » Add
Operation is Process Start » Add
OK
Run your build through VS and through command-line msbuild
See the command-line arguments in the Detail column
Related
I have a solution called MainWindow.vs2015.sln for my Application. This has nearly 100 Projects and it builds perfectly in Visual Studio 2015. When I build the solution from the command line using devenv, it also works perfectly and there are no errors.
However, when I build from the command line, and then open Visual Studio 2015 and build it again, expecting an almost instantaneous build as I had already built from the command line, it builds the whole thing all over again and I am sat there for up to nearly 30 mins waiting for something to build all over again.
Is there some kind of difference between the devenv command and Visual Studio builds?
P.S I have also MSBuild as well as devenv and have had the same problem.
devenv MainWindow.vs2015.sln /Build "Debug ALL"
What's your project type? VB.net, C# or C++?
For .net projects:
If we create a new VS2015 C# project in command-line, build it in Debug+x64 combination. After that when open the project in IDE and build it, it will display Up-To-Date, and won't compile and build again since nothing changes.
So if you meet the build twice issue in C# projects, set the Build Output verbosity to Detailed or higher in VS to see detailed info about the build process.
After that, when you again meet this issue, trying reading the very first of the log to see the reason why VS builds it again! Check if you have some files missing or set as Copy Always like this.
For C++ projects:
If you're in a solution with many C++ projects in it. I'm afraid the answer could be negative. I test it in VS2015 C++ projects and I can reproduce same issue. I found if we create a C++ project, build it in command-line and then VS. VS will consider it not to be up-to-date and try to build it again...
Something interesting is if we build it not by command-line, instead we build it twice in VS, VS can recognize it's update-to-date and won't waste time to build it the second time.
So I suggest you could avoid building it in command-line before building in VS. Cause there's no advantage that we build the project using two ways while we don't do actual modify to the source files. Also, since there's something that can be improved about the Up-To-Date check in VS for C++ projects, you can post a feature request in DC and you can get help from the Product Team there.
In addition: Please make sure the Configuration+Platform you use to build solution in command-line are the same when you build in VS IDE.
Hope it makes some help :)
I'm contributing to a fairly large project that uses MSBuild properties to control the build process. I am running some tests from the command line like this:
msbuild /p:Configuration=Release /p:OSGroup=Windows_NT /p:Performance=true
And everything is working fine. However, when I try to run the tests from Visual Studio, the OSGroup and Performance properties are not set, which causes things to not work correctly.
Any idea how I can set these properties before building my .csproj file within Visual Studio? It has to be without editing the .csproj file, since I don't to accidentally check in any changes I make there. Thanks in advance.
You could just add an external tool command which builds using the same command as shown. VS will parse the output just like from it's own builds, so warnings and errors are shown in the Error List etc. Your command would be something like
msbuild $(SolutionDir)$(SolutionFileName) /p:Configuration=Release /p:OSGroup=Windows_NT /p:Performance=true
You can implement a Visual Studio extension and access project properties trough DTE.Solution.Projects and Project.Properties. There is an example here:
https://msdn.microsoft.com/en-us/library/bb166172.aspx
VS DTE interface can also be used in a standalone application or Powershell script.
Is there an instrument that can find me a place in my project which takes so long to build? Like performance profiler, but for the build process of Visual Studio.
P.S. I tried profiling my Visual Studio during build with another instance of VS, but I didn't get obvious results.
Tools -> Options -> Projects and Solutions -> Build and Run
There you can change the
MSBUild project build output verbosity
settings
When on normal level it will give timings for each project, so this could be used to see what is causing the slow down. (in the Output window)
On a higher level you will see even more detail of what is going on during a compile.
I got better results with http://msbuildprofiler.codeplex.com/ then compile my solution in a msbuild prompt
MSBuild.exe MySolution.sln /t:rebuild /l:MSBuildProfileLogger,MSBuildProfiler,Version=1.0.1.0,Culture=neutral,PublicKeyToken=09544254e89d148c
Just be careful to run rebuild target (/t:rebuild) otherwise you get completely different results second time you run it.
I think $1 donation is good price :)
I want to execute a postbuild command after every build, no matter what project in my solution has changed.
To accomplish this in Visual Studio 2010, I made one empty project depend on every other project, so it always got built, executing its postbuild command. However, Visual Studio 2012 (RC) appears to recognize that the dependency is not real, and will not build this empty project automatically.
I do not see any way to specify a solution postbuild script in solution settings. How can I accomplish this?
I have solved this issue by making my post-build script also delete the output (bin**) of this "empty" project, forcing a rebuild of this project every time. It appears to work satisfactorily so far.
This works (for details see original post):
you may need to change security settings (at your own risk) e.g.: https://stackoverflow.com/a/60284384/2705777
I'm a solo developer running Visual Studio 2008 and looking into MSBuild to improve my build process.
Almost all of the tutorials I've found so far have plenty of information about writing a build file. However I'm having a lot of trouble finding out how to integrate MSBuild into Visual Studio. Maybe MSBuild is only used with something like CruiseControl but that's overkill for me as a single developer.
Where should the build file live in a Visual Studio project and how can I run it from within the IDE?
Visual Studio executes MSBuild automatically for projects it supports.
If you right click on a project and unload it, you can then edit it in Visual Studio. Reload (right click on project again), force a (re)build to test your changes. An alternative is to edit the project file in an external editor and Visual Studio will detect saves and offer to reload the project for you.
Sounds like you're on the right track, and if you are considering writing Targets or custom MSBuild Tasks, take the time to separate them from your current project so that you can re-use them. Don't re-invent the wheel though, the two main complementary MSBuild projects are MSBuild Community Tasks and MSBuild Extension Pack.
Update: Judging from your comment on Mitch's answer, you might also want to consider adding a new Configuration element or custom properties to a project. A new MSBuild Configuration (something other than the default Debug/Release) could run unit tests, build documentation, or whatever you want automated. A custom MSBuild property would allow you to use normal Debug/Release Configuration and extend it to automate more of your build process, just depends on what you want. Either approach could also be driven from the command line.
As others have noted, MSBuild is already available when you install Visual Studio.
If you want to integrate into VS2008: Running MSBuild from Visual Studio
MSBuild is the build engine used by Visual Studio to process the files included in a project.The Visual Studio project files themselves (**.csproj* for C#, and .vbproj for VB, for example) are in fact MSBuild scripts that are run every time you build a project.
Your .csproj file is a MSBuild file. So you are actually using it already.
You may of course wish to create a separate build file to have more control, especially within a continuous integration or nightly build say.
If you simply wish to edit your project build file then you can use the IDE to edit some settings such as pre and post build actions or edit the Xml itself by unloading project and right click and editing.
You can use your current .vcproj files to build your project with MSBuild. However, as MSBuild is not directly supported (at least for vc++) vcbuild is used instead (internally).
In VS2010 all project files are MSBuild based...
This is an older article about some simple extension points from the msbuild team
How To: Insert Custom Process at Specific Points During Build
Also, don't forget you can use the MSBuild SideKick for developing and debugging your (local) msbuilds, available for free at http://www.attrice.info/msbuild/
I'd suggest you call msbuild as a post build step. Then you can put your build script somewhere in your solution and call it.
<windowsdir>\Microsoft.NET\Framework\v3.5\MSBuild.exe c:\temp\MyProject\mybuildfile.proj
The easiest way is probably to invoke your custom build script using a post-build step. Right click project, choose "Build Events" and call msbuild with your custom msbuild file from there.
I use the msbuild template to intergrate with visual studio
http://msbuildtemplate.codeplex.com/