Abel's World

TFS WorkItemChangedEvent... WHERE IS IT???

2010-08-24T16:52:00.001-07:00

In TFS, I sometimes need to write a WorkItemChanged event handler. No biggy, plenty of examples on how to do that. But what's hard to find is what dll is the class Microsoft.TeamFoundation.WorkItemTracking.Server.WorkItemChangedEvent in? In TFS 2008 it was in Microsoft.teamfoundation.WorkitemTracing.Server.WorkItemChangedEvent. In TFS 2010 it is in Microsoft.TeamFoundation.WorkitemTracking.server.DataAccessLayer.Dll.

Only option under File is New Team Project

2010-08-12T07:50:00.000-07:00

This is the second time i ran into this problem. I installed some flavor of VS. All of a sudden, when I go to the File menue, there is no longer the option to create a new project. There is only the option to create new team projects. And yes, I didn't just have Team Explorer installed. In this case, I had vs 2010 ultimate installed. So wtf? Turns out, if you select the project management profile when you first start up VS, it won't allow you to create new projects. What doesn't make sense is that I selected c# profile. Still, the solution is the same as if i did select the project management profile. Reset VS with this comand line command:

devenv.exe /resetuserdata

--a

TFS 2010 with Moss 2010 prompts to save for process guidance and all html pages

2010-07-13T11:04:00.000-07:00

Was running into this problem. TFS 2010 with MOSS 2010. Whenever i browsed to the process guidance or any html pages in the portal, i would get a prompt to save dialog. Turns out, this is a change in MOSS and their default security settings.

http://blogs.msdn.com/b/aaronbjork/archive/2010/02/15/being-prompted-to-save-your-process-guidance.aspx

in a nutshell, open sharepoint central admin, switch to web applications tab, then open general settings for the site you want to change, go to Browse File handling settings, change the setting from strict to permissive.

--a

configuring moss 2010 with tfs sharepoint 2010

2010-07-12T14:51:00.000-07:00

Took me forever to find a guide on how to configure sharepoint 2010 for tfs 2010. Try this:

http://blogs.msdn.com/b/team_foundation/archive/2010/03/06/configuring-sharepoint-server-2010-beta-for-dashboard-compatibility-with-tfs-2010-beta2-rc.aspx

TFS 2010 event refresh rate

2010-05-22T08:00:00.000-07:00

Out of the box, tfs 2010 batches events together and fires them every 2 minutes. To change this, you need to set the notification delay in the TF registry. Run this script using PowerShell. This will set the delay to 30 seconds. You can set it to zero to fire tfs events immediately.

[Reflection.Assembly]::Load("Microsoft.TeamFoundation.Client, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")

# Modify the TFS configuration server URL as necessary.

$configServer = new-object Microsoft.TeamFoundation.Client.TfsConfigurationServer "http://localhost:8080/tfs/"

# Get the TF registry service.

$tfsRegService = $configServer.GetService([Microsoft.TeamFoundation.Framework.Client.ITeamFoundationRegistry])

# Set the notification delay to 30 seconds. All collections will use this delay unless they override this value in the collection hive.

$tfsRegService.SetValue("/Service/Integration/Settings/NotificationJobDelay", 30)

Debugging Visual Studio Integration Packages

2009-09-18T10:29:00.001-07:00

Due to the nature of the company I work for, I've had to write a bunch of Visual Studio Integration Packages. So what's the easiest way to debug a VS Integration Package? Right click the project in the Solution Explorer and select Properties. This should bring up the Project configuration pane. Click the debug tab.

Start external program: \Common7\IDE\devenv.exe
Command line arguments: /ranu /rootsuffix Exp

I got sick of trying to google this every time I had to debug an integration package so here it is.

Create Team Project failure... and solution

2009-08-11T06:52:00.000-07:00

I just created a fresh install of TFS 2010 beta on a vm, tested everything out using the user account I used to install TFS and everything worked fine. However, when I logged in with a different user account who was a TFS admin as well as a local admin on the tfs machine (my user account), I couldn't create a new team project. Checking the error log, it said my user didn't have the correct SharePoint rights to create a new site.

Since I'm not very knowledgeable with SharePoint (at all), I added myself as a SharePoint farm administrator and added myself as a collection administrator. When I went back and tried to create a team project, it failed again with the same error. Did I mention I'm totally clueless when it comes to SharePoint? Anyway after futilely messing around with SharePoint for a while, I realized that all the team projects were children of the Default Collection site. Therefore, I had to give the user rights in DefaultCollection site. So I browsed to http://sites/DefaultCollection/default.aspx, clicked the Site Actions button in the upper right hand corner of the page and selected Site Settings. This brought up the Site Settings page for the DefaultCollection site. Under users and Permissions I clicked People and Groups and added myself as a user with full control. Just in case, I also added myself as a Site collection administrator.

Going back to Team Explorer, I tried to create a new team project. This time, the creation process went further than before, but it again failed. The error log looked like this:

Module: WSS
Exception Type: Microsoft.TeamFoundation.TeamFoundationServerUnauthorizedException
Exception Message: TF30063: You are not authorized to access http://:17012/_vti_bin/TeamFoundationIntegrationService.asmx.
Stack Trace:
at Microsoft.TeamFoundation.Client.TeamFoundationClientProxyBase.ProcessHttpResponse(HttpWebResponse response, Stream responseStream, WebException webException, XmlReader& xmlResponseReader)
at Microsoft.TeamFoundation.Client.TeamFoundationClientProxyBase.ExecWebServiceRequest(HttpWebRequest request, XmlWriter requestXml, String methodName, HttpWebResponse& response)
at Microsoft.TeamFoundation.Client.SharePoint.SharePointTeamFoundationIntegrationService.ActivateFeatureById(String siteUrl, Guid featureId)
at Microsoft.VisualStudio.TeamFoundation.WssSiteCreator.HandleFeatureActivation(WssCreationContextWrapper contextWrapper, XmlNode features)
-- Inner Exception --
Exception Type: System.Net.WebException
Exception Message: The remote server returned an error: (401) Unauthorized.
WebException: Response Status Code: Unauthorized
WebException: Response already disposed, no additional information available.
WebException: Status : ProtocolError
Stack Trace:
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.TeamFoundation.Client.TeamFoundationClientProxyBase.AsyncWebRequest.ExecRequest(Object obj)
-- end Inner Exception --
--- end Exception entry ---

Apparently, I needed to add my user account to the web application policies. To do this, bring up the SharePoint Central Administration, go to the tab marked Application Management and click the link Policy for Web Application under Application Security. From here, add the users who will create team projects.

Problem solved.

VS 2010 beta1, TFS 2010 beta 1 Installation Adventures

2009-08-08T10:46:00.000-07:00

Last week, I was asked to create a bunch of VMware development/demo vm's for the company I work for. These vm's needed to have the following software installed: windows server 2008 sp2, vs2010 beta1, tfs 2010 beta, and office 2007 sp2. Even though I've never worked with VMware before or done a TFS2010 install, I figured this would be cake. I mean, I'm a fricken trained professional!!! What could possibly go wrong? Heh heh heh.

First, I created a windows server 2008 sp2 image without any problems. Installed visual studio 2010 beta1 without any problems. Cool. So far so good. First impressions of VMware are positive. Performance is good. Next comes the TFS 2010 beta install. Glancing through the install guide, it looked pretty straight forward for a simple one server deployment. First up, install SQLServer 2008 with the following features: Database Engine Services, Full-Text Search, Analysis Services, Reporting services, Client Tool Connectivity, and Management Tools - Basic. Everything installed just fine except for the Full Text Search feature. That one had a red "x" next to it.

After trying for a long time to get the Full Text Search feature installed, I noticed that I now couldn't install anything on the server because an installation was already in place. Whaaaaaat??? Looking in the Task Manager, yup, there were two Windows Installer processes running (msiexec.exe). And one of them was eating up most of my CPU! Since at this time there should have been no installations going on, I figured maybe I just needed to reboot. Nope, that didn't work either. After rebooting, the two Windows Installer processes were still there with one of them using most of my CPU. Next, I tried killing the process. That didn't work either. After killing the 2 msiexec.exe processes, they would come back in about two seconds. Ok I thought, I'll just go in and manually turn off the windows installer service. That didn't work either. The stop button on the windows installer service was greyed out. Great! So now, I have a server with two random msiexec.exe processes running all the time, which prevented me from installing anything else on the server. And to add insult to injury, one of the msiexec.exe processes was maxing out my CPU!!! No amount of rebooting would fix this.

Anyway, to make a long story short, after spending ridiculous amounts of time trying to figure out what was wrong, I fixed this by reverting my vm back to a snapshot of just windows server 2008 with sp2. Then instead of installing vs2010 beta 1 first, and then SQL Server 2008, I installed SQL Server 2008 first. Everything installed fine. Then I installed the rest of the pieces of TFS without any problems and last, I installed Visual Studio 2010 beta 1. The rest of the installation went very easily without any hiccups.

So the moral of this story, if you need to have VS 2010 beta 1 and SQL Server 2008 with the Full Text Search feature, install SQL Server 2008 first, and then install Visual Studio 2010 beta 1.

Branching and Merging Strategies (part 2 of 3)

2009-07-05T12:43:00.000-07:00

Last blog, I talked about a simple branching strategy. Today, I'll tackle a slightly more complex scenario. A while ago, I ran into a client (small group) that already released a version of their application into the field. Things were running smoothly for a couple of weeks, developers were busy working in the DEV branch on the next version release. Suddenly, a major bug in the release was found and they needed to apply a patch to the deployed application. In other words, they needed to create a hotfix for a released version.

Here is a branching strategy I like to use for hot fix scenarios. First, I would still have a MAIN branch which holds the latest stable version of the code. From MAIN, I would branch to DEV. This is the branch developers use to work on the latest and greatest (next version). Like the simple branching scenario, changes are merged to the main branch where QA performs their tests. When the code is feature complete and the quality is acceptable for a version release (v 1.1, v1.2 etc), I would branch from MAIN to a hot fix branch, and then branch from the hot fix branch to a V1.1.0 branch for archival purposes. I do this whether I need a hot fix or not. I do this just in case I will need to write a hot fix.

Inevitably, I get someone asking me, "Why do that? Isn't it expensive to branch". The answer is no. If you use TFS as your source control, branching is actually very cheap. TFS only stores the differences (and some meta data for each branch). TFS handles branching very efficiently. Granted, what shows up on your hard drive (if you map your workspace to all the branches) will be copies of the code, but what is stored in TFS is just the differences.

So now, features for the next version are being worked on in the DEV branch. If you need a hot fix, make the changes in the hot fix branch. When the hot fix is finished, branch from the hot fix to another archive branch. If you need to bring the hot fix changes to the current (next version) code base, merge your changes from the hot fix branch to the MAIN branch. Take care of potential merge conflicts as well as potential code breakage here, and when finished, merge the changes from MAIN into DEV.

Here is how I would lay out the code in source control/file structure:

$/Project/
$/Project/Main
$/Project/Main/(Source code for application)
$/Project/Development
$/Project/Development/(Source code for application)
$/Project/Production
$/Project/Production/V1.0
$/Project/Production/V1.0/Hotfix
$/Project/Production/V1.0/Hotfix/(Source code for application)
$/Project/Production/V1.0/V1.0.0
$/Project/Production/V1.0/V1.0.0/(Source code for application)
$/Project/Production/V1.0/V1.0.1
$/Project/Production/V1.0/V1.0.1/(Source code for application)
$/Project/Production/V1.1
$/Project/Production/V1.1/Hotfix
$/Project/Production/V1.1/Hotfix/(Source code for application)
$/Project/Production/V1.1/V1.1.0
$/Project/Production/V1.1/V1.1.0/(Source code for application)
$/Project/Production/V1.1/V1.1.1
$/Project/Production/V1.0/V1.1.1/(Source code for application)

There are circumstances where you might need to have the ability to roll up hot fixes into service packs. If you know you will need to roll up hot fixes into service packs, then you would use the same branching structure, except when it's time to branch for production, you branch MAIN to SERVICEPACK, immediately, from SERVICEPACK to HOTFIX, and from HOTFIX to an V1.0.0 SP 0 archive (read only) branch. If hot fixes need to be done, developers work in the hot fix branch. Changes are merged back to the SP branch, and from the SP branch, back to main, where code breaks and merge conflicts are fixed, and then the changes are merged to DEV. Service Pack specific code is done in the SP branch, and when it's time to release a service patch, you would branch from the SP branch, to a HOTFIX branch, and from the HOTFIX branch, to a read only V1.0.0 SP 1 archive branch.

As you can see, this will greatly increase the complexity. However, if you need to support a released application with hot fixes, actively work on a cumulative service pack that includes all approved hot fixes, and you need to be concurrently working on the next major release, then this branching strategy will accommodate and facilitate an organized and planned migration path for all features which minimize the chances of merge conflicts and code breakage.

Enough on branching for now... next time, support for multi-feature/multi-team development!!

Badges? We don't need no stinking badges

2009-07-03T15:08:00.000-07:00

I remember when I was in my late teens and early 20's, I acrued a fine collection of hair nets and name tags from the thousands of dead end jobs I have had. Today, as a consultant in the IT world, I have started up an equally impressive collection of security badges which gain me access to client sites. Nothing can beat the high tech badge I'm required to wear at my latest client!

Branching and Merging Strategies (part 1 of 3)

2009-07-03T11:50:00.000-07:00

In my last 3 engagements, I've been asked to help my clients with creating a branching and merging plan using code promotion for release management. Since I'm not at a client site today, I figured it was a good time to actually put down my thoughts on branching and merging strategies.

First off, before I begin, I would like to add a word of caution. Any time you branch, you add a significant layer of complexity. In TFS, it's extremely easy to create a branch. You just right click a folder and select branch. However, to maintain the branches, the additional testing required, and resolving the potential merge conflicts between branches does add complexity (and not just a little). The pain of the additional work required with branching need to be far less than the pain of not having the branches. In other words, don't branch unless you really need to.

So when do you really need branching? Actually, this is an easy question to answer. If developers start doing weird things to work around restrictive check-in policies, it's a good sign that an official branching strategy needs to be implemented. For instance, if there is a code freeze on the main branch for V1.0 and developers are creating copies where they can continue working on V1.1 changes, that's a good sign that you need branches. If your developers can't check in their code, they have to shelve their code because their check-ins are going to drastically affect everybody else, which would freeze development, that's a good sign a branching strategy needs to be implemented. If a developer refuses to do a get latest, just works in his own little world, and when he's finally finished, he checks in his code (which results in a hellish couple of days trying to integrate his code back with everyone else's), that's a good sign you need a branching strategy! In a nutshell, if developers don't have the branches they need in source control, they WILL create them on their hard drive. So if you catch your developers creating ad hoc, unofficial branches on their hard drive, it is definitely time to create a branching strategy!!!

In Abel's World, I use 3 different branching strategies. A simple branching strategy. A branching strategy used to support hot fixes (and service packs), and a multi-team/multi feature branching strategy. We'll start with simplest.

A common scenario I see is that a software shop starts off extremely small. One or two developers, long development cycles, and infrequent releases. Since it's just a couple of guys coding like mad men, they have no need for a branching strategy. They are all coding off of a single branch. And for a small shop like this, it works just fine. Inevitably, things start to change and grow. More developers are added, releases come a little quicker and problems and bottlenecks start occurring.

One problem often encontered is developers check in code which haven't been adequately tested. Another common problem is that the code base becomes EXTREMELY volatile right before a release. This makes QA-ing the application, or even figuring out what is going to be released extremely difficult. To alleviate this problem, the team implements a code freeze where developers are not allowed to make code changes. These code freezes might start out as just half an hour, but they soon turn into longer and longer periods of time where developers are not allowed to make changes to the source.

In a situation like this, a simple branching strategy can be used. I take the MAIN branch where developers are currently working, and from there, I branch to a DEV branch. Now, all the developers will do their work in the DEV branch.

As time goes by and DEV becomes closer and closer to feature complete, they need to merge the changes over to MAIN, where the QA finds bugs. Developers continue working in the dev branch, fixing bugs, working on new features, merging those changes over to MAIN until QA determines that it is feature complete and the quality is good. At that time, you create a branch from MAIN to have an archived copy of what the source code looks like for the version release.

I like keeping my MAIN branch as stable as possible. I try not to merge code from DEV to MAIN until the code in DEV reaches a certain level of quality, and is believed to be ready for production. I then merge those changes to MAIN where QA bangs on it and gives it their blessing. I also like having a CI-Build running on the DEV branch, and a Nightly build running on the MAIN branch. This way, developers checking in code will quickly realize if they are breaking the build in the DEV branch, while the nightly builds in the MAIN branch is a nice sanity check to make sure everything compiles and passes unit tests and BVT's.

So the above demonstrates how the code branches, but this is different than how I want to lay the branches out on my hard drive (or in source control). I want to be able to take one look at my hard drive, or source control and know exactly where I am. Here is how I would lay out the source control:

$/ProjectX/Main
$/ProjectX/Main/(all the files and folders for the application)
$/ProjectX/Development
$/ProjectX/Development/(all the files and folders for the application)
$/ProjectX/Production
$/ProjectX/Production/V1.0
$/ProjectX/Production/V1.0/(all the files and folders for the application)
$/ProjectX/Production/V1.1
$/ProjectX/Production/V1.1/(all the files and folders for the application)

Now before I finish this section, I would like to address a question a good friend and colleague asked me. "Why do you branch from Main to Dev, why not use the original branch as the DEV branch and branch to a new branch and call that QA or MAIN? Or if I'm just starting the project, why do you create a MAIN branch first, and branch to DEV?" The reason is because I want to keep a consistent forward merge and reverse merge pattern. Also, branching like this allows for a seamless integration into future branching/merging patterns. Future branching patterns will not have to use baseless merges. More on that next time.

For my next blog installment, I will talk about a slightly more complex branching scenario. Branching for the ability of hot fixes, or even hot fixes and service packs.

--a

Introduction

2009-07-01T17:52:00.000-07:00

Hi there,

My name is Abel and I'm a process consultant for Notion Solutions. What I do is write software. And I'm VERY good at it. What I do for fun is music. And guess what? Yup, I'm also VERY good at that! Hahaha. Kidding

Anyway, I've been thinking about starting up a blog for quite some time now. Because of my work, I'm often thrown into different clients with different problems to solve. Because of my incredibly bad short term memory, it seems that often times, I'm figuring out how to solve the same type of problems. Frantically googling, trying to find answers to solutions I know I've solved before. So why not have my solutions in one easily searchable location!!!!! Why not start a blog?

This thought has been on my mind for quite some time now but I've never been motivated enough to actually start one. However, my current engagement has definitely given me the motivation! It has been a frustrating engagement with plenty of "are you serious!!!" moments that only a consultant would know. Along with those moments have been times where I know I've solved a problem that I'm seing before, but I can't remember how I did it. This happeneed enough times that yeah, I finally decided that today will be the day that I start writing down all of my solutions in this blog.

So... with no further delay, the next couple of days, I will blog about
1) branching and merging strategies with release management done through code promotion
2) simple command line TFS commands that I need to use often enough that i wish I had them memorized, but not enough that I actually have them memorized (think, delete team projects, import/export tfs project templates, changing the password to the service accounts in tfs... things like that).
3) Writing custom controls for team foundation server's web interface
4) Customizing team builds
5) How to use the testing tools inside of visual studio team suite.

That's all for today,

--a