I'm compiling a solution with many projects inside using VS2013's MSBuild. I want the build to stop if one of the projects fails to compile and that the error code of msbuild will be non-zero to indicate something has failed. Can it be done?
I am running this command to start compiling:
%MS_BUILD_PATH% "%workarea%\WindowsSolution.sln" /p:Configuration=Release /p:ContinueOnError=false /p:StopOnFirstFailure=true
but it doesn't work as I want it. Any suggestions?
If anyone is still looking for this feature in Visual Studio, there is a free extension called [VSColorOutput] (here), which has an option to stop the build on first build error. Once you have installed the extension, the options is located at: Tools.Options.VSColorOutput.Build Actions.Stop Build On First Error
The official documentation says StopOnFirstFailure: If true, when one of the projects fails to build, no more projects will be built. Currently this is not supported when building in parallel (with multiple processors).
Can you try setting BuildInParallel=false and see if that helps?
Edit: Found an old blog post that says this might be easy to do if you're building a single .sln with multiple projects http://blogs.msdn.com/b/manishagarwal/archive/2006/05/09/593392.aspx
I'm using StopOnFirstBuildError
https://marketplace.visualstudio.com/items?itemName=EinarEgilsson.StopOnFirstBuildError
It stops the build when the any project building fails. I'm using on 2015. The linked page says it works with Visual Studio 2012, 2013, 2015, 2017.
Related
We recently updated our build servers to using Visual Studio 16.8.1 and Xamarin.iOS 14.4.1.3 and have hit an issue with the previous MSBuild command that used to run.
For the record we are build a Xamarin Forms solution and targeting iOS here.
The command is:
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\msbuild" MySolution.sln /p:Configuration="AppStore" /p:Platform="iPhone" /p:ServerAddress="" /p:ServerUser=""
I have tried searching for the specific error message that it is reporting (below) however I haven't been able to find anything useful so far.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Xamarin\iOS\Xamarin.Shared.targets(230,3): error MSB4044: The "GetMinimumOSVersion" task was not given a value for the required parameter "SdkVersion".
Update
Upon further digging I believe I have traced the source of the error back to these lines not being set in Xamarin.Shared.props.
<!-- SdkVersion -->
<_SdkVersion Condition="'$(_PlatformName)' == 'macOS'">$(MacOSXSdkVersion)</_SdkVersion>
<_SdkVersion Condition="'$(_PlatformName)' != 'macOS'">$(MtouchSdkVersion)</_SdkVersion>
I haven't been able to find out what sets MtouchSdkVersion and therefore why it isn't being set. A comment from just above the quoted section above states:
Sometimes we've used different variable names for the same thing for Xamarin.iOS and Xamarin.Mac projects. Here we try to unify those variables
Could it be that this unification has changed the behaviour of something that used to work?
This has reared it's head again in Visual Studio 2019 version 16.8.3. Looks like they've moved the problem to:
<VS Install path>\MSBuild\Xamarin\iOS\Xamarin.Messaging.targets I was able to get my builds running again by removing the _SayGoodbye dependency on line 52 for the _DisconnectAfterClean target.
<Target Name="_DisconnectAfterClean" Condition="'$(IsRebuild)' != 'true'" DependsOnTargets="" />
This is certainly not a permanent solution to the problem but a workaround has been supplied by the Xamarin team. For reference the response is on GitHub
we're investigating it, but it looks like the build process is getting disconnected after running the clean targets, so if you run Build instead of Rebuild you shouldn't face this.
In the meantime, a potential workaround to unblock Rebuilds would be to edit <VS Install path>\MSBuild\Xamarin\iOS\Xamarin.iOS.Windows.After.targets and remove the _SayGoodbye entry from the CleanDependsOn property group.
I can confirm that this has allowed our CI builds to operate again.
It should go without saying but I want to make it clear you should backup a copy of the Xamarin.iOS.Windows.After.targets file before doing this.
My application use boost 1.54 and it's not up to me to upgrade it. Now I have to port the whole thing to Visual Studio 2013 but I still can't figure out a proper way to build it. So, is there a way to make a vcproj that can be built with VS 2013?
Building boost basically is quite simple.
These guide lines describe the process:
http://www.boost.org/doc/libs/1_54_0/more/getting_started/windows.html
http://www.boost.org/boost-build2/doc/html/bbv2/overview/invocation.html
Basically what you have to do is,
Open a VisualStudio Command Prompt
Change the current dir to your boost directory i.e:
CD c:\myStuff\boost\boost_1_54_0\
Call boptstrap:
bootstrap
start build i.e:
bjam address-model=32
This is the process that worked for me with VC2010. It should work with 2013 as well. If you have problems specific to VC2013, please report the error messages you receive in detail.
You can also use BlueGo to build boost:
BlueGo is a tool which builds Boost libraries using Visual Studio 2010/12/13. You just have to start the application, select your configuration and hit the Build button- everything else works automatically. The application downloads the library, extracts it and builds it.
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 recently create a couple of VSPackages for some Visual Studio extensions (menu bar/command). I compiled them correctly yesterday, checked into TFS (i'm the only one touching this project, FYI). I had already installed these extensions and were working fine. Today it doesn't compile! I get the following error:
Exception has been thrown by the target of an invocation.
This doesn't tell me anything, so i fired up Visual Studio with the following command:
devenv.exe /Rebuild > out.log
In my out.log, I see the following:
C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\VSSDK\Microsoft.VsSDK.targets(420,5): error : Exception has been thrown by the target of an invocation.
I have been stuck on this for hours and can no longer build these VSPackages. Anyone? This is really frustrating. I have already tried cleaning project/rebuilding/build using Visual Studio itself (not command line)
I've experienced this issue several times in both vs2010 and vs2012, and manually deleting the "bin" and "obj" folders from the project then doing a "rebuild" normally does the trick.
Further to the answer provided by the OP, I will provide it here for completeness instead of relying on the external link remaining live:
Quoted directly from the MSDN forum answer:
Do you happen to have these extensions installed to the AllUsers
location (i.e. %VSInstallDir%\Common7\IDE\Extensions)?
You mentioned in your initial post that "I had already installed these
extensions and were working fine."
The task that's failing (based on the line number in the targets file)
is the UninstallExtension task. The only reason I'm thinking this task
would execute and fail in your situation is if you're building an
extension that's already installed to the Common7\IDE\Extensions
directory.
Regards, Aaron
I find myself on this question because of exactly the same build issue of a VSIX Installer Project for our project templates. This solved my issue.
Indeed, I uninstalled the prior version of our templates and the build occurs without issue.
Have you double checked that all of your projects are using compatible framework versions?
As in you can't use a .Net 4.0 assembly in a .Net 3.5 project.
Is the project linked with source control like TFS? If so then take latest from TFS and try again.
Are you running Visual Studio as Administrator?
Maybe you have insufficient rights for some file (copy/move/delete) especially in bin or obj folders.
I'm in the process of upgrading our VS 2008 solution to run on VS 2010
I managed to successfully build in VS 2010
My next step now is to configure a build machine running TFS 2008
Whenever I start a build it does my projects in alphabetical order with no regard for dependencies. I've googled a lot and I can't seem to find a solution to this.
The closest solution to my problem is found here: msdn link which links to this: dependency solution
However I'm dealing with 129 projects, so I would really rather not do this all manually in the xml.
Has anyone been able to effectively remap the dependencies in a way which msbuild recognizes without manipulating the xml for days...?
It turns out that the conversion to VS 2010 makes the build agent have to use the .NET 4.0 version of msbuild.
So I followed the steps outlined here and it worked: Building .NET 4.0 Applications Using Team Build 2008. Keep in mind that those instructions were written during the beta and the path is now v4.0.30319.
This was required even though all my projects are targeting 3.5
Basically I had to make a one line change and now everything is happy (still working on getting my build to pass but the order is good). It had nothing to do with dependencies not being preserved, simply that the way dependencies were being managed wasn't understood by msbuild 3.5
We also have a large number of projects. We wound up (programmatically) creating a MasterSolution.sln file that contained all of the projects. We also require our developers to only use project references in their code. This way, MSBuild always gets the correct order as it parses the .sln file.