I'm in this case, I have a single solution built on Visual Studio 2013. It contains more than 10 projects that reference each others, I need only to build and release 3 projects of them on Azure via Visual Studio Team Services so the question is what is the best approach to do this
Thank you
If they all reference each other than you may need to build all of them. Dependencies will be resolved at build time.
You can reference individual Project files in place of a Solution. You will then need to maintain order yourself.
Just use the same build step for building a Solution, but fill out a Project (.proj) file instead. Control the order by having multiple build steps.
Please read my Suggestions below-
- Copy all the references dll's in one shared folder through Post build event.
- Create new solution according to your deployment needs and take all references from the shared folder in all projects.
- Deploy the solution you want
If the references are project references, you just need to specify the solution file (.sln) to build, otherwise, you need to specify project dependence (Right click your solution=> Project Dependence=>Select a project=>Check the projects’ options that dependence to)
Related
We have an MSBuild .proj file that is used to build and run lots of projects. That have file references to one another. Due to the fact that it is file references, we maintain the list of Project Dependencies on the solution, so that MSBuild is able to identify the order to execute projects in.
We had an issue recently, where our US development team added a new reference to one project, but didn't update the dependencies list. This builds fine for them locally, and on the server. However for the UK team, the build consistently failed for all developers.
I'm trying to understand why this was the case. The only thing I can think of is that our Culture causes the build order to be slightly different when two projects are essentially ranked at the same level. i.e. If Project A and B are perceived to have the same dependencies, then the order the two build in is arbitrarily determined, and this might be different in the UK culture vs the US culture.
That said, my machine (it broke for me) has the Region Format set the English US. And Location UK.
Does this sound feasible? or is there a better explanation for this?
Changing the culture will not fix the issue where you're making a file reference on a components output rather than a project reference to the project that will build the assembly.
Solution files do map dependencies and would help MsBuild determine build order. When MsBuild processes a solution it will first convert it in memory to MsBuild xml format, then it will determine project order by listing the dependencies, then determine if a project needs to be rebuilt by comparing the last update time of the input files to the output files.
When you have a project reference within a project (in a project, open the References folder, remove references to output assemblies and instead reference the project itself). This will modify the project file replacing Reference item groups with ProjectReference item groups. This allows MsBuild to make this determination on a project level and resolves the issue of having to manually configure the project build order.
Good morning'
Team Foundation Server 2010 question.
Do I need to create a Build Definition for every branch I have ?
Is there a way to parametrize 'Workspace' in Team Build 2010 for different branches, so we could just queue a new build specifying the workspace paths?
I tried finding out how TFS retrieves the workspace paths from the workspace used in the build, but the xaml got me clueless since there are parameters for everything except the mapped paths.
Thanks in advance!
Do I need to create a Build Definition for every branch I have ?
No, but you may want to in order to have a cleaner implementation.
Is there a way to parametrize 'Workspace' in Team Build 2010 for
different branches, so we could just queue a new build specifying the
workspace paths?
Yes- but it isn't as straight forward (unless you are using .proj files still).
If you are using the upgrade template and still using proj files:
Building multiple branches, can I use paramters to identify the target branch.
If you are not using the upgrade template, this answer posted on SO will help point you in the right direction:
How to make build definition in TFS Build 2010 configurable w.r.t input variable values and “items to build”
I wish to utilize the new gated check-in function of TFS 2010.
I have about 10 solutions, that all share as a dependency a proprietary shared-code library.
My structure is:
TeamProj/SharedCode
TeamProj/Proj1
TeamProj/Proj2
TeamProj/Proj3
........
The question I have is, how can I set-off an integration of ALL projects that have the SharedCode project as a dependency?
It's possible someone can make breaking changes, and not be aware of it until one of the other projects is opened/built manually.
I want to only trigger a big integration build when check-ins are made against the SharedCode folder.
The problem is, if I map the source-paths required to actually run the builds for the other projects, check-ins are picked-up automatically against all THOSE projects too.
How can I have a gated-checkin controlled folder that is independent to the source actually required to run a build?
Cheers,
Dave
If I understand right, you want to create a Build Definition as gated checkin that builds
TeamProj/Proj1, TeamProj/Proj2, TeamProj/Proj3 when any source file in TeamProj/SharedCode is changed?
In this case, one solution that comes to my mind is the following:
Create the build definition with only source folder TeamProj/SharedCode.
Change the build template to do a TFS GET for the other folders
Change the build template to build all the three solutions Proj{1,2,3}, not the SharedCode solution.
Is this what you want?
So I have a CommonAssemblyInfo.cs linked into all the projects in my solution and is dynamically generated by my rake/albacore scripts which is not checked into source control.
I also have a CommonAssemblyInfo.cs.local for use when there is no ruby available, mainly to be used by devs.
Is it possible to have a msbuild task or something that runs before any of the other project compilation that will copy CommonAssemblyInfo.cs.local to CommonAssemblyInfo.cs before trying to compile my solution? I hate having to have a command you have to just know about and type in order to open and buidl the solution in Visual Studio.
UPDATE
So I ended up using a batch file as a solution wide pre-build event as described here: Solution-wide pre-build event?, it checks to see if CommonAssemblyInfo.cs exists and if not copies CommonAssemblyInfo.cs.local to CommonAssemblyInfo.cs just using a simple batch file.
This is the solution I ended up with.
I have each project in the solution link to a CommonAssemblyInfo.cs which is automagically generated for me by my build scripts (rake + albacore).
Since I cannot check CommonAssemblyInfo.cs into source control, I create a CommonAssemblyInfo.cs.local.
Simple solution: create go.bat which copies CommonAssemblyInfo.cs.local to CommonAssemblyInfo.cs that devs must run the first time they check out the project before opening the solution in VS.
For purely political reasons, if I did this people would have had hissy fits about me doing "nonstandard" things. Complex solution follows:
I created a project in the solution called PreBuild which every project in the solution depends on. This forces the build order to be such that this project is built first. This project contains a pre-build event which calls the following batch file:
echo verifying CommonVersionInfo.cs exists
cd
IF NOT EXIST ..\..\..\CommonAssemblyInfo.cs COPY ..\..\..\CommonAssemblyInfo.cs.local ..\..\..\CommonAssemblyInfo.cs
So now any developers who choose to keep their heads in the sand may checkout the project and blissfully open it up in VS unaware that any build scripts exist at all.
Are you talking about compilation in the VS IDE, or compilation through team build? If you are talking about team build, then you can use the "AfterGet" event as a place to use the standard "copy" msbuild task. If you are talking about the VS IDE, then you can still use the "copy" msbuild task.
I've been struggling with how to best organize my msbuild project files. At one time is was all in one file. Then I split it up into multiple files.
But I want to be able to run 1 master project file that imports everything and builds them with dependencies. Or be able to build a project independently and not have it worry about not being able to find the task in the "dependsontargets" attribute.
So I was wondering if anybody knew of a good reference for me to see how I should be organizing my projects.
Thanks
Not earth shattering, but there are a series of articles in msdn.