If you've been reading this blog, you'll notice that I'm a fan of PowerShell and their integration and .NET stories.  While PowerShell has great support for command-line exe's (you can do the same separation of stdout/stderr, for instance, that bash has had over tcsh for so many years), the more I use PowerShell, the more I hate most exe's.

Why is that?  Because of the poor integration story.  Unless you're willing to do some heavy lifting, you're normally stuck with input mechanisms like temp files, command-line params (in the fixed-size buffer you have available for passing those), environment variables, and a few other similar things.  Nothing great, nothing very structured (natively, you can always use a serialization format like xml), and it's always a bit of work.  Your output mechanisms aren't much better, as you're looking at an int (the exit code) and variable amounts of data from your stdout and stderr mechanisms.  It's one of those things where the mechanisms afforded worked great for the simple cases, but once you wanted to do more complex things, you had to introduce more work, usually text-based processing (find . -exec ... | grep foo | sort -u | awk '{ print $2 }' | cut -c19-32 | ...)

Even inside TFS, some of our story in V1 is pretty limited to command-line utilities.  This is the truest in the admin/ops story, as you're often stuck with things like TfsAdminUtil, TfsSecurity, parts of tf.exe (permissions, for instance), BisSubscribe.exe, TfsReg.exe, TfsDeleteProject.exe, ProcessTemplateManager.exe, etc.

Don't get me wrong - in many cases the exe is all you need.  In many cases, it's exactly what you need.  But what if it isn't?

In my Perfect World, you wouldn't be limited to exe's, but you'd have more of a stack available to you and you'd integrate at the points that were most convenient.  As a comparison point, you can see how in the version control part, you have the web services (go TeamPrise!), the object model, tf.exe, and the VSIP interfaces (not to mention the usual Visual Studio macros and tricks you can do).  Having more and richer integration/extension points makes it less and less important whether we handle every need in-box, because it makes it easier for others to leverage our work.

• (still debating this one) web services for management operations
  • May be limited to just the operations that makes for a static and up app tier.  Alternatively, implemented as a separate site somewhat like Sharepoint's central admin site.
• web interface for management operations
  • Same issues as the web services, as we have some potential chicken-and-egg problems
• object model for admin/ops needs
  • This is the part where we're most sorely lacking.  This isn't just configuration changes, but also better and easier reporting for server status and configuration.  The better this is, the easier integration with things like MOM / Unicenter / etc. should be.
  • Still unclear which machines this would need to exist on.  Because of the simplicity and security benefits, I'm all about leaving these bits on just the TFS server machine(s) and using other mechanisms for remote execution.
• cmdlets for admin/ops needs
  • Fundamentally, I think of cmdlets as the layer on top of your object model that helps reduce typing.  IOW, it should help make many of the operations you expect people to want to do easier to find and easier to type, easier to integrate with (parameter help, accepting various types of object on input, etc.).  They're extremely powerful in helping promote usability from the PowerShell world, but if you find a certain cmdlet that your users literally could NOT get functionality X without, then that's exposing a hole in your object model and you need to push it down there first and then have the cmdlet wrap that.
  • Another reason to make sure your cmdlets are thin wrappers around your object model - other languages!  There are certain to be consumers that want to do something programmatically in C# or VB or IronPython or whatever else.  Once you can bridge your functionality into .NET, the interop story there is HUGE and powerful.
• exe's for admin/ops needs
  • Just like Mom used to make!  Still needed for back compat, at least, but a good exe (like tf.exe) should still be useful.  If nothing else, on Windows 2000 (no PowerShell support), you still need these guys in addition to the cmdlet's. :)
• Admin/ops GUI that builds on top of the cmdlets
  • This should sound familiar, as it's the way tools like IBM AIX's SMIT interface has worked for years (I really liked it - it helped teach me lots of the AIX tools), and is the way Exchange 2007 works today.
  • Most likely, this would exist as a MMC snapin, as MMC, like PowerShell, has done a huge amount of the support and infrastructure work, so coding a snapin instead lets you focus on just the parts specific to your need, in this case TFS.

Exchange 2007 really has the story I want us to go after.  Their admin story is fully centered and focused on PowerShell, and the GUI they provide is just a usability gain on top of the cmdlets (and like I said above, cmdlets IMHO should, in turn, be nothing more than a usability gain over your object model).  PowerShell has let that team throw away a lot of the plumbing code that doesn't really help customers and let them write and expose rich interfaces that make things that used to take 200 lines of vbscript down to 2 or 3 lines of PowerShell.

Don't get me wrong, though, you can still get a lot of the benefits of PowerShell even with TFS v1 (after all, I've got some scripts that use the GSS interfaces instead of calling TfsSecurity.exe), but I'm looking forward to a future version where we're doing more of the heavy lifting in-box and doing more to surface a lot of this functionality that we've coded, but "hidden" behind interfaces like exe's that may not be as useful to you.

If you're still reading (and I'm amazed if you are), then what I really would like to know is:

• What matters most?  (IOW, what would you consider to be the most important new thing to expose that isn't already)
• How much does it matter? (What scenarios does it enable that you don't feel you can do today?)

These questions are not just to figure out what goes into a given release and what doesn't, but also (just as important), *when* it goes into a release.  If something is of huge importance, everyone is better off the earlier that code goes into the product, so it has more betas and CTP's to get hammered on but people, but inside and outside Microsoft.

Is our existing exe's all I want to see exposed?  Of course not! Many of the other tools are ones that don't really even have to be in-box, but could be shipped out-of-band (power toytool style).  Some of these are actually small enough that I have scripts already for them and just need to clean them up a bit and post them.

• Tools to help diagnose why a TFS setup isn't succeeding (Robert's thought a lot about this)
• .. diagnose why a given client can't connect to a TFS server
• .. diagnose why a given client can connect to TFS, but not WSS and/or Reporting Services
• .. use TFS tracing to check for perf problems
• ... etc ...

Any other tools you'd like to see?

And, finally, just to fill in some more questions I've wondered:

• What management tools (like Exchange 2007's shell, IMHO) do you consider the most usable/powerful? 
• What tools do you like using for your administration/management needs? 
• What are the killer features that save you time/effort/headaches?