The New Hype: Top Shelf Project for building Windows Services

January 30, 2012 Leave a comment

Lately my coder compadres have been all a flutter about something called Top-Shelf-Project, an open source project for building windows services for .NET or Mono platforms.

What’s so great about it? I don’t know. I’m trying to find out.  I’ll be back in an hour…

Okay, it’s been more than an hour, but I had to go refill my iced espresso and space out for a minute or two.

Here’s what I’ve found out:

The Top Shelf project allows you to deploy behavior in a similar fashion to a traditional Windows Service, but without the need to create an actual Windows Service project type – a Console Application will suffice, and without all the scaffolding that a regular Windows Service project requires.  You can just run a short bit of fluent configuration in your Console App’s Main routine to configure a regular .NET type as a service. You then have the option to debug it as a Console App (which is a bit easier than having to install and then attach to a traditional Windows Service).

So that’s three nice things there:

  1. less scaffolding,
  2. easier debugging options
  3. fluent style configuration.

That’s a good start.

There’s a few more reasons to dig it besides. Top Shelf bakes some additional goodness into its fluent Host Configuration – namely some convenient command line installation parameters.  Its sort of like magic. I had to check out the source code to see how they did this just to convince myself that it would really work.  Its baked into the host configuration routine.  It looks for command line arguments like “Install” and then handles the nitty gritty of actually installing your console app as a service.

So you build your console app and then just run it from the command line with the “install” argument.

like: c:\boogersugarservice.exe install

The traditional way of installing a Windows Service these days is really not so bad. I wrote a powershell script to uninstall, copy and reinstall a windows service recently – using installutil.  No biggie.  This doesn’t change that scenario all that much, but at least its self-contained and you don’t even need to get a separate utility involved.  Any time even a single step can be eliminated from a deployment procedure my brain releases some happiness chemicals.

Then there’s this whole SHELVING concept.  First of all, what’s up with this metaphor?  I’ve gotten used to using this term in the context of TFS source control and spent a few minutes fumbling about trying to disambiguate that from the meaning in this context.

I could be wrong here, but best guess is you can deploy and startup a new service as easily as throwing a book on a shelf – something like that? Maybe? No?  Well whatever.

Basically shelving involves the use of a TopShelf Service Host. The intention of the host is to allow you to deploy and re-deploy services and have them auto-magically stop/uninstall/reinstall/start in a similar fashion to when you modify the web.config file of a site in IIS and IIS auto-magically knows to recycle the app pool and reload the config.

I haven’t tried this out yet. I’ve been perusing the discussion forums and seeing a fair amount of trouble with production implementations of this.  Makes me a little nervous. But I’ll have to try it out for myself and see.  I will report the results in a future post.

Categories: Uncategorized

VS2010 Error: Unable to start debugging on the web server

November 21, 2011 Leave a comment

If ever you should find yourself confronted with the following error in VS2010 (or its ancestors):

“Unable to start debugging on the web server”

It could be because the msvsmon.exe process has been terminated by some unfortunate circumstances.

This will drive you insane until you sort it out, so quickly read this:

Basically, you need to make sure that the Remote Debugging Monitor, msvsmon.exe is running.  Find VS2010 in your programs menu and look for the Visual Studio 2010 Remote Debugger under Visual Studio Tools.  Read that article for configuration details. In my case, simple browsing into the x64 directory and executing the msvsmon.exe fixed the problem.  This is something I normally take for granted when debugging in Visual Studio.  I created my own problem here because I actually wrote a powershell script to kill the msvsmon.exe process when re-initializing my debug environment.  Why?  Because I was trying to identify the source of some session cache re-initialization issues and thought that little bugger might have had a hand in it.  Still not sure if that was the case, but I do know that I need to make sure that I restart this after I kill it.

Categories: Uncategorized

TFS Getting Real Slow – Is it TFS? The VM? The Proxy? or IE?

March 30, 2011 Leave a comment

Skip ahead for the remedy for bad TFS performance or read on to share in the tale of my woe.

Spoiler: It was Internet Explorer in the Dining Room with a Candlestick

I’ve spent the past 2 days giving my web operations support personnel hell.  I’ve been trying to resolve a performance issue on a test environment webserver.  As a fallback deployment method we have installed Team Explorer and Team Foundation Power Tools on the test server.  Previously the team this is for used Subversion and had a similar configuration.  The local workspace is mapped to the deployment target directories under inetpub\wwwroot.  So, to update TEST, the team can just execute a Get operation on a site.  Not fancy, but effective for their purposes.

The problem cropped up when trying to initially Get some of these sites.  The performance was beyond poor.  It was abyssmal, ridiculous, ludicrous even!  A different kind of “ludicrous speed”.  I couldn’t pull a 10 MB website down – after 10 minutes it had only retrieved about 644KB.  “Yikes!”  Yikes, indeed.

We’d been using Team Explorer and TFS for the past year in this company and I’d never seen any issues like this.  It was understandable then, for me to assume it was a system issue, especially after hearing some rumors of misconfigured VMs.

So fast forward 2 days and 2 re-created VMs later, nothing has helped and I’m ready to bash my head in one of the drawers of those big cubicle file cabinets.  I get the big idea that maybe this is a network issue and not a VM disk issue.  So I try to copy those same 10MB website files over the network from my laptop to the server.  Takes all of 20 or 30 seconds.  Not stellar speeds, but totally acceptable!  Remarkably adequate even!  OK, so what the hell is going on? Why can’t this particular system talk to TFS?

Initially I blamed TFS.  Don’t get me wrong. I love me some TFS.  But in this case, TFS really pissed me off, or so I thought. Within the config file for Visual Studio / or the Visual Studio Shell with Team Explorer which on this x64 Windows Server was found here:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config

I added the following additional setting:

<defaultProxy enabled=”false” />
<ipv6 enabled=”true”/>

A miracle happened.  Suddenly I could not only pull down a 10 MB site in a few seconds, but I could pull down all 24 websites in several minutes.  What the freaking hell?  Why was this necessary on this server and none of the others?  That is a mystery I aim to solve tomorrow.  For today, I’m just happy as crap that I can use this server again.

Oh, one more thing. If you use the TF.exe command line you’ll want to make that change to the TF.exe.config file as well.

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\TF.exe.config

The TF.exe.config file does not have a System.Net element at all.  I just pasted in the entire element as shown above and hoped for the best. It worked.

In truth my beloved TFS was not to blame!

I’ve had a little time to research the real cause of the problem and found that the distinguishing characteristic on the problem server was found in the LAN Settings.  “Automatically detect settings” was checked only on the problem server.  I unchecked that box and removed the <defaultProxy enabled=”false” /> element and all was well.

I followed up with our VMWARE admin and was informed that, although the policies were defined with this flag turned off, Internet Explorer still defaults to “Automatically detect settings”.  Not sure if this is the whole story or not.  In any case, if you’re having similar performance issues with TFS, check your proxy settings.  Try the config fix.  If it works, it’s probably your proxy settings.

Categories: TFS

Bulk Rename Operation in TFS using Powershell

March 25, 2011 Leave a comment

If the structure of your TFS source control requires an overhaul this may help.

Lift With Your LegsFirst if you haven’t already, install the TFS Power Tools. Make sure you find the most recent release.

Here is a link to the most recent version to date:

During installation be sure to install the TFS Cmdlets for Powershell.

If you’ve never used Powershell before fire up a PS Console from the shortcut found under TFS Power Tools in your program menu.

Then set the execution policy by typing the following:

Set-ExecutionPolicy RemoteSigned

OK. Now you’re ready to do some damage. 

SERIOUSLY careful with this!

You don’t want to mess up your repository any more than it already is.
The following snippet is just an example of something you could do, but is not meant to be used as is.  You will need to modify it to suit your requirements.

In my situation I had created about 25+ separate directories for different website projects, each with their own set of branches, Dev, Main, etc.  It looked something like this:


and so on.  I realized I would have to create an additional directory under “Dev” which was the root of the branch to contain each website.   It would have to be modified to look more like this:


So, first I tried to use the Source Control Explorer “Move” command through the GUI.  That didn’t work too well. SCE didn’t seem to want me to move all the files at once in a drag and drop operation and I didn’t want to have to painstakingly drag each directory individually.

Powershell to the rescue…

The Powershell CmdLets for TFS installed with the Power Tools include one item called:


This allows you to recursively enumerate source controlled items.

Try this — Don’t worry it’s safe:

Get-TfsChildItem $/YourProject/*  -Recurse

So, from there we can get the server paths of everything in source control. Combine them with some Where-Object, Select-Object and foreach in Powershell along with the TFS command line utility, TF.exe and we have the makings of a solution.

$sites = “WebSite1”, “WebSite2”, “WebSite3”

foreach($item in $sites){

tf get $/MyProject/$item/Dev/

write-host “Renaming directories”

Get-TfsChildItem $/MyProject/$item/Dev/* -Folder | Where-Object { -not $_.ServerItem.Contains(“/WebSite”)  }| Select-Object ServerItem | foreach { tf rename $_.ServerItem $_.ServerItem.Replace(“/Dev/”,”/Dev/WebSite/” ) }

Write-Host “About to checkin”

tf checkin $/MyProject/$item/Dev/ /recursive /noprompt

Write-Host “Renaming root items”

Get-TfsChildItem $/MyProject/$item/Dev/*.*  -Recurse | Where-Object { -not $_.ServerItem.Contains(“/WebSite”)  }| Select-Object ServerItem | foreach { tf rename $_.ServerItem $_.ServerItem.Replace(“/Dev/”,”/Dev/WebSite” ) }

Write-Host “About to checkin”

tf checkin $/MyProject/$item/Dev/ /recursive /noprompt

Categories: Uncategorized