Is there any similar property to CompilationOutputs in TFS 2010?
If not, how to get all compiled assemblies including all metadata as in TFS 2008?
In TFS2010, if you use the UpgradeTemplate.xaml build process template you can keep your existing TFS 2008 based MSBuild proj files that use the CompilationOutputs property and continue building as per usual.
If you are using TFS2010 workflow based builds (i.e. DefaultTemplate.xaml or a derivative) then the approach will need to be somewhat different. The workflow makes a call to an MSBuild activity internally in order to compile the solution and there is nothing in the properties for that task that returns the data you're looking for.
To work around the change, further down in the workflow there is an CopyDirectory tasks that moves files from the binaries folder to the drop location. You could always put in your own workflow activities just before or around that point in the process and do what ever it is you are wanting to do.
Related
I am about to move a local TFS project to visualstudio.com
When the project was created, it was created with a SCRUM process template. However, only source control functionality was used (except about 20 work items which can be deleted).
I want to add them to visualstudio.com as a project of process template type CMMI.
I am reading confusing (and seemingly conflicting) information on-line about how it is done (and if it is even possible).
Has anyone does this before (or have experience with TFS migrations in general)? Any input appreciated!
Thanks
You can use TFS integration tool to process migrating Source control and work items. As you want to change the process template, you need to put the mapping file during migration. More information, you can refer to this blog: https://mohamedradwan.wordpress.com/2015/05/14/migration-to-vso-visual-studio-online-with-different-tools/
Currently I'm in the progress of updating TFS 2012 to 2013. My plan is to use the default build process template and stick to it, if possible. The existing build definitions use the old TFS method with TFSBuild.proj files. In thse proj files everything happens. Initializing the solution directory, build, clean, run unit test, drop files, etc. Compared to the 2013 build process template this is incorrect, since the workflow has activities for build, clean, run tests, drop files, etc. As well it seems that the targets file used in the TFSBuild.proj files is of a previous TFS version and hasn't been updated to a 2013 version.
The problem is that besides the build, clean, run test an drop files activities there are other activities needed. Version numbers are changed in certain files, obfuscation for dlls, check procedures if the source doesn't contain any unwanted files, zipping of pdb files, etc.
Of course it is possible to execute these tasks/activities with PowerShell scripts. On the other hand working with tasks in the a project file also seems logical. My concern with performing extra tasks in a project files is that TFS is running the activities for test, dropping files, etc. after calling the MSBuild activity.
Can someone point me in the right direction? Do I need custom developed activities that I can use in the build process template? Or is working with PowerShell scripts best practice?
I think you've answered your own question! Poweshell is the way forward!
I would say that modifying the XAML and writing a custom activity should only be considered if powershell isn't working for you, or if your scripts are becoming so big and difficult to debug that it makes sense to turn them in to code. As you mention, some of these tasks will need to be performed well after the MSbuild activity has completed so that's not going to work.
It looks like you want to do some fairly simple steps at defined points in the process and the powershell extensibility points are perfect for this.
A simple script for versioning in the pre-build step. Checking the source for unwanted files could happen here as well.
The obfuscation, zipping and copying stuff can happen post test.
From a Maintainability point of view, I would say that powershell has a much bigger user base than Windows Workflow and MSBuild so that's another advantage to this approach.
Background
Currently I have many C# projects in many TFS team projects.
Several C# projects reference C# projects in different team projects. I do this by referencing the output dll in the Bin/Release folder of the other C# project.
As long as we checkout & build the solutions in the team projects in the correct order everything works fine on all dev's machines.
We're moving to Visual Studio Online and I'm playing around with automated builds.
Problem
The problem I'm having is that it can't find the dlls to reference, even after the project that would output them (to \Bin\Release) has ran.
I've disabled parallel builds (to ensure the referenced projects get built first) and this seems to be the case based on the build logs. The issue is that the projects that depend on these can't find the dlls and as a result I get "the type or namespace could not be found" errors everywhere.
What's the easiest way of resolving this?
Note that I've read several posts/tutorials etc. about this but all seem to involve changing the source control structure, or fiddling about with workspaces etc. I want something where I can keep the simple workspace mapping on the dev's machines where we map "$\" to "C:\TFS\". I don't want to have to remember to periodically merge in changes from a shared library, or maintain lots of folder mappings within a workspace (on dev machines).
Open your process template xaml (usually DefaultTemplate.11.1.xaml or TfvcTemplate.12.xaml with XML editor, not the designer). Look for mtbwa:MSBuild on Run MSBuild for Project activity. Remove the OutDir attribute, save and check-in. This will force MSBuild to use the default OutDir for each project.
We're using Team Foundation Service instead of a local TFS.
Our solution was created on Visual Studio 2012.
My problem is now that we want all assemblies to have the same version number (this part is already solved by using a CommonAssemblyInfo.cs that is linked into all projects).
The issue I'm facing right now is that we need the tfs changeset number at the last digit of the assembly version (e.g. 1.0.0.4711 where 4711 is the changeset number).
I've found several examples, but none of them worked for me.
And yes, I especially searched here on stackoverflow a lot.
I also have to admit that I've never looked into the MSBuild scripts...
Can anyone please give me a hint on how to accomplish this?
Is it for example possible to use the MSBuild Extension Pack on Team Foundation Service (not local TFS) and if, how to do that?
As always, time is my worst enemy...
Note that from 2010 Tfs employs Windows workflow for building the package the workflow calls msbuild for compiling the projects only - while its possible to pass changeset this way to msbuild its rather more hops.
Following deals with your problem, however the linked solution is more complex that needed:
Can assembly version been automatically updated with each TFS 2010 Build?
This is one of best series of tutorials on the custom build activities, the author is on stack as well i believe, one specificly about versioning
http://www.ewaldhofman.nl/post/2010/05/13/Customize-Team-Build-2010-e28093-Part-5-Increase-AssemblyVersion.aspx
In short you need a custom activity to run before compilation on source files, find all CommonAssemblyInfo.cs files, feed this list to your custom activity, it modifies the values inside with passed value of full version number or only the changeset and optionaly check in the change (probably not since your changeset will be out of sync then).
You can also take a look at https://tfsbuildextensions.codeplex.com/ set of activities there is TfsVersion activity among them, at the very least it will provide examples.
Functionality need for this should be available through Team Explorer and source control - The Custom activity assemblies and build templates usually are located in folder in your team project root - the location of this folder is defined for build controller you can change this through team explorer build section.
Changeset is available from value BuildDetail.SourceGetVersion, not sure if this was fixed/changed in 2012 however there were 2 issues about this value in 2010
Its doesnt respect GetVersion override in default build template - you will manualy need to update if override is used
When running latest build (no override) it will get the last changeset number from tfs - depending on your branches this may not be the same as 'last' changeset for the branch of build. You will either have to live with this, provide overrides for each build or implement activity that checks branch history for last changeset value and overrides it again.
It should be noted that GetVersion should be able to accept any sourcespec version - changeset, date, label etc. I havent played around with this enough to provide more details to you.
Colin Dembovsky wrote a great overview of doing version embedding using the new pre-build script setting in TFS 2013 build definitions.
The Changeset number is easily accessible within the pre-build process in the environment variable TF_BUILD_SOURCEGETVERSION. I was able to use this to embed the Changeset value in our binaries using a script based on Dembovsky's work above. (I used Perl, not powershell, so you probably don't want to see it ;-)
This approach doesn't require any changes to the build workflow which makes it a big win for me.
I've used Wintellect's solution - MSBuild-only, no TFS magic needed. I also added to the auto-generated CSharp file:
[assembly:AssemblyInformationalVersion("$(BuildNumber)")]
So I get the TFS build number.
We're currently setting up a number of builds in TFS2010 for our various projects/solutions.
We have a large number where the structure and paths, etc. are essentially the same, but one word may change (for example, using all Integration workspaces versus our Trunk workspaces).
In TFS2008, I would simply edit the XML directly and do some creative search and replace or some magic in textpad before saving the file. However, I do not see any immediate way of doing this in TFS2010 - so I'm stuck slogging through the build definition UI.
I know, in doing a SQL Trace, that all of this ends up as XML - so is there a way to directly access this XML for hand-editing vs. being forced to do all changes through the front-end?
Thanks!
Edit for additional clarity
I have the Power Tools installed, etc. and can clone my builds - but my editing options are still limited to the UI, so if I have a large number of workspace path changes I have to do them by hand (one at a time).
My goal is to be able to directly edit the XAML for a specific build definition so I can do a clone, open the XAML, and then do a search/replace in bulk.
Download and install the Team Foundation Server Power Tools. You can also get them through the Visual Studio Extension Gallery. After installing, you can right click on a Build Definition in Team Explorer and select the Clone Build Definition command (added by the Power Tools installation) to make a copy of an existing build definition. Then you can tweak it appropriately for another branch, etc.
The following tool (VS Addin) will satisfy your requirement>
Community TFS Build Manager
http://visualstudiogallery.msdn.microsoft.com/16bafc63-0f20-4cc3-8b67-4e25d150102c
The build definitions are all .xaml files now - they're WF4 workflows, and they're XML files.
Jim Lamb is right. The build templates are .xaml files now. The definitions are accessed through web services.
I'm about to experiment with a quick HTML form posting to /tfs/_tfs_resources/Build/V3.0/BuildService.asmx/QueryBuildDefinitionsByUri. I noticed when I clicked the build definition in Team Explorer that it has an associated URI: vstfs:///Build/Definition/2. Stay tuned.