When I first looked at the Source Control Explorer in TFS 2012, the thing I noticed first was the introduction of the “Reparent” Menu option in the context menu.
I know that this is not new, It was there in Visual Studio 2010 as well only it was hidden away deep down in the file menu.
I will be honest, until a few weeks ago I never used it. I did not have a scenario where this was handy and I could not really understand why someone wanted to Reparent a branch.
The scenario I had was actually pretty obvious. For the purpose of this blog I simplified it a bit but it is still the same thing.
Imagine you have a Generic Component. This is used in several project. You created a branch of a version of this Generic Library. As you can see in the picture below. The Generic MAIN was release to Release 2.0 and this Release is now used in a project.
In the meanwhile, people worked on Version 3.0 of the Generic Libraries. This was released before the project was finished. The project now wants to use the newest version of the Generic Libraries. This is scenario that makes sense.
When I came across this, I thought of the Reparent option. Just Reparent the Project Branch to the 3.0 Release and Voila! All Fine.
Almost …..but not really..
How Reparenting works
When you click reparent on the target branch, you initially see the following picture.
That is strange. How can you point to another parent then? The solution is baseless merging. First you do a baseless merge of the new parent to the target branch. With this action you set “a” relation between the 2 branches.
Baseless merge is something you do from a command prompt. Open a Visual Studio Command prompt, navigate to the workspace directory of your new parent branch and execute the following command
tf merge /recursive /baseless "$/GenericLibraries/RELEASES/GENERIC LIB RELEASE 2.0" "$/BranchProject/GENERIC LIB - Branch Project"
After this action you have pending changes. Check in the changes and view history on your target branch. You will see the merge action. When you choose “Track Changeset” on the merge action you see a nice picture drawn of you latest actions.
Now the relation is put into place, select the target branch and select the “Reparent” option (VS 2010 file menu, VS2012 Contect Menu—See above). This shows the current parent and the new parent. Select the new parent and press “Reparent”.
After this action the new parent is set.
Hope this helps!
I frequently build custom tooling against the TFS API. Sometimes Windows Applications but most of the time I build Web Applications.
When building Web Applications it is no secret that your application runs under the credentials of the application pool.
When accessing work items via TFS API from your web application you can get the error:
I have seen this error as well in the SharePoint WebParts that Access TFS.
You get this error because the user under which the application runs, has no rights on the folder mentioned. Duh ! But why?
Every time your application makes connection to TFS a cache is built up to speed up things in a later stage. This cache consists of a lot of files that are generated.
Visual Studio uses this as well, Visual Studio builds up a cache at:
A little off-topic but if you have any problems with red crosses in Team Explorer or Team Explorer acting weird, delete all files in this folder!
When you don’t want to think about anything, you just give the application pool user of your custom application or the service account of your SharePoint application [Modify] rights to the folder mentioned (c:\programdata….). Make sure you do this on all front-ends if you have a load balanced network.
Sometimes this is fine, sometimes this is not allowed by the sys admins. Don’t fear….there is another way !
You can set the cache path yourself!
In your web.config of your application you can add a appSettings key called [WorkItemTrackingCacheRoot] that has a value of a path that you can decide (c:\temp\cache?). In this way you can have all custom files (your website/service, logging and cache) together and set up rights for all required users.
This key is also used in the WebAccessClient. In this case the value points to (did you already guess?)
C:\ProgramData\Microsoft\Team Foundation\Web Access\Cache_v10.0.30319
Hope this helps !
I do quite a lot of Build customizations and usually I create a new Build Template for each type of Build I want to do.
You can choose to copy the file in the Build Definition Editor or you can just Copy/Paste the file in Windows Explorer. The advantage of the editor is that it directly copies the file to Source Control.
When you do Build Customizations, it is necessary to have a solution that contains a project with the templates, and a project with your custom activities. In my case I have a template project that contains all my different Build Template XAML files. When you copy a template and build the solution, the following error pops up.
The type 'TfsBuild.Process' already contains a definition for…”
What is happening here?? It even gives you this message when you copy it from the Build Definition Editor.
The Build Template is a XAML file and is handled that way by the compiler. If you open the properties of your Build Template file in the solution explorer, the Build Action is set to XamlAppDef for Workflow files.
When this is the case, source is generated each time when you build. You can set the Build Action to None to fix the problem. However, this does not compile the workflow and you can not programmatically call this.
Sometimes you want to achieve this and thus set the Build Action to XamlAppDef. When you have 1 workflow everything is fine, When you copy the workflow the problems start. The code that is generated on compile time looks in the xaml file to obtain the namespace. Because you copied the file, the namespace is the same and the same class is generated for different workflows.
To fix this right click the Build Template XAML file and choose View Code.
In the first line there is the name of the generated class
Rename this to something you like. For example TfsBuild.BlogExampleTemplate
Keep the “TfsBuild” for now….
The rest of the file points to <this:Process
Replace all occurrences of this:Process with this:BlogExampleTemplate.
That’s it. Reload the file and you’re done.
If you also want to change “TfsBuild” in your own namespace for example “Company” change the x:Class attribute in "MyCompany.BlogExampleTemplate” and the
Good luck !
Recently I was doing some work on Work Items. I had to remove a field from a Work Item and wondered what would happen with History etc..
In this blog post I describe the things that happen if you delete a field from a Work Item Type Definition.
For this post I added a Field “Test.TemporaryField” to a Bug Work Item.
I added the field to the form and saved 3 revisions of the Bug.
This reflects in the history as expected.
Then I remove the field from the Work Item Type. Of course I removed it from the form first.
I hoped that the history would still contain the field, but the history only shows fields that are currently available on the work item.
But in the Tfs_Warehouse all history is still preserved
And then as a final test, I re-added the field to the bug. Magically, all history pops up again. Obviously it was not deleted at all..
Hope this saves you a lot of uncertainty…
The answer to the question in the title probably varies from person to person. Some people will say that an implementation of Team Foundation Server (TFS) automatically implies an implementation of Application Lifecycle Management (ALM). Other people will say that this is not the case and you don’t get ALM by implementing TFS.
I belong to the last group of people with some nuances. I firmly believe that an implementation of TFS (and of course Visual Studio along with it) is a really good start of an ALM implementation and that some aspects of ALM almost get arranged without any effort. Unfortunately ALM implementations often stop after implementing TFS and organizations do not get the value from the product that they actually want.
The reason for this blog post is that I want to raise some awareness around the implementation of ALM within your organization. What does it mean, what needs to be done and who are involved? I feel that it is very important to set expectations about an implementation up front.
People know that you are not an author after installing Word or a designer after installing Photoshop. Somehow this is different with TFS. At first hand some (or many?) organizations think they do ALM after installing TFS.
I work in the profession of TFS/ALM implementations since 2006 and because of this I can easily recognize if the implementation is a TFS or an ALM implementation. It is totally OK to install TFS without doing ALM and it can in fact be very useful, but the expectations must be set correctly.
I know I am doing a TFS implementation when I get questions like:
The questions are “How” questions. There is a problem or a requirement and one of the TFS/Visual Studio features can solve this. These questions are often asked by technical people. Software developers, testers and/or architects. They are directly involved in building software and see the bottlenecks in that process.
Microsoft has the tendency to target most of the presentations and marketing on these people as well. “Look at this great feature and what it can do for you!”
It is definitely an ALM implementation when I hear:
The big difference with the “TFS” questions is that these questions are focused around a specific problem area. The “Why” is clear at this point or is at least the starting point. Something is wrong, we know why and we want to fix it. The “Why” questions can still be asked by the same Software developer, tester and/or architect. However, often the business, product owners and Head of IT are involved as well.
Instead of choosing to use a great feature because it is a great feature, both features and process changes are sought to solve a problem. In most cases TFS/VS can help in solving these problems but sometimes TFS is not even necessary.
Make sure you know what kind of implementation you are initiating up front. Is it mainly about features or tools, start a TFS implementation. If you want to solve business problems, start an ALM implementation.
It does not matter what sort of implementation you choose to initiate, just be aware of it. Both are valuable and are the best choice in a specific situation, both have a different goal and both need a different approach.
If you acknowledge the advantages of Application Lifecycle Management and you actually choose to do an ALM implementation, you need to arrange more then implementing tools. Generally speaking, you cannot expect an ALM implementation to be successful when only technical people are involved.
To facilitate a successful implementation prepare yourself with the following points.
ALM implementation is not only technical, but it is a process implementation also. Changing the process implies changing the way of working. You will notice that most people are willing to change but some people are very reluctant. Do not exclude those people but involve them. Try to give them value on their area. At a certain point things will change. Support of management is crucial here. They need to guide this process and keep everybody on board. , Understand, a business realize its needs by people, tools and process.
I would recommend everybody to use TFS and Visual Studio. Both are great tools that provide you with a lot of possibilities. However, make sure that you know the reasons and people behind an implementation. Is it TFS or ALM that you are implementing?
Be aware of your choice and define your strategy up front. It is perfectly OK to do a TFS implementation if that suits your situation. No matter what type of implementation you choose, make sure you manage the expectations accordingly.
In this series of blog posts I like to highlight some features of TFS/Visual Studio that people seem to overlook. In my day to day job I often see that people don’t know about certain feature that are available in Team Foundation Server, Visual Studio or some of the Powertools.
Some features are available as a Powertool. These can be downloaded from here
In this part…….
Sometimes it useful to have an overview of all the states of a work item, and how the different states interact wit each other.
The state transitions and states are defined inside the Work Item Definition. Surely you can export the work item type definition and look at the XML or, for a better experience, open the Work Item Type Definition in the Process Editor. This is all possible but not very user friendly.
A better way to do this is use the Web Access Client that comes with TFS.
When you use Team Foundation Server Source Control you certainly know about history. Sometimes you want to see the history of a single file and see how certain pieces of code ended up there. Who did that and when was this done.
In TFS 2010 you get the possibility to annotate your file. Simply right click a file in Solution Explorer or Source Control and choose Annotate.
When you click this, the latest version of the file is loaded with annotations on the left side.
The blocks on the left show you the changeset number, the author and date. When you click the changeset number, the changeset details open directly.
Have fun !
I use TFS for a number of years now and I have a few tools and links that I always take with me.
Let me share them with you
Team Foundation SideKicks by Attrice
This tools has some great features for doing administration tasks in TFS. Looking at checked out files, workspaces or doing code reviews. Great Tool !
Import/Export Areas and Iterations tool by Neno Loje
This tool allows you to import and export all areas and iterations in a Team Project. When doing migrations this tool is priceless! Thanks Neno!
Import/Export Work Item Queries
This tool allows you to export all Work Item Queries and folders and reimport them in another Team Project. Again when doing migrations or movements this tool is a must!
If you use a lot of reports it is sometimes useful to download multiple reports at once. This tool allows you to do this. Last time I looked it could not handle subfolders but this can easily be fixed in the code that you can download from codeplex as well.
TFS Administration Tool
This tool allows you to easily set permissions on TFS, SharePoint and Report Server all at once. This is very useful for administrators
TFS API Series by Shai Raiten
This great blog of Shai Raiten has code examples and downloadable samples for a lot of different TFS API subjects. Work Items, Test Cases, Builds all can be programmatically accessed and Shai describes it.
TFS Build Customization by Ewald Hofman
Ewald describes the most relevant aspects of customizing TFS Builds. This is a must read for anybody who wants to customize the TFS 2010 build processes!
Of course there are some great tools in Visual Studio as well. The most important one
I got this message a few weeks ago and it scared me. Why? Let me tell you.
The company where I do a lot of consultancy called me in the middle of the day that users started receiving this message. People could not check-in, create work items or add/edit any TFS information.
The support engineer already had looked in the Event Log and found the following result.
Detailed Message: TF30065: An unhandled exception occurred.
That scared me. I had had this message before and back then it was a full disk of the database server. That still is not nice as it not easily fixed sometimes, but at least it is obvious.
When searching the internet I found many suggestions, but most of them indicated that I should put the DB in Simple recovery mode, or clean things up.
Do not do that because this can have serious implications!
Our disk was not full, and existing artefacts (work items, source, builds etc.) where still accessible. The database was about 50Gb. I was not planning to do anything about the database structure or data so more investigation was needed.
Strange….When we looked a little bit further in the event log there were also different kind of messages.
“Could not allocate space for object 'dbo.WorkItemsWere'.'PK_WorkItemsWere' in database 'Tfs_DefaultCollection' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup”
Aha ! That was actually the hint I was looking for. As we already checked disk space I thought of SQL Server. You can fix a database. What I understood is that this is a trick a lot of DBA’s perform to increase performance on a database. Fix the size of the database file.
In order to fix the problem, we opened the properties of the TFS_DefaultCollection database and changed the autogrowth property to Unrestricted File Growth.
Visual Studio 2010 has this nice feature for config transformations. When adding a new build configuration you also get the possibility to add a web.[Configuration].config file which contains specific settings for that specific configuration.
When using the publish function, the transformation uses pretty slick XSLT transformations to update the web.config with the settings you specified in the web.[configuration].config.
You can read all about this functionality here. http://msdn.microsoft.com/en-us/library/dd465326.aspx
When you are coding for Azure or coding in a team with a number of developers, web.configs and app.configs can really make life hard. Especially for Azure it is hard to maintain the different configurations for the Acceptance and Production environment.
Likewise when you are developing software in a team, it is also very unhandy that with every Get Latest Version, your config settings with all your connectionstrings and local paths are overwritten with the settings of your fellow coder.
Would it not be nice to use these transformations to solve these problems as well? Just create your own config settings and the build process takes care of everything? Don’t worry about wrong settings or connections? Yes it would ! Unfortunately, the transformations only work on publish and not on build.
Together with my friend and colleague from Delta-N Jasper Gilhuis, I figured out a way to use this transform functionality within Visual Studio and the TFS Build Server, which gives you loads of possibilities regarding different configuration files.
The solution we have found can be implemented in the following way:
· Create a Web.Computername.config and perform the default transformations as described here http://msdn.microsoft.com/en-us/library/dd465326.aspx
1: <UsingTask AssemblyFile="..\BuildTasks\Microsoft.Web.Publishing.Tasks.dll" TaskName="TransformXml" />
3: <Target Name="BeforeBuild">
4: <Copy SourceFiles="Web.Config" DestinationFiles="Web.Original.Config" />
5: <TransformXml Source="Web.Original.Config" Transform="Web.$(Configuration).config" Destination="Web.config" />
Make sure the path to the Microsoft.Web.Publishing.Tasks.Dll can be found. Best is to
copy the assembly to a relative folder of your solution. You can find the assembly here. C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web
To test it, just put a dummy value in your web.config and a real value in your “own” config. Build Solution and voila!
For the Team Foundation Build Server, just create a configuration like you did before and point to that configuration in the Build Dialog.
Nice thing is, this works for all xml based config files because it is plain XSLT transformations. To use this functionality with app.config or any other.config, follow the steps described here http://stackoverflow.com/questions/3004210/app-config-transformation-for-projects-which-are-not-web-projects-in-visual-studi to make the other configs dependent as well.
For your convenience I added a zip with a preconfigured solution with web.config transformations