Planet SCM

One of the painful parts of TFS 2008 install is that you can point (via the msiproperty.ini file) the install at the right machine for your SQL Reporting Services, but not the specific instance on that machine.  It's a bit of a long story as to why that is, but it does lead to the question of "If I have multiple RS instances on the machine I point it to, which one does it pick?"

Here's the logic used:

• If there are no RS instances on the machine, that's an error (of course)
• If there's 1 RS instance on the machine, we use that one (of course)
• If there's more than 1, we look for:
• If there's one where the instance name matches the instance name of the database server you pointed to, then we use that one
• This is useful because many times people will just install all the SQL Server services with an instance name like "TFSINSTANCE", so we Just Work in that case
• Otherwise, we see if there's a default instance available, and if there is, we use that one
• Otherwise, we use the first one

There's a good bit of logging in that section of code, so the logs should make it clear what it chose and why.

Jason mentioned their TXLooker back in early April, but not long after that, TeamExpand announced the beta of TX Chrono at VSLive.

I know of a good number of companies that will love having something like this - getting their timesheet management into TFS (so it can be reported on, especially) will make life a lot easier for them.

The OOTB experience for code reviews isn't horrible (shelvesets work fine, in my experience), but there's not a good built-in way of tracking the code review process, especially the feedback given.

Over the last month or so, JBBrown has done a ton of work on TeamReview which aims to tackle this problem, both making it more structured, but at the same time much easier.

The "TeamReview by Example" on the project's main page does a great job getting across what a typical code review is like with TeamReview, and if you're doing code reviews (you should!) with TFS, this sure looks like a great way to go.  It's on my TODO list to try it out myself once the current queue of work gets flushed. :)

Another brown-paper-bag bug in TFS 2005 was that, by default, all valid users could see the full list of team projects.  You would grant read access to some random team project and all of the sudden, when the user connected they could see all your team projects.  D'oh!  It wasn't difficult to change the permissions to prevent this (and sites like CodePlex had to do exactly that), but it wasn't a good experience nonetheless.

Willy-Peter (whom I had a chance to work with for a bit on the TFS BPA) noticed that got fixed in TFS 2008. :)

While there are projects like LizardTF, IMHO you're better off running SvnBridge and then using your real SVN clients.

SvnBridge allows you to use TortoiseSVN and other Subversion clients with Team Foundation Server. It converts the calls made by your Subversion client to the API supported by TFS.

SvnBridge works by running an executable on your local machine that acts as the bridge to TFS. You point SvnBridge at the TFS server, and point TortoiseSVN at the bridge running on your local machine. This allows you to use TortoiseSVN with any TFS server without needing to change the TFS server in any way (no need to convince your system administrator of anything!).

The only drawback (and it's a very small one for what you get) is that you currently have to download and run the software locally, and then point to localhost:8081 (or whatever port you decide) as your server.

I've asked the CodePlex team to host it themselves to remove that barrier, but I'm not sure when/if they'll be able to get to that.

While I personally prefer our interfaces (VS, tf.exe, etc) most of the time, I'm sure there's also value in SvnBridge for developers that like/prefer their existing SVN clients (be it svn's command-line, or TortoiseSVN, or whatever) but want/need to interact with TFS.

While we already have the code so SP1 final will support the RTM version of SQL Server 2008, because of changes during their development, our SP1 Beta only supports the "February CTP" version of SQL Server 2008.

If you already have the SQL Server 2008 CTP installed and aren't sure if it's that CTP or not, the version number for the February CTP is 10.00.1300.13.

If you want to do a fresh install against SQL Server 2008, though, you'll need to do our "integrated install".  Abdelhamid posted the instructions in a blog entry earlier today.

http://blogs.msdn.com/aabdou/archive/2008/05/13/team-foundation-server-sp1-beta-now-available.aspx

The steps to perform the integrated install are easy

1. On the server that you plan to install Application Tier on copy the RTM media (AT folder on the DVD) to a local folder say <AT RTM Folder>
2. Extract the SP1 package to a local Folder by executing the command TFS90sp1-KB949786.exe /extract:<SP1 Folder>
3. Run the following command to combine both RTM and SP1 to one install package: msiexec /a <AT RTM Folder>\vs_setup.msi /p <SP1 Folder>\ TFS90sp1-KB949786.msp TARGETDIR=<AT SP1 Folder>
4. Your Integrated RTM+SP1 setup is now available in <AT SP1 Folder>. You can run setup.exe in this folder to install Team Foundation Server 2008 SP1

I helped a friend via email with this last week and just noticed a similar blog post.  If you're having trouble trying to destroy an item you already deleted (to free up disk space, for instance), you may find this helpful.

http://kinnie.blogspot.com/2008/05/6-delete-vs-destroy-in-tfs.html

The thing is that you need the deletion id of the item to force the destroy. How to get that deletion id? Request the properties of the appropriate item via the properties command. After that you will be able to pass the deletion id to the destroy command and the folder should be gone forever.

Joel's 12 rules rightfully includes 2 entries on creating builds.  While many would argue that rule 3 should be modified for continuous integration rather than daily, Team Build 2008 does a great job getting your team covered in both cases, and more importantly, for both rules.

With this screencast, Steven Borg covers getting automated builds and a build server set up with Team Build 2008, so if you don't have those automated builds already running, hop to it!  It's like TiVo - once you have it, you'll wonder how you ever lived without it.

If you've used CruiseControl / CruiseControl.NET, Continuum, or other CI servers in the past, then you're going to be up to speed on a lot of the gains of using Team Build 2008 already, but there's still a lot of other things to learn from the screencast, so check it out!

geekSpeak recording: All About Team Build 2008 with Steven Borg

In this episode of geekSpeak, Steven Borg shares the merits of using Team Build 2008 to radically improve the quality of the code you write. Steven gives a great overview of how to set up automated builds and a build server, and the benefits of investing the time to do it right.

I'm about a month behind on this one, but based on their technology roadmap, TFS integration is on the way!

Team Foundation Server

A plugin supporting the version control features of Microsoft Team Foundation Server is currently in development. It is planned to be released for both IDEA 7 and 8.

Yay!  I used IDEA for a long time and really loved it.  I'm very happy to see this!

Don't be fooled - despite being tagged Beta, this actually isn't a Google product.  I kid, I kid!

Hopefully by now you've already seen Brian's list of SP1 improvements for TFS.  My work's been mainly around SQL Server 2008 support (it's been interesting), although my team did have one brown-paper-bag bug where tfsadminutil sid /change didn't work.  At all.  A one-line fix, at least :)

Anyway, I noticed ScottGu posted a list of improvements for the rest of the service pack.  Wow.

This particular bit made me very happy:

VS 2008 SP1 adds much better intellisense support for popular Javascript libraries (we specifically did work to support JQuery, Prototype, Scriptaculous, ExtJS, and other popular libraries).

I use all 4 of those listed in various ways on my own asp.net 3.5 sites, and it's great to see this!  It'll make development that much easier.

Also, I'd been using Dynamic Data support already, but it's nice that it's in the service pack so I can avoid the separate download.

One bug not listed that I'm really hoping that gets fixed is the javascript breakpoints in closures.  A lot of my own code uses that, and it's painful to live without.  Thankfully, Firebug has no problem with that, so I had a fallback, but I'd rather be a good dogfooder when I can :)  Kevin Dente (author of that blog post) posted a comment on Scott's blog, so I'm sure we'll hear back soon!

I need to learn more about LINQ-to-Entities to see if it has anything compelling over LINQ-to-SQL (which I've happily been using).  Astoria's interesting, but I don't have any need for exposing data as REST at the moment, so it may be awhile until I get around to playing with that.

One of the things I miss when using TFS instead of Subversion is svn's metadata ("properties") that you can attach to arbitrary items ("svn propset" for the fellow command-liners out there).  It's something I only used around 10% of the time, but when you need it, it's very hard to live without it.

As Brian mentions in this blog post, we have a spec for properties in our upcoming version of TFS.  As you can see from the list he mentions, there's a lot of scenarios this enables (his list is very much the tip of the iceberg) that are very difficult without it.  I'm glad to see we'll be getting this and hope lots of people give feedback, especially any Subversion users that miss that feature and want to make sure we handle their use case :)

While Subversion uses these properties internally, I think it's worth pointing out at least one scenario that a common svn client (TortoiseSVN) supports: linking with bugs in Trac (or another bug-tracking system). 

That particular scenario is handled natively in TFS with our links between changesets and work items, of course, but hopefully it makes it clear what kind of power properties can deliver to tons of scenarios, especially those around integration.

Helen: You're late. When you asked me if I was doing anything later, I didn't realize you'd actually forgotten. I thought it was playful banter.
Bob: It *was* playful banter.
Helen: Cutting it kinda close, don't ya think?
Bob: You need to be more... *flexible.*

The Incredibles has a permanent spot on my DirecTiVo since all 4 of us in the house love to watch it :)

Anyway, here's a quick meta-post to link to the TFS 2008 flexibility blog posts over on Sudhir's

• Analysis Services Flexibility
• Reporting Services Flexibility
• SharePoint Flexibility
• Armstrong Flexibility

I made a failed attempt to see if we would be willing to make the next version of Team Foundation Server only supported on Windows Server 2008.  Since we'd like to have native IIS7 support in our setup (not require the IIS6 compat like we do in TFS 2008), we're looking at maintaining 2 different code paths, the 2k3/IIS6 method (already coded and tested, thankfully) and the new IIS7 code.

There ended up being a whole slew of benefits to being Longhorn-only (much smaller test matrix, ability to take dependencies on some IIS7 features, powershell in the OS, etc), but it's not going to happen, at least not for this release. 

This means our job is a bit tougher, but for all of you playing along at home, be happy knowing that (at least as things stand now) we won't be forcing an OS upgrade with our next version of TFS :)

I get what it's trying to say, but I'm at a loss as to what the Yes and No buttons will do here.  I'm not sure this warrants WTF, but still.

Actually, perhaps I'm wrong - Chris thinks it warrants it :)

James Manning?? [1:25 PM]:
  ---------------------------
Windows Server Backup
---------------------------
The selected volume is also included in the list of items to back up.  Exclude this volume from list of volumes to back up or add another disk and retry.
---------------------------
Yes   No  
---------------------------
??Chris Rathjen?? [1:25 PM]:
  wtf

This request came in from an internal PS list.  You can certainly make it fancier, and all it does now is invoke a WIT method, but hopefully you may find it of value.

param($wiqfilename = $(throw 'must specify wiq filename'))

# get the fullpath to the psqfile, get the provider path as
# it will handle UNC paths too
$wiqfilename = (Resolve-Path $wiqfilename).ProviderPath
$wiq = [xml] (gc $wiqfilename)

$tfs = get-tfs $wiq.WorkItemQuery.TeamFoundationServer
$results = $tfs.wit.Query($wiq.WorkItemQuery.Wiql, @{'project' = $wiq.WorkItemQuery.TeamProject})
$results

A potential place to use an extension method cropped up in our team this week, and I gave feedback that I'd like to avoid it (for this case) because in this scenario, it enabled something that just felt wrong to me - working instance methods off null instances. 

Remember, null in C# isn't like Ruby's nil - in the typical case, you'd get a NullReferenceException (like if the below snippet had called GetType() instead of GetName()).

It's not a big deal, just a funny little thing.  If you don't use extension methods, of course, then you won't see this :)

public static class ExtensionMethods
{
    public static string GetName(this Program prog)
    {
        return "oooooooooooohhhhhhhh";
    }
}
public class Program
{
    static void Main(string[] args)
    {
        Program prog = null;
        System.Console.WriteLine(prog.GetName());
    }
}

This one is, unfortunately, very easy to get wrong, and lots of people do, even those inside MSFT.  It came up when I was reading a recent post from the great Jeff Atwood, where he gets it backwards, thinking the Local System account is limited, when it's anything but.

Note that the service is running under the Local System account, which has extremely limited permissions. Normally, this is OK, but if you plan to implement any Subversion hook scripts later, you'll want to switch the service identity to another account with more permissions.

The names for these 2 accounts are painfully similar, which IMHO is likely the main cause of confusion.  Something called "Limited Service" would have more clearly identified that 1) it's of limited permissions and 2) it's (still) targeted for use by services.  Ah, well.  That ship... it has sailed.

The LocalSystem Account

One advantage of running under the LocalSystem account is that the service has complete unrestricted access to local resources. This is also the disadvantage of LocalSystem because a LocalSystem service can do things that would bring down the entire system.

LocalService Account

[LocalService] has minimum privileges on the local computer and presents anonymous credentials on the network.

In the cmd world, I constantly had filenames that I had to copy-paste onto a gvim command-line, sometimes from findstr, or from dir, or whatever. 

In the PowerShell world, I tend to have available (from some previous command) paths as strings, PathInfo instances, powershell item objects, or something similar, so all those things could be piped into get-item (which is amazingly good at figuring out which item you're talking about based on just about anything you can pass to it).  That makes it very easy to get those items and, for my usage, pass them along to gvim, potentially using "tf" to pend edits on them first.

In fact, to get the source to post here, I didn't even need to remember which dir I had this script in, I just had to "gcm gvimf | gvimf"

param([switch] $edit)

if (-not $args) { $args = @($input) }
if (-not $args) { throw 'files are required either as params or input' }

$filepaths = $args | get-item | %{ $_.fullname }
if ($edit) { tf edit $filepaths }
gvim $filepaths

The first "real" line (referring to $input) lets us pass things in either as command-line params or piped in (I could have allowed both easy enough with += and dropping the if, now that I think about it, but haven't actually had that need yet)

There's one thing that's conspicuous in its absence - quoting!  I love PowerShell - the above Just Works even if the dirs have spaces in them, or the files have spaces in them or both.  I didn't have to deal with any of that junk myself when calling tf.exe or gvim.exe, it just does the right thing since I'm passing arrays of strings.  It's a beautiful thing.

why gvim instead of vim?  because the gvim window is easier to resize/maximize and it doesn't block the powershell that spawned it like vim does.

I've had this come up in conversations in the past (and it's been on feedback for almost 3 years now), but just realized I never posted the (simple) extension method I use.

A comment on Brad's blog:

# Milan Negovan said on July 4, 2005 5:59 PM:

Brad, is there any reason why Contains, IndexOf and such don't have an override with StringComparison?

(Whidbey actually added it for IndexOf and LastIndexOf, as per the feedback link)

A comment on the BCL team blog:

Thursday, April 06, 2006 3:13 AM by Andrew Webb

# Finish off the String class

Add a StringComparison parameter to the Contains and Replace methods of the String class.

While I could add it for Replace as well, I only typically need Contains.

    public static class ExtensionMethods
    {
        // BCL should really include this
        public static bool Contains(this string self, string value, StringComparison comparison)
        {
            return self.IndexOf(value, comparison) >= 0;
        }
    }

Ok, so it's just in the planning stages, but you may have run across Charlie Calvert's recent blog post about supporting dynamic (aka runtime) lookup for methods/properties/etc which would avoid having to deal with that ghastly beastie that is reflection (even though I'll admit the reflection API's are probably about as good as they can be given the nature of what they're doing).

http://blogs.msdn.com/charlie/archive/2008/01/25/future-focus.aspx

Dynamic Lookup

The next version of Visual Studio will provide a common infrastructure that will enable all .NET languages, including C#, to optionally resolve names in a program at runtime instead of compile time. We call this technology dynamic lookup.

Work on support for dynamic lookup was begun in the CLR, but soon became part of the Dynamic Language Runtime, or DLR. The DLR provides the infrastructure on which a common set of dynamic tools can be built. For instance, the DLR provides the infrastructure for both IronRuby and IronPython. It will be the infrastructure on which the C# team implements dynamic lookup .

Support for dynamic lookup is already available in Visual Basic for .NET, where it is often known as “late binding”. The new release of .NET will provide C# developers with similar functionality, while at the same time providing a shared infrastructure for runtime name resolution across all .NET languages, including VB.

more...

I went ahead and added my own comment on implementation, but would love to see others chime in as well.  Here's my comment, just to make this blog post longer than it needs to be.

Love the idea, but the dynamic keyword is indeed a bit limiting - since it's most logically tied to an instance, the "this is dynamic" magic should be tied to an instance/variable instead of a scope.

What Andrew Davey said about IQuackFu from Boo is good, but IMHO the easier and more powerful approach is also from Boo - the "duck" type (http://boo.codehaus.org/Duck+Typing), which you declare a variable as and then the compiler knows that it's a dynamic type.  Then you can pass "duck" objects around without having to deal with the dynamic keyword.  Then tools (like the debugger) also know the instance is "special" and interact with it as such.

Instead of duck, though, perhaps System.Dynamic or similar, since it probably makes sense to have it represented in the BCL since you may want to string some static methods off of the type (System.Dynamic) that helps runtime interaction with such objects, like easier-than-reflection inspection of methods/properties/etc, or Ruby's "reopen this instance/the entire class" support, or whatever.

Back to the IQuackFu/IDynamicDispatch idea - as long as the compiler implements it as a fallback so "regular" method calls that are implemented by the type keep working as normal, then that's fine with me - it's effectively Ruby's method_missing at that point, which would be useful to have in some situations.

The combination of the two gives you both fully-dynamic instances (with the duck typing aka System.Dynamic) and partially-static, partially-dynamic (with IQuackFu aka IDynamicDispatcher), so you can choose what works best for you.

The idea is great, but I really fear the dispatch keyword+scope approach would make it less useful (read: more cumbersome) to interact with.