"Culture name 'en-securid' is not supported. Parameter name: name"

A user in England was getting the error "Culture name 'en-securid' is not supported. Parameter name: name" when accessing Team System Web Access 1.0. I asked Google and Live. No luck.

I then started to dig. In IE if you click Tools > Internet Options > Languages.. you'll see the Language Preference dialog. The user with the issue only had "User Defined [en-securid]" listed. They added "English (United States) [en-us]" right below "User Defined [en-securid]", but still got the error. We then had them Move Up "English (United States) [en-us]" to the top value, click Ok > Ok and the error was resolved.

If you run into a similar error, give this a shot and let me know how it goes.

"Application Not Found" in Team Explorer

A user in my group was getting "Application Not Found" when clicking on any attachment using the Team Explorer in Visual Studio 2005. The error was fixed when we (actually Desktop Support) changed the user's default browser from Firefox to Internet Explorer.

Because I'm curious, I changed my default browser to Firefox but was unable to repeat the error on my machine. I got a prompt from Firefox asking me what program to open the file with. My guess is, the user's Firefox settings are a bit off.

Anyway if you do get "Application Not Found", you may want to see what the default browser is and see if changing it to IE will fix it.

In other news, another person blamed firewall settings. You can find that potential solution here.

How to implement check in policies

We met with Teamprise this morning to discuss check in policies. One of the larger business units in the company has a long list of policies they'd like to see. Including, but not limited to, Work Item Association, Comment Association, Forbidden Pattern Policy and a Are You Breathing Policy. We (a smaller business unit) on the other hand, are only looking for the first one, Work Item Association.

If you're coming from a tool that has never enforced check in policies before (like we are with VSS) here is my suggestion for how to best implement them. Keep things simple and follow the three step process I've laid out below.

Step 1) Don't implement any policy right away. That is, try to mimic your current source control workflow in TFS. If users could check in and out at will, then let them. This non-intrusive approach allows end users to get comfortable with the new tool, by using a common approach they're accustom to. Remember, change is hard for people.

Step 2) Start with one policy and one policy only. I'd suggest all user bases start with Work Item Association. Asking the user to simply select what piece of paperwork (e.g. Task or Bug) the code was addressing, is an innocuous approach to improving your processes. Remember, change is hard for people so don't Big Bang them. Lull them into a better place like you do when boiling a frog (not that I've ever tried that...).

Step 3) Don't get crazy. That is, don't feel like you have to implement every single check in policy known to man. Engineers are smart, that's why we're engineers for goodness sake. Assume that you don't need a check in policy to verify that we got morning coffee. We all know how to get morning coffee. A tool does not need to tell us so.

By following this three step process, you'll find a more accepting user base and a better TFS/Teamprise implementation.

Accessing TFS from Windows Explorer with "Dubbelbock TFS"

When the big wig at IBM came in to show off ClearCase, he waved in my face the ability to interface with ClearCase by Right Clicking on a file in Windows Explorer, and then seeing the Source Control features at the tip of my proverbial fingers. While I didn't ever think I'd use it, I did find it an interesting feature. Personally, I like to interact with Source Control in my IDE only, but obviously others differ.

Anyway to my point. A fellow blogger, who happens to work at the same company but uses a separate TFS instance, found a tool called "Dubbelbock TFS" that allows just this. I don’t think I'll ever use it, but I did find it a nice example of how easy it is to extent TFS and how many small little projects are out there to improve developer efficiency.

Lastly just a note on my game theory analysis. I see ClearCase as a direct competitor of TFS. Since ClearCase has this Right Click in Windows Explorer functionality, I'm thinking MS might want to add it, even though I don't think users like me will ever use it. Reason being; when all the vendors show up on your door knocking they like to tout all the neat bells and whistles centered around functionality. When the ClearCase vendor showed this Right Click deal, I looked around the room and saw a bunch of manager types peak above their BlackBerrys and nod, as indicating "Oh that is nice. Let's make it a mandatory requirement for our next SCM tool so I don't get fired for buying a tool that does not have it." So even though I think the functionality is unneeded (at least by my group), game theory says MS should add it to a forthcoming release.

ReportViewer only pulls back 100 Work Items by default

Our release manager comes to me today and says he really likes the Report Viewer option in Team System Web Access, but hates the fact that he's limited to only viewing a 100 work items. At first I thought he was crazy - I have similar thoughts about most manager types - but after peering over his shoulder, he was right, only 100 work items showed up.

I started by digging on the forums and didn't find much. Turns out Google didn't know either so I started to track it down in our DEV environment.

If you open the Web.config under \Program Files\Microsoft Visual Studio 2005 Team System Web Access\Web, you'll find a setting for "maxWorkitemsInReportList" which defaults to 100. Push the value up a bit (we set ours to 200) and you get the requested results.

Why didn't I set it to 2000? Here is my logic; I figure Microsoft put a limit on the number of work items for a reason. I'm guessing performance, though I don't have any proof. The release manager said he would not expect anything near 200 at this point, but did have queries that pulled back more than 100. So we agreed on 200 for now and shook hands. We can gradually push the value up as we go.

I'd be interested to hear from someone with far more Report Viewer knowledge that I to comment on why there is a default max limit set.

Bug in the Power Tools recursive "Compare" utility (i.e. TreeDiff) when working with Windows and Unix ASCII files.

If you're a user of VS.NET 2005 with the TFS Power Tools and work with files edited in both Windows and Unix, you may find some odd results with the recursive Compare tool, which I believe uses TreeDiff and DiffMerge combined. The issue is, when you setup Compare to ignore end of line characters (/ignoreeol), which you need to do as Windows uses Carriage Return (CR) + Line Feed (LF) and Unix only uses LF, the Tree Difference does not honor the /ignoreeol settings. Nor do we find a way to tell TreeDiff to ignore EOL. Below you'll find the steps to reproduce and my opinion on why this is wrong. I've submitted this to Microsoft so you can get the details here.

1) Open a file in Window's Notepad and enter two lines of txt. (e.g. c:\temp\CRLF\test.txt)
2) FTP file in binary mode to UNIX machine.
3) Run cat -v on file (e.g. cat -v test.txt) to see the ^M which shows the carriage return.
4) Run dos2unix on file (e.g. dos2unix test.txt) to remove ^M
As an alternative, you can also transfer the file to Unix in ASCII mode which removes the ^M
5) Transfer the file back to Windows to a different directory (e.g. c:\temp\LF) in BINARY mode, which will not add the ^M back in (e.g. c:\tmp\LF\test.txt).
6) Edit your VS.NET 2005 Compare Tool (i.e. DiffMerge) to /ignoreeol See my post for details on how to do that.
7) Now use the Right Click, Compare tool in VS.NET 2005 with Power Tools add-in to compare directories c:\temp\LF and c:\temp\CRLF.

The Tree Difference will show the files are different, but if you Right Click, Compare Files, you should get "The Files are identical" as it now remembers you included /ignoreeol in our compare settings.

This is incorrect as the Tree Difference should also honor your Compare setting overrides (or allow overrides itself) and not flag the files as different.

The importance of Teamprise

A few months ago Microsoft's Gregg Boer was nice enough to fly in and spend a day with us discussing TFS. If I understood him right, one of his goals was to "not" develop a SCM solution for Microsoft, and Microsoft only. That is, TFS needs to be a product that helps company's outside of Microsoft solve problems. As a software company, my organization struggles with this as well. We get caught up developing software that works well for us, not necessary for the user base.

Any way, I took Gregg's comments to heart as we're using TFS in a business unit that develops all our products in Java. We don't need a SCM solution that is geared towards Visual Studio users. We need one for Java developers. Thus we leverage Teamprise for our RAD/Eclipse users and Linux desktop users. So far we've had pretty good success and great support from the vendor.

As much as Microsoft would like to see it, large companies are not going to use .NET exclusively. Sure we're going to use .NET, but we're also going to use other languages like Java, Python, or Perl. If TFS wants to compete with ClearCase or Perforce (which I think they should as TFS is positioning itself very competitively), then Microsoft needs to ensure vendors like Teamprise continue to offer cross platform solutions. I would go so far as to say, if it was not for Teamprise, our organization would have went with ClearCase/ClearQuest or Perforce (plus an additional workflow tool). Both of those tools provide our Java developers or Linux platform users, interfaces from their native environments, which was one of our top ten requirements.

In ending, we really like TFS and feel we made the right decision. But if it was not for Teamprise, we would be using a different SCM tool. That's how important Teamprise is to Microsoft.

"Connection Failed" in our Webex Training files for TFS

This is not really related to TFS, but I wanted to write it down someplace so when I have to do it again (hopefully never) I know where to look. We use a lot of Webex when training users on TFS. Showing a user something rather than writing up a long-winded email, seems to work better.

Anyway, we (actually our server support folks) just got our Webex Website server setup. It's nothing more than a simply web server running IIS 6.0. Unfortunately we were getting a "Connection Failed" error when launching the WRF files. In the past we had just a simple file share and the WRF files launched right away. After reading this post from Experts Exchange, we found that we had to add a MIME type of WRF. Once we did this, the WRF files fired right up. Below are the steps for setting this up in IIS 6.0.

1) Right Click on Website and select Properties
2) Click on HTTP Headers
3) Select MIME Types at the bottom
4) Select New
5) Enter "wrf" (no quotes) for the Extension and "application/octet-stream" (no quotes) for the MIME Type
6) Ok, Ok, Ok,
7) Restart Website. Not sure if this is needed, but it's always a good step to take with Microsoft products.

* Here is another site we used for reference.

Fixing odd diff results when using Visual Studio .NET 2005 Compare on files with line feeds

The Compare tool that ships with Visual Studio .NET 2005 is called DiffMerge.exe and it's located under "C:\Program Files\Microsoft Visual Studio 8\Common7\IDE" by default. The posting on MSDN says the default "Option" passed in on the tool is only /ignorespace.

This causes a problem with our hybrid Windows/Unix users (i.e. users who edit files on Unix, then FTP them over to their Windows box to check them in to TFS) as files with line feeds were not diffing correctly. Oddly the line above the line that was different would show a difference, even though they were exactly the same. The line that was different (right below the line showing the difference) did not show a difference.

To fix this we had to change the DiffMerge Option to /ignoreeol. These values override the default values (described in the link above). Here are our steps.

1) In VS.NET 2005 go to Tools > Options > Source Control > Visual Studio Team Foundation Server
2) Click on Configure User Tools > Add
3) Fill in the Following

- Extension = *
- Operation = Compare
- Command = C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\diffmerge.exe
- Arguments = %1 %2 /ignoreeol

4) Ok > Ok > Ok
5) Tree down to file $/MyteamProject/MyApp/.../myaffectedfile > Right Click > View History
6) Highlight the last two versions > Right Click > Compare.

For us, the files now diff correctly.

Long string values in the drop down list for Team System Web Access.

We're seeing a slight usability issue with Team System Web Access. When submitting a new Work Item Type (e.g. Task) the user is given a new, smaller, browser pop-up with the template form. This is fine, but if you have drop down fields on the right hand side of the new window, which contain long string values (e.g. "This is a really long string value that we have in our drop down list"); the user is not able to get the scroll bar as it's off the screen.

The solution is to expand the pop-up window so you can scroll the drop down list. This problem happens in Mozilla as well. We're using 1024 / 678 pixels. Because we're fielding - no pun intended - a number of questions on this, we thought it would be best to submit the a case with Microsoft.

Details can be found here.

A follow-up on a few suggestions for TFS.

I thought I'd provide an update on some of the suggestions I've posted the past few weeks.

"Find In Files" - Good news. Microsoft said they plan on adding this feature in an upcoming release. I'm not sure if it's in the Orcus release or Rosario. Being it was just "resolved" in September of 07, I'm guessing it will be in the Rosario release in late 2008 - or so I've heard. Click here for details.

"Multiple Source Control trees pointed to one local directory" - Bad news. It does not look like Microsoft has plans to change this anytime soon. Click here for details.

"Right Click and "Set Working Folder"" I've submitted this to Microsoft to see if they'd like to add the feature. Our Teamprise users really like it so we'll see what Microsoft comes back with. Click here for details.

"Allow "Get Latest Version at Checkout to be a preference setting"" - We've submitted a suggestion with Microsoft, so we'll see what they come back with. We really like this feature in Teamprise so hopefully Microsoft will listen to us! Click here for details.

"Undo you check out, but keep changes" - We've submitted this to Microsoft as a suggestion. Click here for details.

"Diff files at check in" - We've submitted this to Microsoft as a suggestion. Click here for details.

Finding your Active Directory server when extending TFS for Alerts

This is only somewhat related to TFS, but I wanted to document it anyways for my future reference. Because TFS RTM 1.0 Alerts stink, we wrote our own notification server. It simply looks at each work item change and if the "Assigned To" changes it uses the "displayName" (e.g. LastName, FirstName (Company)) to do a look up in Active Directory and find the user's email address.

In a posting way back - where I share all the things we dislike about TFS - I describe how we're using Mariano Szklanny's solution.

Anyway, I wanted to do some browsing in the Active Directory tree to see what other information we could get back, but I couldn't find the DNS to connect my LDAP browser. After digging around for an hour, I kind of found it here on Microsoft's page.

I'm not sure if this is right, but basically all I did is run the "nslookup" command and it gave me back the domain controller (I think that is what it gave me) and I was able to connect to Active Directory and get what I needed.

Again, I'm not sure if this is the best way, but it seems to work for us.

Using the "TFSUrlPublic" value

When we first setup our TFS instance, for some reason we didn't change the "TFSNameUrl" value to be our DNS name (e.g. tfs.mycompany.com) or uncomment and change the "TFSUrlPublic" value. Not sure why as we did do all the other things you need to do, which are spelled out in a number of blogs. Here is a pretty good one from Etienne.

Anyway, everything worked fine except the alerts were including the local app tier server name (TFSAppTier1) instead of the friendly DNS name. To fix this we simply uncommented the "TFSUrlPublic" value and changed it to match our DNS name (e.g. tfs.mycompany.com).

We also found out, if you don't uncomment "TFSUrlPublic" then "TFSNameUrl" is used as the default. But once you uncomment "TFSUrlPublic" then it overrides the "TFSNameUrl" value for alerts. At least that is the behavior we found.

http://geekswithblogs.net/etiennetremblay/archive/2006/07/28/86542.aspx

The horrid "There may be problems with the work item type definition" error - cont.

We got the horrid "There may be problems with the work item type definition" error again today. We get it every few days while making changes to Work Item Templates.

This time we got this when changing the "for=GroupName" attribute on a Transition. The error was only happening to a user who happened to be in a Group that was in GroupName and added to GroupName individually.

We removed the individual user from GroupName and everything worked fine. Unfortunately, like the posting below, adding the individual user back into the GroupName did not reproduce the error. It's almost as if, the root cause is caching where the only way you can force the tooling to refresh the cache (sever I'm guessing as we got the same error when logging onto a new machine with the same user) is to make a change that forces the system to update some cache.