If one project can't build, Visual Studio, by default, keeps right on trying to build all the other projects that depend on that project, and therefore gets stupid errors because those other projects are now building against a stale version of the binary.
How can I change this behavior, and get it to stop on failure?
For example, suppose I have a library project called MyApp.Core, and an executable project called MyApp. MyApp calls a method in MyApp.Core. Suppose I add a new parameter to that method and then try to build, but I've inadvertently introduced an unrelated compiler error in MyApp.Core. When I build, Visual Studio will:
Try to build MyApp.Core, and fail because of the compiler error. The MyApp.Core.dll on disk is left unchanged because the build failed.
Go on to try to build MyApp against that older version of MyApp.Core.dll, and report compiler errors because it's passing more parameters than the method in the old DLL expects.
Report the second batch of errors at the top of the Errors window, thus making it very difficult to find the actual problem.
Make has had this problem solved since 1977: when it realizes that it can't build, it stops building. Every other build system and IDE that I've used is also clever enough to stop on a lost cause. But Visual Studio hasn't quite caught up to the technological sophistication of 1977.
The book "Visual Studio Hacks", in its section on macros, has a workaround: you can write a macro that fires when a project is done building; if the project's build status was "failed", the macro can issue a Cancel Build command. I regularly install this hack on every computer I use that has Visual Studio. However, at home I use Visual C# Express, which doesn't support macros.
Is there any way to get Visual Studio 2010 (including the Express editions) to stop building on a build failure?
As much as I like MSBuild, there isn't a built-in way to do this when using the solution file to build (as you've already discovered). With Resharper's analysis enabled I find that compiler errors are very rare for me these days, so I rarely have the problem of overwhelming error messages.
At my previous shop, someone routinely gacked-up the build so that one of the root projects in a solution of over 60 projects and because of that, many people took to running projects individually from the command line similar to running individual Make files.
If you really wanted to handle this problem in a different way than the macro you mentioned, you could construct an external msbuild file that executes the projects individually and checks for errors in-between runs. You'll have to keep the build ordering correct, and you'll need to run it from the command line and/or add a shortcut to the Tools menu option.
Here's an example:
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Build">
<MSBuild ContinueOnError="false" Projects="log4net\log4net.csproj" Targets="Build">
<Output TaskParameter="TargetOutputs" ItemName="BuildOutput"/>
</MSBuild>
<MSBuild ContinueOnError="false" Projects="Project1\Project1.csproj" Targets="Build">
<Output TaskParameter="TargetOutputs" ItemName="BuildOutput"/>
</MSBuild>
<MSBuild ContinueOnError="false" Projects="Project3\Project3.csproj" Targets="Build">
<Output TaskParameter="TargetOutputs" ItemName="BuildOutput"/>
</MSBuild>
</Target>
<!-- <OnError ExecuteTargets="ErrorTarget" /> //-->
</Project>
Replace the projects with your projects, and the group will need to be mimicked for the Clean target.
I wish there was a better solution and I don't know why the MSBuild team won't add this feature into the product. Like you said, Make figured it out decades ago. FWIW, I don't know how well this works with complicated build dependencies and build parallelism.
My problems with MSBuild center around the ResolveAssemblyReferences, and ResolveComReferences Tasks which are the slowest part of a build in a big solution with a large/complicated project dependency tree (large being relative ~30 projects at a minimum).
I hope this helps.
There is also this free extension for Visual Studio 2010/2012/2013 that does this.
StopOnFirstBuildError (Download)
http://visualstudiogallery.msdn.microsoft.com/91aaa139-5d3c-43a7-b39f-369196a84fa5
Stop Build on first error in Visual Studio 2010 (Write-up)
http://einaregilsson.com/stop-build-on-first-error-in-visual-studio-2010/
You can also kill the process called cl.exe using the task manager. There might be multiple cl.exe processes - killing just one of them should be enough.
This will stop the build process immediately.
I always just hold down the "Pause / Break" key when I see it happening and it cancels the build.
Related
Is it possible to use an external build system for VC++ 2013?
I want Visual Studio do nothing but build by invoking my build tools.
I am thinking about something like this:
Put all build command in batches.
Invoke a project-level build batch by right clicking the project and choose build.
Invoke the a solution-level build batch by right clicking the solution and choose build.
Is there some walk-through tutorial? I searched a lot but no luck.
ADD 1 - Some progress...
After briefly reading about the MSBuild process, I tried as below.
First, I edit the *.vcxproj project file. I change the DefaultTargets from Build to MyTarget.
<Project DefaultTargets="MyTarget" ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
Then I add a new target named MyTarget:
<Target Name="MyTarget">
<Message Text="Hello, Bitch!" />
</Target>
I hope this can bypass the VS2013 built-in built process and only carry out my own batch.
It works well on command prompt:
But in Visual Studio, when I right click the project and choose build command, it gives me a lot of link errors.
How to avoid these link errors? Since my batch can take care of all the build process, I don't need Visual Studio to do the link for me.
ADD 2
It seems these link errors show up because I include the *.c files with the ClCompile tag as below.
<ItemGroup>
<ClCompile Include="z:\MyProject1\source1.c" />
<ItemGroup>
Since I don't want VS2013 to invoke the compiler, I change it to <ClInclude> tag, the link errors disappeared, but the symbol resolution is not working... Seems I shouldn't change the tag.
ADD 3
Here's another way to compile without linking.
Is it possible for Visual Studio C++ to compile objects without linking
Seems it doesn't have the symbol resolution issue. But I still cannot invoke an external batch by click build/rebuild/clean.
You might want to look into Visual Studio's makefile projects (in the Visual C++/General project templates category).
You get to specify what commands to execute for each type of build (clean, build, rebuild). The command can invoke a make, run a batch file, or invoke some other build tool. It just executes a command. The commands can contain various macros that VS provides (similar to environment variables) so the command can be parametrized for things like making a target directory based on the solution or project name or type (debug vs. release).
(Michael Burr's reply pointed out a better direction, i.e. a better VC++ project template. You can combine my answer and his.)
Finally, I solved this issue!
The trick is the so-called target overriding. The Visual Studio context menu items Build\Rebuild\Clean correspond to MSBuild targets named Build\Rebuild\Clean, respectively. We just need to override them in the *.vcxproj file.
Such as this:
DO REMEMBER that:
The last target seen by MSBuild is the one that is used — this is why
we put the at the end of the existing *.vcxproj file.
And in the override.proj, do whatever you like as below:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Build">
<Message Text="Build override!" />
<Exec Command="kickass.bat" />
</Target>
</Project>
The following 2 links are good reference:
Hack the build
Hijacking the Visual Studio Build Process
Note that:
The 1st link take a CSharp project as example, but ALSO works with VC++ project.
The 2nd link doesn't work for VC++ project but the rational is similar. If you didn't include the Microsoft.Cpp.targets, you will see the following error when loading the project:
ADD 1
As I tried, we don't need another overrride.proj file. We can just place the specific target at the end of the *.vcxprj file. Such as below:
ADD 2
With target overriding mentioned above, I can run my customized bat file with project's Build/Rebuild/Clean commands. But I noticed that when I run solution's Build/Rebuild/Clean commands, I think it is just following some kind of project dependency order to build each project respectively, which is not exactly equivalent to what I want for an overall build in my scenario.
My current workaround is to create a dummy project and use it to trigger a batch for my overall build.
In my project, I am running an external tool to update some binary files. These files are included in the project as "content".
At the moment the tool is set to run during "pre-build event" in C# project properties. Unfortunately, this event is only executed if the project is out of date, which is not what I need.
I am working around this by always using "rebuild" instead of "build" on my project, but this is tedious and slow.
I need to execute this tool always, irrespective of whether a project is or is not up to date. Actually, even before MSBuild even determines whether the project is up-to-date, because the tool modifies some of the files included in the project, therefore affecting the up-to-date check result.
Is there a proper way to do it?
Here's the solution. Define this property in your project file:
<PropertyGroup>
<DisableFastUpToDateCheck>true</DisableFastUpToDateCheck>
</PropertyGroup>
PreBuildStep will then execute every time, regardless of whether the project is or isn't up to date.
It seems that Visual Studio is bypassing normal up-to-date checks of MSBuild and using some sort of custom check that is faster, but has a side effect of breaking customized build targets.
In project level, you have three options:
1) Pre-build action
<PropertyGroup>
<PreBuildEvent>notepad.exe Foo.txt</PreBuildEvent>
</PropertyGroup>
2) normal BeforeBuild target
<Target Name="BeforeBuild">
<Exec Command="notepad.exe Foo.txt" />
</Target>
3) "attached" to "Build" target (like stijn suggested)
<Target Name="BeforeBuild2" BeforeTargets="Build">
<Exec Command="notepad.exe Foo.txt" />
</Target>
Actually this solution (in case of Build) will not work, because DependsOnTargets is executed BEFORE BeforeTargets. And exactly in DependsOnTargets the real (CoreBuild) sits :)
This is why they invented the 'BeforeBuild' target ;)
In both cases VS check if something is changes (files are up-to-date). Why do you even want to run external program if nothing was changed? If this program work on file (eg. "content") msbuild and VS should detect files as out-of-date and process building.
Unfortunately IDE (Visual Studio) has it's own method to deal with msbuild projects. The main mechanism is the same, but when it's came to determine what project build or not, or in which order... VS act totalny different.
You can use external tool and run "msbuild" against your solution or project. This will also compile "the proper way" and binaries will be not different, but you will have full capabilities and potentials of MsBuild
There is also one additional pre build event that was not discussed here. Usually code analyzers are using that to check if code analyzer was downloaded by NuGet.
So if you want to execute something before code analyzers you need to use that target.
You just need to add <Target/> node under <Project/> node in your .csproj file:
<Target Name="DownloadNugetPackages" BeforeTargets="PrepareForBuild">
<Exec Command="notepad.exe Foo.txt"/>
</Target>
PrepareForBuild event will run before pre build events.
None of these solutions worked for me using Visual Studio for Mac.
I want to run a bash script before building the project but since I'm using Xamarin, some things are getting out of whack. I tried all different types of targets and even tried the CustomCommands in the project options but still I would get issues around MSbuild just running automatically or not truly running before the build
You can run the PreBuild events in a separate project that compiles before your main project.
Create a new project and name it something like "PreBuildEvent"
Add your MSbuild targets/commands as shown above to this new PreBuildEvent.csproj file for each property group/build configuration
In the project where you originally to do the PreBuild work, add a reference to this new project.
This new project will build first, executing any PreBuild events, and once this project is built, it will kick off the build for your original project. This is because when you add a reference to a project, visual studio makes sure to build them in the correct order
The solution that works for me is to have another project (configuration Makefile) and set that project as a BuildDependancy.
This avoid modification of how the prebuild step runs, and could allow you to regenerate your binary files in isolation to the rest of your build process if required.
If I run a c++ project/solution, in Visual Studio, with a command line option "--xx", how can I do the exact same thing from TeamCity ?
I have searched and have been unable to find any option.
The one thing that looks like "Command line parameters" is actually designated for MSBuild.
I have to run the solution - and not just the executable generated by the solution.
Thank you.
Your Visual Studio build is executed using MSBuild on the server, the name may be a little confusing, but the parameters should function in the same way using that MSBuild parameter box as passing them to visual studio would be.
if there are issues getting this to work using that parameters box, we will need some more information about the commands you need to run and the behaviour you need.
Edit following questioner's comment
The problem in actuality here is that Visual Studio builds don't really exist in TeamCity, visual studio build is actually just going to run MsBuild against your visual studio solution, which, in terms of Google Test, is sufficiently different to cause your problems.
To resolve this, you are probably going to have to change your build runner to just be an MsBuild script which builds your solution and runs the Google tests. thankfully, the internet provides:
http://code.google.com/p/msbuildteamcitytasks/wiki/RunGoogleTests
The above is some MsBuild tasks which claim to integrate GoogleTest results completely with TeamCity, doing all the leg work for you in that regard. The result of this is that you only need a very brief build script calling MsBuild on your solution, followed by calling that MsBuild Task as required. I cant confirm how well they work or how easy they are to set up as I haven't used them, but the documentation on the page implies it should be reasonably easy to put together.
below is a snippet of MsBuild that will build your solution(s)
<MSBuild Projects="#(BuildProjects)" Targets="Rebuild" BuildInParallel="true" Properties="Configuration=Debug;Platform=$(Platform)">
<Output ItemName="DebugOutputs" TaskParameter="TargetOutputs"/>
</MSBuild>
where each $() variable is a system property in your TeamCity configuration #(BuildProjects) is a list of solutions generated using this:
<ItemGroup>
<BuildProjects Include="$(WorkingArea)\**\*.sln" />
</ItemGroup>
you can of course hard code any and all of these variables, or change parameters as required, but this example will give you some freedom to reuse the script on other projects (its not a full script, there's some extra structure stuff to go around the outside).
you can of course build in further functionality to the script as required, or leave it as simple as possible to make it easy to understand.
there is further documentation on MsBuild scripts are available from these locations:
http://www.universalthread.com/ViewPageArticle.aspx?ID=61
http://codingcockerel.co.uk/2008/04/15/automating-the-build-with-msbuild/
http://www.codeproject.com/Articles/12985/Practical-NET2-and-C-2-An-introduction-to-MSBuild
I'm sure there's plenty more out there if you need it.
Well, In TeamCity (I am using version 6.5.x), When you add a new Build Step, select the Build runner as Visual Studio (sln) or Visual Studio 2003 as per your requirement and there you'll get the option to pass command line parameters.
What Version of TeamCity do you use?
I am trying to build MSIs in a TFS Build by shelling out to DEVENV.exe (since MSBUILD does not support VSPROJs). In any case, my first installer project builds fine, the second one fails. If I reverse the order, same thing happends (i.e. the error does not follow the project). Looking at the output, I get the following errors:
Deserializing the project state for project '[MyProject].dbproj'
[MyProject].dbproj : error : Error HRESULT E_FAIL has been returned from a call to a COM component.
Also, I get:
Package 'Microsoft.VisualStudio.TestTools.TestCaseManagement.QualityToolsPackage, Microsoft.VisualStudio.QualityTools.TestCaseManagement, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' failed to load
It looks as though the first build tries to serialize the DB project (and it says it succeeds, but there is no DBML file anywhere). Then the second build tries to deserialize the DB project and fails.
I've tried resetting env settings (using the /resetusersettings flag) as well as using the /resetskippkgs flag. Nothing works.
Any ideas?
When you shell out to DevEnv, are you building that specific project (.vdproj file), or are you building the solution? It sounds like VS is trying to open the solution on the build machine and the database and test project systems aren't present.
Have you considered porting your setup project to WiX?
Start simple. Unless you're well versed in the problem you're trying to solve it's usually best to try it "by hand" before getting it running as part of a TFS build. RDP into the build server and try running the necessary commands at the command line and see what happens. You can even go simpler than that and RDP into the build machine and load Visual Studio and build it.
Bottom line is that if you can't get it to build within Visual Studio or at the command line by calling devenv.exe it won't work as part of the team build.
I am using the below Exec task to do precisely what you are doing as part of a TFS build. So I know this works. Your platform and configuration may vary depending on what you're building. The nice thing about this is that you'll have a log file at C:\Temp\MSIBuildOutputLog.txt that you can analyze for additional errors and information.
<Exec Command=""C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" "$(PathToSolution)\solution.sln" /Build "Release|Mixed Platforms" /out "C:\Temp\MSIBuildOutputLog.txt"" />
One important thing to note... There is a bug in VS2010 which causes MSI generation to fail when you try to run it at the command line using devenv.exe. This took me days to find and figure out, but you need this hotfix. Worked like a charm...
http://archive.msdn.microsoft.com/KB2286556
Actually it's the deployment projects that don't support msbuild. FWIW, this is all deprecated in the next release of Visual Studio so you might want to start looking at InstallShield Limited Edition and/or Windows Installer XML now before spending too much time on dead end, broken technology. Both of these alternatives have proper MSBuild support aswell as many other improvements.
It would be perhaps better and quicker to adopt WIX (Windows Installer XML) which is the technology MS now recommends to use within VS/MSBuild/TFSBuild environment to crate MSIs.
It is relatively easy to setup and integrate within your VS Solutions. It uses XML based files to describe your MSIs and uses these files to create your MSIs when you compile.
I would start by downloading Wix from http://wix.codeplex.com/
Once installed you would be able to use the VS2010 integration of Wix based projects to create MSIs. To get started quickly simply add a new Wix project to your solution and reference the projects whose output you wish to combine into an MSI. Next you can run a tool called "Heat" which is included with Wix toolkit to generate the XML files by scanning your projects.
Once you have these XML files, add them to your Wix project and compile.
I have a solution with several web application projects in it. After all the projects have been built I need to run an MSBUILD script.
What I used to do was call the script from one of the existing projects (through <Target Name="AfterBuild"> in the .csproj file). However, I had to make sure I used the project that built last, and if the build order ever changed I would get unexpected results.
So, I decided to make an empty web application project, and set the project dependencies so that it always built last, then attach the MSBUILD script to this.
So now it always runs at the right time, but I get an extra (tiny) assembly as a result of the supposedly empty project being built. There are no code files in the project (except AssemblyInfo.cs), but an assembly is always produced.
So, is there either a way to stop the assembly being built, or maybe a way to attach the MSBUILD script to the solution as a whole and avoid this dummy project altogether?
In MSBuild 4.0 there are two new hooks that can be used to run scripts before and after a solution is built. When running MSBuild on a solution file, it will look for two target files in the solution directory:
before.SolutionName.sln.targets
after.SolutionName.sln.targets
If any of those files is found, it will automatically be executed at the proper stage.
In your case, in order to run a script after all the projects in the solution have been built, you could create an after.MySolution.sln.targets file with a Target like:
<Target Name="RunPostBuildScripts" AfterTargets="Build">
<MSBuild Projects="PostBuild.targets" />
</Target>
See also:
Extending the solution build
I don't have enough reputation points to comment on the Enrico's accepted answer so I will just comment here that this doesn't work when you run the build in Visual Studio 2010 itself. It does work when MSBuild is run as a command-line.