I'm facing a weird issue while trying to build using MSBuild.
I'm using MSBuild to build a solution file with /m (parallel build) and BuildProjectReferences set to true.
Suppose I have A.vcxproj and B.vcxproj in the sln file with B having a project reference to A.
What happens is A project starts to build first and while its in the middle of compiling, B project starts to build in another process (since parallel builds) and it would invoke building A.
Now this causes a race condition because we have two processes trying to build the same project A and I would see access issues.
Ideally MSBuild should not invoke building B if A hasnt finished building or if it does invoke B then detect that A is still building and wait for it to finish.
None of this happens. Also, this happens only with MSBuild - doesnt happen if I try to build the solution file from VS2015 IDE.
Any idea why MSBuild behaves this way?
Finally found the solution to my problem
MSBuild expects that the project dependencies be added in two ways
1. In the vcxproj itself, add all the dependent projectreference
2. In the sln file too, define the projectdependencies.
The following VS blog actually states the opposite- For example - https://blogs.msdn.microsoft.com/vcblog/2010/02/16/project-settings-changes-with-vs2010/ states that projectdependencies and projectreference are analogous and use only one specifically projectreferences.
This may be true when you build using VS IDE but not for MSBuild. It needs the project dependencies to be defined on both ProjectReference and ProjectDependencies.
Hope this helps anyone who hit into the same issue as mine.
Related
I'd like to invoke MSBuild to build a single project inside a solution.
Therefore I use
MSBuild MySolution.sln /t:MyProject
Since I have some sophisticated deployment process and I want to save time, I need to build just the one project, but nothing else. Like mentioned here I tried
MSBuild MySolution.sln /t:MyProject /p:BuildProjectReferences=false
which works for project-to-project references, but not for project references defined by the solution (via ProjectSection(ProjectDependencies) in sln-file).
Does anyone know a way to ignore the solution project references also?
I want to build a project with a particular named Build Configuration, let's call it Conf-A.
This is running as an MSBuild step on TeamCity. When the build runs, it spits out:
The OutputPath property is not set for project ... You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project.
This project is part of a hulking great solution we load on our dev machines.
The error makes sense for my situation, since I'm building just the proj file, but I don't want to use the solution file since I'm trying break-up this monolithic app.
I want the build-server to treat this project as it's own component, even if for the moment it is part of a solution and has references to other projects (assemblies) in the solution.
Must I build this via a solution file?
I could potentially copy the solution file and prune off all the other projects that are not required, but that's more complexity.
(Maybe the error is a red-herring).
you dont need to build a sln. Its like the error says. You just havent specified a value for the variable OutputPath in your msbuild. You can add it to your files or you can pass it in at the cmd line - msbuild someproj.proj /p:OutputPath=C:\notallovermydrive
I'm struggling to find a solution for this issue.
I have a solution (VS2008) that contains around 50 projects (C#).
The inter-project dependencies are added as project-reference (and not by referncing a DLL).
Also, the dependencies inside VS is set correctly in the solution settings dialog.
The problem is, when building the solution from MSBUILD (command line) on our CI server, msbuild will build the projects in what seems to be the order that they're laid out in the solution file, and not according to the dependencies.
I've found numerous references for this on the web, with no solution...
What can i do in order to build the solution correctly with msbuild from command line ?
This can be due an invalid build order inside your solution. You can change the build order without removing and re-adding the project. In Solution Explorer, right-click the solution name and select Project Build Order. You will be able to specify the build order of your projects so it should work in msbuild. This commonly happens if inside VS you have cached the DLL's during development. To verify if it works, remove all obj and bin folders before changing the build order and running the build.
I have a build.proj, that is a MSBuild file and can be run locally.
All I need from TFS is
Get the sources from TFS Source Control.
Call "MSBuild.exe /t:Deploy".
Update the build status based on the result of MSBuild.
I have tried to make a template combining the DefaultTemplate.xaml and UpgradeTemplate.xaml.
But so far, no luck :-(
Can someone help me make this template?
If you select the upgrade template that comes out of the box when you create a new TFS project with 2010, you can supply your old TFS2008 proj (MSBuild) file without problems. Please read http://msdn.microsoft.com/en-us/library/dd647553.aspx for more details.
You should use DefaultTemplate. I had the same problem and I solved it this way.
You can do it using UpgradeTempate also, but using DefaultTemplate was easier for me.
On Process section follow these steps:
Select Default template
Add your project into Items To Build collection
Set MSBuild Arguments (Advanced section) to "/t:Deploy"
I have MSBuild project file for running builds locally. This script is used also for sever builds. I have three MSBuild projects in Items To Build collection. One for PreBuild step (some checks before build is executed), main build script used also for local build and the last script for additional post build tasks (deploy process). I'm setting additional MSBuild propertires like IncrementalBuild and ServerBuild properties in MSBuild Arguments.
Ok, so I've got a somewhat complicated problem with my build environment that I'm trying to deal with.
I have a solution file that contains multiple C# projects which is built by a NAnt script calling MSBuild - passing MSBuild the name of the solution file and a path to copy the binaries to. This is because I want my automated build environment (CruiseControl.Net) to create a folder named after the revision of each build - this way I can easily go back to previous binaries for any reason.
So idealy I have a folder layout like this
c:\build\nightly\rev1
c:\build\nightly\rev2
c:\build\nightly\rev3
...
c:\build\nightly\rev10
etc.
The problem that's arisen is I recently added the latest version of the Unity IoC container to my project, checking it directly out of MS's online SVN repository. What's happening is I have a Silverlight 3 project that references the Silverlight version of Unity but I also have other projects (namely my Unit testing project) that reference the standard (non-Silverlight) version of Unity.
So what happens is since MSBuild is dumping everything into one single folder the Silverlight version of the Unity assembly is overwriting the non-Silverlight version because they have the exact same assembly file name.
Then when CruistControl runs my unit tests they fail because they don't have the proper dependencies available anymore (they try to load the Silverlight specific Unity assembly which obviously doesn't work).
So what I want to do is:
keep my desired output directory
structure (folder\revision)
I don't want to have to manually edit
every single proj file I have as this
is error prone when adding new
projects to the solution
Idealy I would like MSBuild to put everything into a folder structure similar to this:
nightly\revision1\project1
nightly\revision1\project2
nightly\revision1\project3
...
nightly\revision2\project1
nightly\revision2\project2
nightly\revision2\project3
etc
I can't modify the Unity project to give it a different file name because it comes from another SVN repository I cannot commit changes to. I found a similar question posted here and the suggested solution was to use a "master" MSBuild file that used a custom task to extract all the project file names out of the solution then loop over each one building them. I tried that but it doesn't build them in the order of their dependencies, so it fails for my project.
Help?
Firstly I would always have the build server delete the old working copy and check out a fresh copy to avoid any problems with stale artifacts from the previous build.
Next I would have nant or msbuild build the solutions as before with the artifacts from each build going to their local working output folders.
After that I'd move the artifacts from their working paths to their output paths, this shouldn't require digging through the project files since you can just tell msbuild/nant to copy working\project1\bin\release\**\*.* to artifacts\project1\.
The script that does this should ideally be stored along with the source with the main file, e.g. build.nant or build.proj in top level of the trunk.
For third party libraries I would simple include the DLLs directory in your repository. Nothing worse than writing some code and having a third party dependency break your build because of changes on their end.
Simply document the versions of the libraries you are using, and if you must update them, you'll have a better sense of what breaks the build before you even check it in.
Also, doesn't CC.Net automatically handle the providing of releases based on revision? I'm using TeamCity and it keeps a copy of the artifacts of every build.
I highly recommend reading JP Boodhoo's Automating Builds with NAnt blog series. That's been my starting point and have made lots of changes for my own taste. I also highly recommend checking out the builds of many open sources projects for examples. I've learned a lot from the builds of the Castle/Nhibernate/Rhino-Tools stack.