Build process template not visible when creating build definition in TFS 2010 - tfs

I am trying to add a new build process template (XAML) to TFS 2010, using VS 2017.
I have committed it under the BuildProcessTemplates folder for the team project and it is shown in the Source Control Explorer, but it doesn't show up in the drop down list on the Process tab of the Build definition dialog.
The drop down list only shows the other 3 templates (DefaultTemplate.xaml, UpgradeTemplate.xaml...) in the folder.
I found this description of how the dropdown list works:
This list is populated with the following build process templates:
The ones that come out of the box (DefaultTemplate.xaml,
UpgradetTemplate.xaml and LabDefaultTemplate.xaml). These are created
for every new team project (this can be changed by modifying the
process template)
Any build process templates that have previously
been added for any other build definitions in the same team project.
The last bullet is a bit unintuitive, but it means that if a developer creates
a new build definition in team project A, and adds a new build process
template (for example by by selecting New and then browse to an
existing .xaml file),
this build process template will be available in the process dropdown
list for all other build definitions in team project A. It will not be
available in team project B, but has to be added in the same way.
https://blog.ehn.nu/2010/11/managing-build-process-templates-in-tfs-2010-build/
I tried clicking on "New..." next to the drop down list. It only shows the option
to "Select a team project that contains your build process template", there's no option to create a new one.
If I enter the path to the .xaml file under "Path in repository" and click on OK I get an error: "Object reference not set to an instance of an object"
Screenshot of error
How do I make the new build process template available for build definitions?

Normally, you just need to check in the template xaml files under the BuildProcessTemplate folder, then in Build Definition Process tab, Click New… button to add these xaml files from that fold. The path of xaml should have a \ sample in front of it.
In your case, also try to clear TFS and VS cache, then try it again.
If delete cache folder still doesn't work, please try it with older Visual Studio Version such as Visual Studio 2015 and create a new build definition, select the template.
Also take a look at this blog shows the customize process template experience in TFS 2013, which may be helpful.

Related

Adding project from VS2013 to AzureDevOps

Im using VS 2013 (CE).
Windows Server 2012 with a local install of Azure DevOps.
I can connect to the repository via the URL
http://example.local/DefaultCollection
Under defaultCollection i have another few test projects i.e.
/DefaultCollection/A-Project,
/DefaultCollection/B-Project.
For this example i will user C-Project which im trying to add to source control.
All im trying to do is add a project to this source control but i am experiencing issues that i would have thought shouldnt exist:
In VS2013, I add a new solution. I right click the project and select "Add solution to source control". Immediately it selects the project A-Project with the path /DefaultCollection/A-Project/C-Project. I dont want this as it resides inside another project.
From the web portal i create a new project and select Team Foundation Server (not Git as the examples online i have seen all select Git). In VS i create a brand new project and then attempt the same as 1 above but it tells me that i already have a project with this name under source control. I expand A-Project and i see it listed and undo any changes but it still doesnt add as i get some form of error.
Other problems range from the local version not mapped to, existing file exists/under source control to other errors.
What is the correct process to add a project to Azure Devops when using Visual Studio 2013 CE?
The default steps are described here: Set up Team Foundation Version Control on your dev machine.
You have to:
Create a workspace from the target project.
Copy your project into the locally mapped folder.
Add your project to the source control.
As workaround:
Create workspace from the target project: Create and work with workspaces
Copy your project into the locally mapped folder.
Add your project to the source control by: Manually add files to version control
Open the project and fix source control bindings:
Useful document: Add files to the server

How do I create a new build definition in TFS 2017 across projects

We just upgraded from TFS 2013 to TFS 2017 and I was excited to go in and create a new build definition, but I can't seem to do it at the collection level. I can only create a new build definition once I've selected a project and then when defining the Get Sources page I can't seem to access other projects within the collection. The highest level it will allow me to get is the current project. In the Repository drop-down the only option is the current project. How can I create a new build definition across projects in TFS 2017?
The TFS build is project level for now, it's not able to create a build definition at collection level and across projects. For 2015 you could, instead of using the trigger path '$/{team project}', also insert just '$/', which would result in that the continuous integration build triggers on all check-ins in that team project collection. It's more like a backdoor.
However, In TFS 2017, it 's no longer possible to freely edit this field, and that you can only add a trigger for the team project that the build definition resides in.
There had been a uservoice and got started:
VSO build vnext: share build templates between projects
https://visualstudio.uservoice.com/forums/330519-visual-studio-team-services/suggestions/8468566-vso-build-vnext-share-build-templates-between-pro
As a workaround you could export your existing build definition in the project to other project. However, this just avoid you manually duplicating the definition in another team project. It's not able to get source from another project which different with the build definition belongs to.
There is an Export/Import Build Definition extension in Visual Studio Marketplace you can use now. Also available from within the TFS2017 update1 Build Definitions web UI:
.

TFS 2010 Missing Process Templates

I am trying to set up continuous integration using Visual studio 2010 and TFS 2010 and when i try to Create a new build definition, and go to Process Tab, i dont see any templates under the Build Process file(Windows workflow XAML) drop-down.
I have setup a build controller that points to our Team project collection and a build agent, in our TFS server.I am trying to setup a new build definition from my local machine Visual studio and i cant see any default templates under the Build Process file(Windows workflow XAML) drop-down.
Is there any settings i am missing ?Please let me know. Do i also need to install Visual studio in the TFS Server ?
All i need is whenever someone checks in a file, it should kick off a build and see the status if the build is broken or not !
Make sure you have a folder inside your Team Project Source Control called:
BuildProcessTemplates
Inside of there should be the following files:
DefaultTemplate.xaml
UpgradeTemplate.xaml
There are additional ones in this example, but you should have those two from the install.
If you have this folder and still cannot see anything in that dropdown let me know and we can take it from there. What most likely happened is you or someone on your team saw the folder and deleted it or moved it thinking it its placement wasn't important in the project. Or perhaps deleted the xaml files inside there.
The process section uses that folder and all files within it to display on that prompt.

Steps for changing process template for an existing project in TFS 2010

I have an TFS server installation that through time has gone through upgrades from TFS 2005 to TFS 2008 and then to TFS 2010.
During the lifetime of the installation a lot of projects have been created and different project templates have been used. MSF Agile 4.0, 4.1, 4.2 and 5.0. and a few MSF CMMI ones.
What I would like to do is "replace" the project template used for all these projects to use a new one common one: Microsoft Visual Studio Scrum 1.0.
I am aware that TFS project templates are used as templates for creating new projects and cannot modify the tfs projects definitions after creation.
Uptil now only the version control and build server part of TFS have been used and there are no existing work item types.
Additionally all projects and build scripts are depending on the source code paths stay the same.
As I see it I have the following options:
Create new TFS projects using the correct project template and then move/branch the source code to the new project.
All code is moved to a temporary team project.
The old project is deleted
New project with the original name and correct process template is created
Code is moved to the new team project
Temporary team project is deleted
All the build definitions needs to be to recreated which is not an option.
The source code move/branch will "mess up" the versioning history
By messing up the versioning history I mean that when you move source code it will behind the scenes do a delete + source rename on the original location and the history will still be located in the old project. This will make searching in the history difficult and if I actually delete the old project I will loose all the history before the source code move.
This is really not an option for me since there is years of code change history that is needed to for supporting the different applications being built.
Use the TFS migration tools to migrate to another TFS project
This has the same downsides as the first solution
Replace/import work item types, install new reports, create new SharePoint sites
For each tfs project
Delete existing work item definitions using "witadmin deletewitd"
Import each work item definition from the new process template using "witadmin importwitd"
Import work item categories using "witadmin importcategories"
Delete old reports in project folder in report server
Upload the report definitions from the new process template
Modify data sources used for the reports using the report manager to point to the correct shared data sources (TfsReportDS and TfsOlapReportsDS)
Modify the report parameter ExplicitProject default value to "" (empty string) and disable prompt user option.
Export the documents in the old SharePoint site using stsadm
Delete the old SharePoint site
Recreate the sharepoint site using the TFS2010 Agile Dashboard site template
Activate site feature "Team Foundation Server Scrum dashboard"
In TFS Project Settings -> Project Portal Settings: Enable "team project portal" and ensure the url is correct. Enable "reports and dashboards refer to data for this team project"
And finally..
Process the Warehouse
Process the Analysis Database
Even though that this involves a lot of small steps this looks more appealing because
this option will not force me to move the source code and my existing build definitions will be intact.
My question:
Are there other ways to achieve the replacement of work item types that I haven't mentioned?
And/or am I missing any steps in last solution?
Given that you aren't using any existing work item types, your final proposal looks like the best option.
After deleting the old reports and exporting the SharePoint documents (you could also use Windows Explorer instead of stsadm), there are actually two commands in 'tfpt' that will help you. This will reduce it from 14 steps down to 5 or 6 steps.
tfpt addprojectreports Add or overwrite reports for an existing team project
tfpt addprojectportal Add or move portal for an existing team project
tfpt addprojectreports /collection:http://yourtfs:8080/tfs/YourCollection /teamproject:"Your Team Project" /processtemplate:"Microsoft Visual Studio Scrum 1.0" /verbose
tfpt addprojectreports /collection:http://yourtfs:8080/tfs/YourCollection /teamproject:"Your Team Project" /processtemplate:"Microsoft Visual Studio Scrum 1.0" /verbose
Your first option is IMHO your best shot.
You can branch the sources from the old team project to the new team project. With TFS 2010 you can see the history also from the branched location. So you don't loose functionality in here.
The Build is just an msbuild file which is stored in source control. The only thing you have to do is actually copy the build definitions. You can do that either manually, or you can create a little app that does that for you.

Proper build reports in TFS with multiple products under a project

Underneath one "Project" in TFS we have multiple products. This is because for us, a project is a business unit and they each can have many applications that we develop for them. Each one has its own folder in source control(under the TFS project) and each one has its own TeamBuild set up. The issue I have is that whenever a build runs, the report generated for it contains a listing of all the changesets that were associated to the TFS Project; even though many of them were for a different product and the code referenced actually wasn't compiled or built during that build.
Does anyone know how to get TFS to only include changesets in its report that are associated to the actual VisualStudio projects that are being built in TeamBuild?
The best solution would to to modify the Workspace Mapping for the Team Build Definition to include the Solution Root path instead of the Team Project Root.
In TFS2008,
Right click the Team Build Definition and choose 'Edit Build Definition'
Select the 'Workspace' tab
Remove the existing mapping: $/TeamProjectName
Add a new mapping to the solution root, for example: $/TeamProject/Main/Solution1/
In TFS2005,
Open Source Control Explorer
Browse to $/TeamProject/TeamBuildTypes/BuildName/WorkspaceMappings.xml
Get Latest of the file and check it out for edit
Remove the existing mapping: $/TeamProjectName
Add a new mapping to the solution root, for example: $/TeamProject/Main/Solution1/
This workspace mapping defines the scope for changesets to be included in the build.
See:
http://blogs.msdn.com/buckh/archive/2007/08/14/tfs-2008-a-basic-guide-to-team-build-2008.aspx
http://msdn.microsoft.com/en-us/library/ms181718.aspx
http://msdn.microsoft.com/en-us/library/ms181286.aspx
Grant

Resources