Aug 26
Controlling IIS7 remotely with PowerShell
icon1 Darrell Mozingo | icon2 Misc. | icon4 August 26th, 2010| icon31 Comment »

Our deployment script needed to do some basic IIS administrative tasks remotely on a Windows 2008 (non-R2) server, which runs IIS7, recently. Finding the information and fiddling around with it took me a good day and a half, so I thought I’d post the steps here to help someone else (more than likely myself) in the future:

  1. Download the Windows Management Framework Core package for your setup
  2. If your machine is something older than Windows 7 or Server 2008 R2, you’ll need to get the PowerShell IIS7 Snap-In
  3. If your workstation/build server and target web servers happen to be on different Windows domains, you’ll need to run this one time on each client machine:
    Set-Item WSMan:\localhost\Client\TrustedHosts *
  4. Run this command once on each server:
    winrm quickconfig
  5. You’ll need to load the PowerShell Snap-In once on each client, which differs depending on which version of Windows you’re running. Anything older than Windows 7 or Server 2008 R2:
    Add-PSSnapin WebAdministration

    Windows 7 and Server 2008 R2 run:

    Load-Module WebAdministration
  6. Check if it’s working properly by running this command on any version of Windows (you should see the IIS7 Snap-In listed):
    Get-Module -ListAvailable
  7. Get credentials for accessing the remote server
  8. Start running some remote commands on your web servers:
    Invoke-Command -ComputerName "webserver_computerName" -Credential $credentials_from_last_step -ScriptBlock { Add-PSSnapin WebAdministration; Stop-Website IIS_Site_Name }

It’s not really that hard once you get the proper packages installed and the permissions worked out, and since it’s so powerful and useful for scripting purposes it’s well worth the trouble. The available commands are awesome for use in automated deployment scripts.

You can learn more about the PowerShell Snap-In provider here, and at its download site here.

Aug 19
Clever vs Explicit
icon1 Darrell Mozingo | icon2 Musings | icon4 August 19th, 2010| icon31 Comment »

When we all start out developing, either through classes in high school/college or slowly on our own time, we inevitably want to write code thats super clever. Like, use-3-lines-to-express-what-used-to-take-20-lines type of clever. We see less code and we’re pleased. All is good and well with the world.

Until you look at that code a few months down the road and wounder what the hell you were smoking, and it takes you almost as long to decipher it again as it did to write it in the first place. All of a sudden saving those few extra lines of code don’t seem so smart, huh?

The simple fact of the matter is you spend more time maintaining code than you do writing it in the first place, so being more explicit in your code always trumps being clever to save a few lines. Always.

There’s the obvious places where people get clever, like algorithms or loops, but there’s plenty of other places too. Places where I wouldn’t really call it “being clever”, or at least I’m sure the original authors never thought they were trying to be clever when they wrote it. It was probably just quicker to write it in a certain way. For example, take this code:

var mappedEmployees = new List<EmployeeViewModel>();
foreach (var employee in _employeeRepository.All().Where(x => x.IsRetired == false && x.Salary > 100000))
return View(mappedEmployees);

It’s not really hard to read, but it’s not really easy either. It might take you an extra second or two to figure out what’s going on when you first look at (even if you wrote it a few months ago), but multiply that by how many places you see code like this and how often you go back in to modify it (for new features, bugs, whatever). It adds up, quick. Written more explicitly, it might look something like this:

var mappedEmployees = new List<EmployeeViewModel>();
var nonRetiredHighEarningEmployees = _employeeRepository.All().Where(x => x.IsRetired == false && x.Salary > 100000);
foreach (var nonRetiredHighEarningEmployee in nonRetiredHighEarningEmployees)
	var mappedEmployee = _employeeMapper.Map(nonRetiredHighEarningEmployee);
return View(mappedEmployees);

You might call it verbose, but I’d say it’s a net gain. Each line is doing one thing. Yon can step through and read it without mentally pulling pieces apart. None of this “OK, that’s the mapped object call there, and its return is going into the collection there, and the whole thing is looping through that query there”. Things are given names and methods aren’t nested inside each other.

Always be on the lookout for “clever” areas in your code. Be explicit. Try to stick to each line doing one thing so there’s no hidden surprises.