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.