Manually Adding Files to Pending changes in Teamprise's Plug-in

There have been a few times recently when users have added files in Eclipse, but the files were not picked up by Teamprise's Eclipse Plug-in as a Pending Change.  If this happens, the new file will have a "?" on it.  It's one of those incidents that we can't seem to reproduce, but happens ever so often.  It also seems to happen to a small subset of users.

If you run into this problem, a work around is to manually add the files.  I'm doing this from memory so the steps might be slightly off.  However, I think it's close.

1. Show the Team Explorer Panel in Eclipse.  Window > View > Teamprise > Team Explorer.
2. Make sure your Team Project is selected and expand it.  There you will see Source Control.
3. Double click on Source Control.
4. In Source Control, path yourself down to the correct directory where the files were indented to be added.
5. Right Click on the directory you're wanting to add the file to and say "Add Files to Source Control" (or something like that).
6. Now select the files that were not added by the plug-in.
7. Back in Eclipse's Package Explorer (or what ever view you're using), Right Click > Team > Synchronize.
8. The Synchronize command should now make the "?" files show up as "+" files and thus added to your Pending Changes.

Hope this helps anyone who runs into a similar situation.

<UpdateBuildNumberDropLocation and NFS File Systems

Our current Team Build drop location is a Common Internet File System (CIFS) mount to some network attached storage (NAS).  To a novice like me, the drop location looks just like a Windows server drive that is shared.  However, on the back end this CIFS mount has all the bells and whistles that the data center offers (e.g. backups, redundancy, etc.).

The issue we have with the CIFS mount is that while our Windows servers can pick code on their for deployment, our Linux boxes can’t see the CIFS mount.  Since a lot of our development is done in Java and runs on Linux, we have an issue.

Enter the fine storage and system admin teams who have tested the use of Network File System (NFS), as a replacement for the CIFS mount, which is accessible by both Windows and Linux servers.  We’ve tested the NFS mount and sure enough, both our Windows servers and Linux servers can mount to the same drop location and pick up the build output used for deployment.  Perfect right?  Unfortunately there is a small issue.

According to this post, Team Build’s <UpdateBuildNumberDropLocation Task has code in it which needs to update permissions on the drop location.  From what I understand, the code will change the permissions so the App Tier service account has access to the drop location (it needs access to delete builds and such).  To see this, Right Click on a file located on the drop location and notice how the App Tier service account has full access to the folder and any sub files or directories.  The <UpdateBuildNumberDropLocation is doing this.

The issue that I’m running into is, when the drop location is a NFS system, there are no permissions at the file or directory level.  For Windows, the permissions are at the share level.  I’m assuming Linux permissions are dependent on wether the mount is a write or read mount.  So when the <UpdateBuildNumberDropLocation Task runs, it gets a message back saying permissions can’t be set and thus throws this friendly message back to the user: “TF209025: The build process is unable to set the permissions on the drop directory <actual drop location>(Detail Message: Attempted to perform an unauthorized operation.). Make sure that the build service account has proper permissions on the build drop directory and try again.”

What’s interesting is, the share is wide open thus the NFS mount is wide open.  And Team Build actually writes files to the location.  So functionally everything should work fine if we could get past the feature in the <UpdateBuildNumberDropLocation Task where it tries to adjust permissions.

I’m not sure what a good solution is for this.  However, I think the current implementation needs adjusting.  In my Connect submission to Microsoft, I’ve asked them to provide a Property (e.g. UpdatePermissions=”false”) where you can turn off the permission change when you want to use a NFS mount for your drop location.

Team Explorer "did not load because of previous errors"

My colleague installed TFS 2008 SP1 on our app tier.  He then uninstalled it because we were having some issues, which we're tracking down. However, after uninstalling, we were unable to open Team Explorer due to the following error.

The Microsoft.TeamFoundation.Client.ServicesHostPackage, Microsoft.VisualStudio.TeamFoundation.TeamExplorer, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a ({8E01EC3E-2928-4AA5-B720-E28C163818E6}) did not load because of previous errors. For assistance, contact the package vendor. To attempt to load this package again, type 'devenv /resetskippkgs' at the command prompt.

I'm not sure what /resetskippkgs does, but I ran it and Team Explorer is now back to being functional.  If you run into a similar problem, I’d be interested to see if this /resetskippkgs works for you.

"Find in Source Control"

It's fall which means all the interns from MIT, University of Wisconsin and University of Minnesota (I'm an alumni) head back to school.  It's also time for us full time employees to pick up the messes they left.

For me, their messes usually include having thousands of files checked out in TFS (or VSS back when we used that).  In the past, I just deleted their workspace from a command line.  That works pretty well and to be honest, should be the way we do this.

However, my colleague showed me a really cool feature called "Find in Source Control" where you can search on a person's ID to see all their pending changes.  Then you can undo them from there from a nice gui.  Works great when you've got some lead engineer breathing down your neck because they can't update source code because some intern had an exclusive lock on the file.  Nice feature Microsoft.  Keep up the good work.

HintPath and Team Build

Very long week so I've got to keep this short. For some reason when a developer added a Reference to his csproj file it didn't add a <HintPath. The build worked locally and it worked on the build machine when we ran the build manually through Visual Studio. However, when trying to run the build via Team Build, we got the error "Could not resolve this reference. Could not locate the assembly." We could see that when Csc.exe was called, our Reference was not referenced.

The fix was to add a <HintPath to the csproj file. After doing that, Team Build ran fine and we could see it added to the Csc.exe Reference command line. I didn't get time to figure out why, but thought I'd document it here for when it happens again.

Source Control Cache Hits on our server.

I enjoy reading Grant's blog. In this Cache Hits post, he shows how to get your Cache Hit Ratio.

We're currently hitting our local Source Control cache 96.06% of the time. What are your numbers? I'm interesting in comparing.

Using $(WebProjectOutputDir) in the *.csproj file's PostBuildEvent

A colleague of mine wanted to add a PostBuildEvent in their *.csproj file which would run a custom executable to create generated java script files.

The change (see BEFORE below) worked locally as the path they wanted the generated was $(ProjectDir) which mapped to the .\Sources directory on the build machine and their locally directory within their IDE. The issue was, we needed the generated files to be under .\Binaries on the build machine which didn't exist on their machine. More specifically, we needed this generated file created under $(OutDir)_PublishedWebsites\$(MSBuildProjectName) on the build machine which translates to .\Binaries\_PublishedWebsites\$(MSBuildProjectName).

What we ended up doing was, instead of using the $(Outdir) property, we used the $(WebProjectOutputDir) which was set in the $(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets file. Using this value allows the output directories to be correctly set on both the build machine (where we want to use .\Binaries) and $(ProjectDir) where we want to use the locally structure.

BEFORE:
"$(TargetDir)JavascriptFromMvcRoutes.exe" "$(TargetDir)$(TargetFileName)" "$(ProjectDir)js\Generated.js"

AFTER:
"$(TargetDir)JavascriptFromMvcRoutes.exe" "$(TargetDir)$(TargetFileName)" "$(WebProjectOutputDir)js\Generated.js"

TSWA Profile > Options Not Staying

A colleague of mine tracked down an issue where all users' TSWA Profile > Options were not staying after they closed the browser. For example, a user would change their Theme to Olive, but after they closed their browser it would default back to the default.

We're not sure if this is the right fix, but we had to change permissions on the D:\Program Files\Microsoft Visual Studio 2008 Team System Web Access\Web folder so that "Users" had Modify permissions. Users are now able to change their Options and they stick.

Question Marks "?" on files in Teamprise

A colleague of mine summoned me over to his desk. He had question marks "?" on all the files he checked out from the Teamprise Plug-in and was wondering why.

Typically I see files with question marks on them when the user has changed the file permissions without checking the file out. Teamprise, not knowing what the status of the file is (as I would expect), labels the file with a small question mark indicating that something has changed, but its not sure what. Or something like that.

However, in this case the user had promised me the files were checked out. He had the Pending Changes to prove it.

I did a quick search and after digging through a couple of my old posts, I found Martin's post Teamprise V2 Preview 2 where he discusses better off-line support. It's here he states "When you next connect, all the read/write files will have a little question mark on them inside Eclipse."

Now the user is using Teamprise 3.0, but my thought is this "question mark" behavior was not changed until 3.1, which by the way is what I’m using. He's been having a number of network issues so my guess is that his network connection was dropped thus resulting in Teamprise 3.0 to go into "off-line" mode. Once he was back online, he would have needed to run "Team > Synchronize" to synch back up with the server. This is exactly what we did and the question marks were changed back into check-marks indicating check out.

I couldn't reproduce this as I think Teamprise changed the behavior in 3.1. If I get sometime next week, I'm going to rollback my Teamprise version to 3.0, check out some files, drop my network connection and see if I can reproduce the error. Or more likely, simply upgrade him to 3.1!

Bug in TFS 2008: "TF50605: There was an error looking up the SID for "

Here is a Bug we found in TFS 2008. At least I think it's a Bug. It happens when you try to delete (or perform other workspace actions) on a workspace owned by a user who no longer is in Active Directory.

1) Create an AD account and use it to log into TFS 2008, create workspaces and check out files.

2) Then, leaving some files checked out such, delete the account in AD. This is what happens when someone leaves your company.

3) Go back to TFS and try to delete their workspace. E.g. tf workspace /delete /server:http://tfs.int.mycompany.com:8080 Z055638-XPA;Z055638 *where Z055638 is the user who left the company.

4) You should get the error "TF50605: There was an error looking up the SID for Z055638" which to me means since the account can't be found in AD (the user left the company) you can't delete their workspace and thus can't "undo" any files they have checked out.

To resolve this, we had to manually update the TfsVersionControl, Tbl_Workspace table. Cameron Vetter's post gave us the idea. We changed the OwerId field to a valid user for that workspace. The we were able to delete it.

Not ideal, but worked for us. I've submitted this to Connect as well.