IE8 RC1 finally able to access certificates on an E-ID card

Ever since this morning, even before I noticed my friday afternoon problem went away by itself over the weekend, I’ve been feeling a little bold. Maybe you yourself are familiar with the feeling of being invincible, on a roll, miles ahead of the hurd…

Anyways,  feeling the way I did, I decided it was time to re-install Internet Explorer 8 and give it another go. Maybe this time everything would work out for me.

You have to know that a while ago I installed IE8 Beta 1 followed by Beta2. And to be honest, aside of the fact I had some minor ‘drawing’ problems on some occasions and google having trouble showing results when searching for stuff, it seemed to do the job just fine.

That is, untill I recently tried to use my Belgian e-ID card and authenticate myself to the website where one can fill in his tax report. It was just then that I noticed that although my certificates were registered and available when looking at them in Tools > Internet Options > Content > Certificates, IE8 (up to Beta2) did not show them in the popup box which should list the certificate and let you pick it. The popup box just stayed empty.

Because I really wanted to use my e-ID card to authenticate myself I decided to go back to IE7 as I was sure it worked before upgrading to Microsoft’s Latest and Greatest. And indeed, after downgrading everything worked just fine once again.

So feeling the way I felt today, I was convinced reinstalling IE8 (using RC1) would give me the advantage of both enjoying this new version and still be able to use my e-ID card.  You know what, IT DID!  I like to think it was due to the fact of me being so great but it could as well be that Microsoft fixed one of the bugs left in the beta versions….

Unable to check out files after using tf destroy

Last friday I decided it was time to clean up some deleted artifiacts in our source code repository. As you might know, deleting files in source control doesn’t really delete them from the repository but just marks them as being deleted. Since some time, however, the tf.exe command line tool allows you to actually remove (or destroy) artifacts from the repository.

I first made an inventory of all artifacts that I wanted to remove from the repository and afterwards started doing just that… To make sure I didn’t mess up I followed the same procedure for all of them:

tf dir xxxx /deleted (where xxxx is the path you want to query, e.g. “tf dir $/ /deleted” to query the root)

As a response you get an overview of all artifacts (folders or files) in the path you specified

E.g.

$/TeamProject1

$/TeamProject2;X999

If an artifact shows up with a semi column and a number at the back, it means this artifact has been deleted from source control but still exists in the repository. If you want you could restore this artifact and make it visible again. Because I wanted to remove them I then issued the “tf  destroy” command for these artifacts.

E.g.

tf /preview destroy $/TeamProject2;X999

Which gives you an idea on which artifacts will be destroyed when execting the same command without the /preview option. If you feel comfortable with the artifacts it says it will destroy you can go ahead and re-issue the same command without the /preview option.

E.g.

tf destroy $/TeamProject2;X999

All went well for a while until I got a phone call from some of the developers telling me that they couldn’t check out files anymore. I was certain I didn’t mess up and accidentally deleted files because I never destroyed any files without a semi column and number at the end. So what went wrong?

Lets say the Team Project having issues was called MyCompany.TeamProject, the root source control folder would then be called $/MyCompany.TeamProject. We could still see this folder and the artifacts it contained could still be queried, a get latest or specific worked and getting version info for these artifacts also didn’t pose any problems. But when trying to check out a file we got the following error:

TF10175: The team project folder $/MyCompany.TeamProject does not exist. Contact your Team Foundation Server administrator and ask that it be created

So although the folder was still there, Team Foundation Server seemed to have lost the link between the Team Project and it’s root source control folder.

Now you have to know that before we created the team project called MyCompany.TeamProject,  a team project called MyCompany.TeamPROJECT existed but was deleted because of incorrect casing in the name. Because this team project also had a root folder called $/MyCompany.TeamPROJECT, this got deleted (but not destroyed) at the same time we removed the wrongly named team project. So when issuing the command tf dir /deleted we actually got two folders with the same name (if you don’t take into account the casing). e.g.

$/MyCompany.TeamProject

$/MyCompany.TeamPROJECT;X1234

 Because the one with the deletion id in the back never contained any artifacts, we assumed it was safe to delete it. Little did we know that the tfs destroy command would mess up and in some way remove the link between the team project and the correctly and still existing team project root in source control.

This case has been filed with Microsoft Support and as soon as I get a solution or the less fortunate reply that there isn’t one, I will let you know. In the mean time we will probably branch (still works) to another team project and merge back when it’s fixed.

Update: Arrived @ work on monday to find that the problem went away by itself. Apparently the warehouse needed an update before it (automagically) re-established the link between the Team Project and the folder in source control. My thx go out to Nitish @ Microsoft Support for reproducing this on one of his virtual machines over weekend and who confirms the warehouse update does the trick.

Visual Studio 2008 RTM available on MSDN

As of this morning VS2008 Team Suite can be downloaded from the MSDN website 🙂

Downloading the bits right now…

Missing Feature in TFS Project Templates

While reading this post from Willy-Peter Schaub it crossed my mind that I forgot to post about a feature I think is missing in Team System Project Templates.

I recently tailored the Project Template from Conchango to serve as our ‘standard approach’ for each Team Project we create. After some fiddling around I got everything the way we wanted except for the creation of a couple of folders in source control. Apparently there is no way of doing this automatically so we ended up doing this manually each and every time. Willy-Peter’s blog shows that we are not the only ones handling it this way. If you ask me, the Team System guys really missed out on this one…

TechEd 2007 – Barcelona here I come (maybe)

I’ve been to TechEd the past two years, once to Rotterdam and once to Barcelona. And I must admit I liked it very much on both occasions. Good technical content and the ability to talk to several MVP’s and Microsoft employees made this so much interesting than attending e.g. DevDays. So I was looking forward to attend TechEd this year too. I suppose it came as no surprise at all that Murphy showed up and only one team member was allowed to go while two applied for the trip.

And then, out of the blue, when I least expected it, Microsoft Belux offered a free ticket leaving only travel and expenses to be paid by my employer. So today I filed my request once again, hoping my manager will approve it this time. Only time will tell… Thx for offering Microsoft Belux!

Update 4/9/07

mission accomplished, cya in barca

Scrum Eventing Service woes (continued)

After receiving a response to my question on the Scrum for Team System Forum I investigated our problems somewhat further and noticed we were still running the Eventing Service from version 1.1, although I was convinced we did the upgrade to 1.2 as soon as it became available. Obviously I thought this was the very thing causing all this trouble.

As stated before in my previous post we recently moved the Eventing Service to its own Application Pool. We did this to make sure it wouldn’t crash our TFS server any more. When we tried to do the same thing with version 1.2 it no longer worked and Event Viewer showed this message: “GC handle cannot be shared among different application domains”. So we moved it back to the Application Pool belonging to TFS itself. The first couple of hours everything seemed just fine. The next morning however we had to recycle the Application Pool once again. I decided to stop the Eventing Service right there and then.

The next day I wrote a Windows Service which is currently running on our Continuous Integration Server and updates all Product Backlog Items once an hour by running the ScrumConsistencyChecker for every Scrum Project hosted on the TFS Server. It manages to do this in about 15 minutes for the 20 projects we currently host and this without any impact on the TFS Server. Which is, by the way, running just fine without the Eventing Service and hasn’t required any recycling since.

Scrum Eventing Service woes

In some previous posts, e.g. this one, I talked about performance problems we were having with our TFS server. After upgrading the server everything seemed to be a lot better but because we experienced two more hiccups we decided to move the Scrum Eventing Service (part of Scrum for Team System by Conchango) out of the TFS application pool. The primary reason we did this was to make sure that if we had to send dumps of the TFS process to Microsoft it would not be cluttered by stuff that didn’t belong to Microsoft in the first place.

Maybe it’s a coincidence but since we moved the Eventing Service into a dedicated application pool TFS is behaving just fine. The Eventing Service on the other hand is timing out a lot and fails to update the remaining workload most of the time. Sometimes the Eventing Service takes up to 50% of CPU while, on first sight, it has almost nothing to do. Since we have no idea what is going (wr)on(g) we might decide to either update remaining workload at pre-defined intervals or (worst case scenario) move away from Scrum for Team System. A cry for help on the forum has returned nothing else but radio silence.

Since we want to stay with Scrum as such, this means we will have to evaluate other offerings like this, or this, or build a Process Template from scratch ourselves. I had a quick look at eScrum from Microsoft itself and I must say I was impressed about what they have to offer. They included a lot of stuff which would be deemed overhead and !Scrum by Scrum purists but really is a must when practicing Scrum in an enterprise context.

Adding users to TFS from the extranet

It came to our attention today that colleagues located in our offices in Chennai are unable to add people to the security groups in TFS. The problem is that the people working in India live on a different domain than the people in Belgium. TFS currently requires all its components to reside in the same domain. As you can see in the picture below TFS, the build servers and the proxies are all configured in the same domain. The proxy servers are, opposite to TFS and the build servers, physically located in Chennai. The obvious reason for this is that you want to have the proxy server on the remote side of the leased line if you want to keep traffic low.

So while the TFS infrastructure resides on the DOM001 domain, people in India are logged on to the DOM002 domain. We do have Domain Trust enabled between the two and they are able to connect to both TFS and Build Servers from the remote location. They do have to specify DOM001 domain user credentials each time they log on to the TFS Server but that’s just because they use different user names & passwords on the DOM002 domain. If these were the same, Windows would just pass user credentials without passing in the domain and they wouldn’t even have to do that. No problem so far.

So if everything works fine this way, why can’t they just add users to e.g. a Contributor security group in TFS?

The problem is that Team Explorer is trying to validate the users they specify against the domain in Chennai in which, of course, they do not exist. For one reason or the other they cannot specify that it has to validate against the DOM001 domain. We didn’t investigate any further because by the end of this year the Chennai domain will cease to exist and we will all be happy campers residing in DOM001. In the mean while we will fall back to plan B and have somebody in Belgium add the users for the teams in India.

Too bad we can’t outsource this ;)….

 Update

Check out the comment from Stefan Venken, turns out we can outsource this afterall 🙂

Using the TFSSecurity.exe tool found in the tools directory of the Team Foundation Server installation one can add users from the command line. Stefan found out about this over here…

TFS 2008 and the MoSCoW method

Last week I read this post from Brian Harry listing all the goodies that made it into the TFS 2008 feature list. I thought it would be a good idea to just make a shameless copy (sorry Brain) of this list and see how it held up against our needs and wishes using the MoSCoW method (just because one of my colleagues is a great fan of this). Keep in mind that everything in this list will be available by the end of this year if all goes well, the MoSCoW categories just reflect the items in the list we are going to use and the ones we are not. So here goes:

Must Haves

Administration, Operations & Setup

• Share Point 2007 support
• Official testing and support for more configurations – This includes clustering, mirroring, log shipping, Virtual machine deployment, and more.
• Upgrade from TFS 2005
• TFSDeleteProject now permanently deletes (destroys) version control content (new) (RTM)

Build (more detail)

• Support multi-threaded builds with the new MSBuild.
• Continuous Integration – There are many components to this, including build queuing and queue management, drop management (so that users can set policies for when builds should be automatically deleted), and build triggers that allows configuration of exactly how when CI builds should be triggered, for example – every checkin, rolling build (completion of one build starts the next), etc.
• Improved ability to specify what source, versions of source, and other build properties.
• Improved extensibility of the build targets – such as ability to easily execute targets before and after each solution/project is built.
• Stop and delete builds from within VS.
• Simplified ability to specify what tests get run as part of a build.
• The ability to store build definitions anywhere in the version control hierarchy.
• Scheduled builds – You can schedule builds to happen at specified times.
• Improved build agent communication – We replaced .NET binary remoting with WCF web services, simplifying some configuration and security aspects.
• New checkin policy for broken CI builds – Preventing checkin while the CI build is broken.
• Support for HTTPS communication to the TFS server (new)
• Continuous Integration build checkin policy (new)
• Support for incremental gets and builds (new)

Version Control

• Destroy – The ability to permanently delete version control files/folders from TFS. It can also be used to destroy the file contents while preserving the change set history.
• Get Latest On Checkout – There have been many requests for this feature (which was a change in behavior from SourceSafe). There is now an option that allows you to specify that you want TFS to download the latest version of files when you check them out.
• Merge improvements (new) – Improved the logic that detects merge conflicts to generate fewer false positives and handle more scenarios.

Web Access

• Adding Web Access UI to TFS – As you’ve seen many places, we acquired devBiz and their TeamPlain Web Access product. We are releasing it as a Power Tool in the next few months and plan to release it as an official product in the Orcas timeframe. We have not figured out how the release date will line up with the Orcas date but it will be in the same general timeframe.

Bug fixes

• In addition to all of the feature work, we’ve spent months testing the product and fixing any bugs we’ve found. We expect Orcas will have even better stability and robustness than TFS 2005.

Should Haves

Administration, Operations & Setup

• New role for many operations activities (new) (RTM) – You don’t have to be server administrator to run many of the admin utilities any longer.
  
• Enhancements to tfsadminutil (new) (RTM) – New capability to configure accounts, connections, etc on both TFS and the TFS proxy.
  

Build (more detail)

• Improved ability to manage multiple build machines.
• .NET Object model for programming against the build server.
• Ability to run GUI tests as part of a build – Automated builds used to run tests in such a way as to prevent access to a GUI desktop.

Data Warehouse

• Add support for checkin policy overrides to the warehouse – an oversight from V1.

Version Control

• Annotate – This is based on the TFS Annotate Power Tool but includes numerous improvements.
• Folder Diff – Also based on the TFS Tree Diff Power Tool with numerous improvements.
• Workspace improvements – Workspaces will now support mapping a folder or file under a cloaked folder and wildcard mappings so that you can map all files in a folder without mapping sub folders. Based on experience with large projects, this will simplify workspace definitions for many people.
• Performance improvements – A variety of Version Control performance enhancements that will improve virtually all aspects of version control performance. The gains for smaller servers/projects (< 10,000 files) will be modest. The gains for larger projects (particularly where the file count approaches 100,000’s) will be substantial.
• Scale improvements – Fixed out of memory problems on the server when operating on more than a few hundred thousand files at a time.
• Offline improvements – We’ve signficantly improved the experience going offline and integrated the tfpt online capability into the IDE for going back online.
• Extranet support for the TFS Proxy – allowing you to access a local TFS proxy with a different set of credentials than the TFS server.
• Command line help – You can now type “tf command /help” and get a console dump of the usage of that command. This is much more convenient than always being launched into the richer GUI hypertext help when you just want to remember what the options for a command are. You can still launch the GUI help by running “tf msdn”. You can get a console dump of available commands by just typing “tf help”.
• Source Control Explorer refresh improvements – This includes less redrawing and reloading but even more important it enables updates based on changes made in other instances of TeamExploror or the command line. That’s right, if you checkout a file from the command line, any instances of TeamExplorer you have running on the same machine will automatically refresh.
• Async loading of the Source Control Explorer (new)
• The SCE local path can now be selected and copied (new)

Could Haves

Administration, Operations & Setup

• Support for MOSS 2007
• Simplify installation – In Orcas, we will be doing a variety of things to attempt to make installing TFS easier and quicker than it is now. Improvements include eliminating the separate data-tier installation, simplifying the requirements around required domain accounts by supporting the built in machine accounts (like Network Service) where we can, etc.
• Support for client certificates

Migration

• Migration toolkit – A toolkit for building conversion and mirroring solutions between TFS and other systems. In addition, we will release one or more new tools to integrate with popular alternative systems.

Work Item Tracking

• Performance & Scale improvements – A variety of improvements that will make both the work item server and client faster and able to handle larger servers.
• Query builder usability improvements – Drop down filtering based on current project, better MRU lists, column drag & drop, shift-click mouse based multi-column sorting, etc.
• Attachments improvements – Save button, drag & drop for adding an attachment, multi-select for attaching files.
• Tooltips on field names contain the field name used for querying
• Server side support for deleting work items & work item types – We didn’t have time to do client UI support for it but we plan to release a Power Tool that will take advantage of the new server side feature.
• Support for security on the iteration hierarchy (new)

Would Haves

Administration, Operations & Setup

• Enable use of Sharepoint on any server and any port
• Enable support for Reporting Services on any server and any port
• Support for SQL Named Instances – This will allow customers to share a SQL server between multiple TFS instances, or with other applications. This has been a commonly requested feature by enterprises.
• “Longhorn” server support – TFS will support the next version of the server (and corresponding new version of IIS) that is currently under development.
• Sync Large Groups – This is a set of work to improve the performance and robustness of TFS’s handling large groups of users (~30,000 or more) granted permission to a TFS instance. Today this can result in a support call to recover from it.
• Non-default ports – We’ve gotten a bunch of feedback from enterprise customers about TFS’s limited support for alternate web sites and ports running afoul of data center policies. We are going to be improving TFS’s configurability in this respect in Orcas.
• Support for SQL 2008 (aka Katmai) (new) (RTM)

As you can see I am a pretty happy guy if they deliver on this…

Planning Team Projects

When starting to work with Team System, one inevitably gets confronted with a lot of self posed questions about how to structure or organize Team Projects. While there was little or no information about this available at the launch of Team System, Microsoft put up some information on how to ‘Plan a Team Project’ after a while. They state that four categories of questions should lead you to the best way to organize your Team Projects, categories are:

• Questions about the Current Team Project and Your Future Work
• Questions about the Capacity and Performance of the Team Foundation Server
• Questions about the Structure or Hierarchy for Organizing the Team Project
• Questions about the Preferred Software Development Process

This is all great information but in the end you will have to decide for yourself if the choice you get by following this guidance is the exact solution you wanted or expected to have (or not). For us it was not… The main reason for this is that we are organized in a very specific way; now I know you were afraid of this from the start, but let me elaborate.

Projects versus Maintenance

Basically our shop is divided into two groups. We’ve got people belonging to the Projects Group and others belonging to the Maintenance Group. I think it’s pretty obvious and self explanatory what these teams do, but still, I’ll tell you J

The Projects Group

• Is divided into several project teams
• executes each and every new project
• lives on short term assignments (project scope)
• uses latest version of framework, etc…
• task management & reporting related to one specific project

The Maintenance Group

• does maintenance on each and every project delivered by the Projects Group
• lives on longer term assignments
• maintains projects built on different versions of the framework
• task management & reporting related to monthly delivery milestones

At this very moment we’ve got 4 different projects running, all staffed by members of the Project Group, the Maintenance Group currently has more than 50 applications in maintenance. So we had to look at the situation not only in two different ways but also had to cater for the scenario in which projects move from a project phase to a maintenance phase. And keep in mind this move means handing it all (software, documentation, …) over to a different set of people.

Projects

What we feel is important for projects is that we:

• can assign a limited set of people (team members) to a certain project
• are not bound to one and only one Project Template which is not upgradable at all
• are able to report easily on one specific project
• do not have to follow the same pace in terms of iteration and/or release dates

So in our scenario each new Project we start gets its own Team Project created with the latest version of the Project Template. This way we are not long term bound to one specific Project Template. Our early Team Projects were based upon the MSF for Agile Project Template after which we moved to the Scrum for Team System Project Template from Conchango and finally ended up with a customized version of the latter. Some of you might think ‘well ok, but isn’t there a certain limit in the amount of Team Projects one is able to create in Team Foundation Server’. The answer would be ‘Yes, there is, but read on…’

Maintenance

What we feel is important for maintenance is that we:

• can assign a group of people (team members) to a maintain all projects
• can use one type of Team Project for all projects
• are able to report easily on all projects
• can follow the same pace in terms of iteration and/or release dates

To accomplish this we just created one Team Project for the Maintenance group, each project that enters maintenance phase is then moved to the Maintenance Team Project. We made this very easy by organizing our source control folders in an organized way. In the root folder of a new Team Project we create a sub folder stating the name of the project and all other artifacts are to be stored beneath it. This was we can easily move that folder to another team project, taking all what’s in it, with it. Once the move is complete, we remove the Team Project itself, which keeps us far away from the capacity induced limit of (worst case) 250 Team Projects.

There are some back draws to this but we can live with them:

• While change sets are preserved, work items are not. So you will still be able to see who f*cked up but not which task he linked that specific change to.
• Moving stuff away from one Sharepoint site to another is not that simple. The fact that it isn’t simple does force you to think about the nature of the documentation being short term, midterm or long term;
• We have to modify the Build Types when moving them to the Maintenance Team Project*
• Only one Build Type for the same project can run at the same time*

(*) nothing that a new version can’t fix 🙂

Ok, that’s about it for now, if I left something out feel free leave a comment and I will try to answer as soon as possible…