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!