Technical How-To's

Puzzling Issue Involving Reflection and MbUnit

Russell Ball — Fri, 21 Dec 2007 16:09:55 GMT

I just sent the following email to the BCL (Base Class Library) Team Blog email address in hopes of getting some insight into a weird problem we've been having.

I was hoping you could give me some general guidance on how Type.GetProperties() determines the sequence of the PropertyInfo objects it returns.

I just ran across this remark on MSDN about the order that Type.GetProperties() returns PropertyInfo objects

The GetProperties method does not return properties in a particular order, such as alphabetical or declaration order. Your code must not depend on the order in which properties are returned, because that order varies.

We have parsing code that uses the 1.1 framework which is dependent on the order in which properties are returned. It fails intermittently when run as part of a suite of MbUnit tests. After seeing this msdn remark, I changed the code to remove the sequence dependency and the MbUnit intermittent failure problem disappeared. This led me to believe that properties were sometimes being returned in an order other than what we expected (the order they were declared in the code files).

Normally we are not allowed to make production changes this time of the year unless the issue is critical, so we are trying to determine the likelihood of this causing production issues. The problem is that we get contradictory results based on how we test this. If I wrap the method in a hundred thousand loop iteration, then I can’t reproduce the error in MbUnit. The properties always return in the order in which they are declared in the class file. However, if I run the whole suite of tests several times in succession, then I receive random errors that seem to derive from the sequence being returned in a different order.

Is there some internal algorithm that might trigger a different sequential order to be generated based on some unique condition that running the whole MbUnit suite of tests as opposed to running them in a large loop would cause (i.e. a certain number of threads or memory/cpu pressure)?

Any insight you could offer in this problem would be greatly appreciated.

Thank you,

Russell Ball

Does anyone else have any ideas?

** Update **

We no longer get these failures in MbUnit if we revert it to the 1.1 framework by changing the supported frameworks node in the config file as described here. I'm guessing they changed the algorithm in the 2.0 framework that is used to determine the sequence.

That still doesn't explain why there is a difference between calling our code in a massive loop versus calling it as part of a suite of tests, but at least it puts our minds at ease with respect to the risk of intermittent failures occurring in our current production code.

Friends Don't Let Friends Use the Start Menu

Russell Ball — Sat, 15 Dec 2007 06:35:48 GMT

I've read and listened to Scott Hanselman sing the praises of SlickRun for a long time, but I just recently got around to using it.

For those of you who are as slow to catch on as me, it is essentially just a tricked-out version of the Run window that allows you launch programs much faster than you can through the traditional hide-and-seek start menu approach. This is especially true if you are a tool addict and have a start menu that stretches across your screen.

Best of all, it is FREE, which is one of the few things that still fits into my budget these days. It also only takes seconds to grok and begin saving time with it.

To get started, all you have to do is right-click on the floating SlickRun textbox and select "New Magic Word". When the dialog box with the nifty wizard hat pops up, you simply drag the magic geen lightsaber circled below over to an open program and it will figure out the program's filepath. You can also create the mapping by just dragging a shortcut from the start menu on to the floating SlickRun textbox prompt.

Next, you think of a clever and creative keyword (for example NCoverExplorer for NCoverExplorer) and then optionally assign paramters to it. Parameters are cool because you can do things like open FireFox and surf to your favorite porn site in one swift and efficient motion. For NCoverExplorer, I set the parameter value to the path of the NCover xml result file that gets generated from our automated build process.

Finally, thanks to the magic of intellisense, you just have to type a couple of letters until the keyword you want appears in the textbox and then hit return in order to launch it. Easy, huh?

Just remember, REAL geeks don't use the start menu. If you don't want all the other geeks laughing at you and kicking silicon dust in your face in the computer lab, then I suggest you download SlickRun immediately.

Helpful Configuration Hints

If you're used to Windows-R to launch programs, you can change the default SlickRun hotkey (Windows-Q) to this more familiar one by setting GrabWinR=1 in the slickRun.ini. You can find this config file in your computer's app data directory (directory locations vary based on the OS), but it won't actually be created until you close SlickRun for the first time.
I also like turning the ChaseCursor option on so that launcher window pops up where ever your cursor happens to be after hitting the hotkey combination. This saves me from having to shift my focus to a different part of the screen... Yes, I know that it seems lazy beyond words to recommend a feature just because it saves my eyeballs from having to move a few centimeters.

Notes about Vista

SlickRun is not quite as compelling on Vista because of the built in launcher in the Vista start menu. However, I still like using it on Vista because it offers more flexibility in terms of creating more logical words for program names as well as automatically passing in parameters to the program.
Setting up magic words by dragging shortcuts from the start menu to the SlickRun prompt doesn't work on Vista for some reason.

Interesting SlickRun Factoid

This was actually written in Delphi. I'm going to let you come up with your own Delphi jokes so as to avoid any hate mail from either one of the remaining Delphi programmers out there.

Don't Forget to Verigoogle

Russell Ball — Tue, 18 Sep 2007 04:36:20 GMT

I knew that SQL Server 2005 had structured exception handling, but for some reason I assumed that you could only use it within CLR sprocs. Since I still haven't actually heard of anyone using CLR sprocs for anything other than demos or sample projects (at least not without being pummeled by hoards of angry DBA's), I mostly ignored this new feature until now.

Today I worked on a sproc that involved over a dozen DML statements (it was a utility sproc to handle security and setup steps for developers as part of our build process, so there is no need to chastise me about it being bad design to have so much logic in the database). The thought of copy-pasting dozens of tedious procedural error handling code snippets was so distasteful to me that I decided to do a quick verigoogle. Verigoogling is my freshly coined word for challenging one of my assumptions through google. I was delighted to discover that this new Try/Catch syntax is available to the masses to be used in plain vanilla sprocs. Instead of checking the @@error variable after each statement, we can now be lazy..er..I mean concise and consolidate all the error handling code into the catch block like we're used to doing in good ole' OOP code.

For those of you like me who haven't been taking advantage of this new feature yet, here is some sample code that demonstrates the how easy it is to use. As for the rest of you, please restrain yourself for making fun of me and go verigoogle one of your own assumptions.

BEGIN TRY

BEGIN TRANSACTION

DELETE FROM table1

DELETE FROM table2

COMMIT

END TRY

BEGIN CATCH

IF @@TRANCOUNT > 0
ROLLBACK

     DECLARE @ErrMsg nvarchar(4000), @ErrSeverity int
     SELECT @ErrMsg = ERROR_MESSAGE(),
   @ErrSeverity = ERROR_SEVERITY()

RAISERROR(@ErrMsg, @ErrSeverity, 1)

END CATCH

Confessions of an Aero Addict

Russell Ball — Mon, 13 Aug 2007 17:18:41 GMT

When given a choice between style and substance in software, I usually opt for what I consider to be substantive qualities such as speed, functionality, usability, and cost. Since I never saw a sentence about Vista without the phrase "eye candy", I casually dismissed Microsoft's long-awaited OS release as fluff when it first came out and was in no hurry to jump aboard the upgrade band-wagon.

Well despite my valiant effort at indifference, I am ashamed to admit that I have finally succumbed to the narcotic affects of the Aero and was compelled to upgrade both my work and home PCs to Vista last week. After less than a week, I now experience acute withdrawal symptoms every time I sign back onto an XP machine and am deprived of my glass translucency goodness. I could talk enthusiastically about some my favorite non-visual features in Vista, such as the pervasive search box (ctrl + esc) that I now use in lieu of Google Desktop to quickly find content and launch programs, but who am I kidding? My name is Russell Ball and I am an eye-candy junkie.

For those of you who are weak like me and are considering an upgrade in the near future, here are a few things to keep in mind.

At the Office

If you're going to take advantage of an MSDN license and upgrade your OS well ahead of the crowd, make sure you're nice to the IT Pro group. I got their blessing ahead of time by offering to give them a scouting report of any issues they will likely encounter when trying to upgrade the entire department.
When encountering an application error in Vista, try restarting the app using the right-click 'Run as Admin' option. Several rather cryptic errors have miraculously disappeared after re-opening the app under elevated priviledges.
<tongueInCheek>Go paperless</tongueInCheek>. The IT Pros in my shop are understandably reluctant to risk upgrading drivers on the print server just for me, so I am currently remoting in to the dev box to print documents until I can get someone to punch a whole in the dev domain firewall and let me connect directly to the printer.
Expect to have to spend a little time applying a new service packs and installing new versions of applications. PowerShell requires a new version and Visual Studio and SQL Management Studio both require service pack upgrades before they will properly work on Vista.
Expect a few apps to not work. I had to turn off a visual affect in order to get the UltraMon title bar butttons to show up and shut down the Track-It agents on my machine to stop getting bombarded with error messages. Transcender won't work at all, so I'm having to remote into the development server to take practice tests for my upcoming certification exam. Considering that I probably have a hundred apps installed on my machine, that's really not that bad.

At Home

If you have a machine that is more than a few years, just let it go. I had a P4 that worked fine for remoting into the office and web browsing, but it was easier to just spend the $800 at my local computer store for a basic machine than fuss with tracking down incompatible parts as part of the upgrade process. After a quick $150 upgrade for a new video card that supported dual monitors, I found myself with a Windows Experience Score of 4.8 (not bad) and enough RAM, disk space, and processing cycles to power a small third world country.
When your wife sees the bill for the new PC, cast an “Aero Translucent Glass” spell on her. If she isn't fully distracted, try the alt-tab spinning windows trick. If that doesn't work, then try defending yourself with one of the countless left-over non-Vista compliant parts that will soon litter the tech landscape.

See you at the Vista half-way house.

The Open Source Side of Powershell: PSCX

Russell Ball — Fri, 27 Jul 2007 04:38:01 GMT

One of my goals for the next six months was to contribute to an open source project and I think I've chosen one. I downloaded and installed the PowerShell Community Extensions (a.k.a. pscx) from codeplex a while ago, but I just now got around to really tinkering with the cmdLets and reviewing the source code and scripts. I have to say I'm impressed. Keith Hill and his team of volunteer developers did a first rate job of supplementing version one of Powershell with some really useful cmdlets. I can't wait to dig into the source code some more and figure out how the snap-in model works.

Here are a few of my favorite features:

Provider:

GAC Provider - It's a little slow when it first loads up, but it is very helpful to be able to easily navigate around in the GAC and do wildcard searches on version numbers.

CmdLets

Get/Stop-TerminalSession - It seems like every couple of weeks I have to kill a remote terminal services connection on one of our development servers because someone forgot to log off and pushed us over the two simultaneous users limit. This cmdlet is a lot quicker than loading up the administrative GUI and will help make the experience much less aggravating.
Write-Zip - This will be very useful addition to backup/archiving scripts. At home, I just did the following: dir "G:\Music\Radiohead\Pablo Honey" | write-zip
Get-FileVersionInfo - We just started auto-versioning all of our dll's during our build process and set it up so we can match the version of a dll in production with a build directory on our build server. I'm sure we'll be asked to create some automated way to help auditors figure out the version numbers and this will definitely help.
Set-Writeable - This just removes the Read-Only flag from files, but it would have come in handy last year when we had to upgrade several projects to the 2.0 framework and move them from VSS to TFS. Removing a project from VSS is painful and one of the more tedious steps is clearing the read-only flag on all the source files. I remember wasting an hour of my life writing and debugging a VBScript because the right-click/recursive method never seemed to fully work.
Out-Clipboard - One of the things that still sucks about working in the shell environment is the editing capabilities, especially when it comes to copy and pasting. When I want to transfer the results of a command to an email or word doc, I simply pipe it to this cmdlet.
Send-Smtp - This will be great for the error-handling notification part of scripts. It would be even better if I could figure out how to populate the body parameter from the pipeline.

You can get a list of the 59 new cmdLets added when installing this snap-in by calling the function gcmpscx.

Using Powershell with SQL Server

Russell Ball — Wed, 25 Jul 2007 12:24:13 GMT

Anything that can be done with ADO.NET is possible in PowerShell through a call to Assembly::Load and the New-Object cmdLet, but that doesn't mean that the resulting code will seem very shell-like or practical. Two approaches to database access that definitely do seem compelling to me, however, are the sample SQL Provider recently demoed by the PowerShell team and Dan Sullivan's PowerSMO script, which is really just a thin wrapper around the SQL Management Objects found in the Microsoft.SqlServer.Management.Smo namespace. The SQL Provider allows traditional command line navigation through the database using dir and cd and the SMO objects provide access to nearly any administrative function in SQL Server.

In order to use the PowerShell team's SQL Provider, you'll need to download SQLProvider.dll, install it in the GAC, and call the Add-PSSnapin cmdLet. Then you can treat the database just like the filesystem and cd or dir your way around with statements such as the following:

PS>cd SQL:

SQL:>cd MySQLServerName

SQL:>dir

master
tempdb
model
msdb
pubs
Northwind

SQL:>cd Northwind

SQL:>dir

name
----
Categories
CustomerCustomerDemo
CustomerDemographics
.. etc...

SQL:>cd Employees

SQL:>Dir -filter {where EmployeeId=8}

EmployeeID : 8
LastName : Callahan
...etc...

Unfortunately, this provider is only a partially implemented sample and I quickly lost interest when I figured out that I couldn't easily or naturally pipe the results to the where, select, and sort cmdLets. I did some quick searching to see if someone else had taken the next step and fully implemented a sql provider but I didn't come across anything. However, I'm sure it won't be long before somebody creates a production-ready version. The PS team did include the code for their sample provider, so perhaps I'll take a look at it myself to see how hard it is.

To run the PowerSMO examples found on Dan Sullivan's blog, you simply need to run a powershell script or place it in your profile so that it is run automatically when you start the shell. The script preloads some required dll's and provides a factory function for retrieving some of the key objects, so retrieving a server object feels more like a cmdLet experience.

$server = get-SMO_Server mySQLServerName

However, since he warns that his script is for instructional purposes only, you might also just want to load the server object directly:

[System.Reflection.Assembly]::Load("Microsoft.SqlServer.Smo,Culture=Neutral,Version=9.0.242.0,PublicKeyToken=89845dcd8080cc91") | out-null

$server = new-object "Microsoft.SqlServer.Management.Smo.Server" myServer

Then you can grab a database object and do interesting things like finding which tables and indexes in your database are taking up the most space.

$pubs = $s.databases | ?{$_.name -eq "pubs"}

$pubs.tables | ?{$_.name -notlike "sys*"} | select name, dataspaceused,indexspaceused,@{name="Total Space";expression={$_.dataspaceused + $_.indexspaceused}} | sort dataspaceused -desc

...or finding out the firve widest tables in the database as potential candidates for normalization and save it to an html file.

$pubs.tables | ?{$_.name -notlike "sys*"} |select name, @{name="Columns";expression={$_.columns.count}} -first 5 | sort columns -desc | convertto-html > C:\wideTables.html

Again, you can do almost any of these functions through some other way (system sproc, sql function, utility), but what is significant is the capabilities that powerShell gives you to be able to manipulate the resulting data once you have it (sort, group, filter, format, etc.).

Disk Space Management with Powershell

Russell Ball — Fri, 20 Jul 2007 13:36:04 GMT

The more I work with powershell, the more I start seeing everything that lives on the computer as part of a giant database that I can query. When used in conjunction with the pipeline and get-member -type property to discover the available properties on an object, the where-object, sort-object, select-object, and group-object cmdlets can be strung together to answer some very sophisticated questions. We often seem to run out of space on our development sql servers, so one tedious question that I am often forced to answer manually or with a utility such as windirstat is which sql backups are taking the most space so we can delete unused ones and free up space. This question can be answered easily and quickly in one line from powershell and then exported to text, csv, or html so that it can be sent to anyone else that needs to assist in the decision making process. In fact, with an extra line of code you could easily load up the .NET SMTPClient class in system.net.mail and email the output without leaving the command line. Here is the powershell one-liner that I used to find the largest 10 backups on a development server and save the output to a text file:

Dir \\devsql\sqlbackups *.bak -rec | sort length -desc | select name,directory, @{name="Size in GB";Expression={[System.Math]::Round($_.length/1073741824,1)}},CreationTime -first 10 | ft -auto > C:\LargeBackups.txt

This produces output that looks something like this:

Name                                      Directory                   Size-GB   CreationTime
----                                           ---------                          --------       ------------
LendingHistory.bak              \\devsql\sqlbackups\Dev03       7.5     0/27/2006
Lending0702.bak                 \\devsql\sqlbackups\Dev01       6.2     06/29/2007
LendingPostEOD0628.bak   \\devsql\sqlbackups\Dev01       6.2     06/29/2007
LendingSOD0628.bak          \\devsql\sqlbackups\Dev01      6.1      06/12/2007
LendingSOD0627.bak          \\devsql\sqlbackups\Dev01      6.1      06/29/2007
Lending.bak                        \\devsql\sqlbackups\Dev02      6.1      11/27/2006
Investments.bak                  \\devsql\sqlbackups\Dev02      6.1      05/23/2007
InvestmentsHistory.bak        \\devsql\sqlbackups\Dev02     6 1       1/27/2006
Warehouse.bak                   \\devsql\sqlbackups\Dev01     5.9        04/25/2007
Lending.bak                        \\devsql\sqlbackups\Dev01     5.9        10/27/2006

How To Log On To A Web App With One Keystroke Using Powershell

Russell Ball — Wed, 18 Jul 2007 17:56:33 GMT

I'm doing some work now on an internal web application where I had to logon with an external test account before I could do anything. That got old fast, so I created a powershell script file to automatically launch IE, input the username and password, and click the submit button. I originally tried to do this with WatiN, which provides a much easier interface for controlling the browser than the COM object InternetExplorer.Application, but I couldn't get by the security exceptions explained in this Scott Hanselman post. I then added a keystroke shortcut in WinKey to execute this ps1 file via the hstart utility so that no command window would flash on the screen before the browser window could load. It's probably not the cleanest solution, but it has been a huge time and annoyance saver.

Here's the winkey info

command: <<local path>>\hstart.exe
parameters: /nowindow "C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe -command ""&" 'C:\myScriptsDirectory\launchWebApp.ps1'""

...And the powershell script

$psie = new-object -com InternetExplorer.Application
$psie.Navigate2("http://www.someWebApp/")
$psie.visible=1
($psie.document.getElementsByTagName("input") | where { $_.Name -eq "UserID"}).value = "userID"
($psie.document.getElementsByTagName("input") | where { $_.Name -eq "Password"}).value = "password"
($psie.Document.GetElementsByTagname("input") | where { $_.Value -eq "Login"}).click()

A Powershell Inspired Prank

Russell Ball — Fri, 13 Jul 2007 14:03:24 GMT

Here is a good joke to play on one of your developer buddies if they have powershell and SQL Server installed on their local machines and you have sa rights on the SQL Server for whatever reason (former debugging help, open environment between developers, blank sa password, or mad hacker skills on your part). Wait until they are busy typing and execute the following query in Query Analyzer (or using sqlcmd.exe if you want to be a purist) against their SQL Server. You may want to lock down your own machine before trying this in order to avoid certain retribution...:-)

master..xp_cmdshell "powershell.exe (new-object -com 'SAPI.spvoice').speak('Ouch. You are typing too hard')"

This is a little more difficult with SQL 2005 because remote connections and xp_cmdshell are both disabled by default for obvious security reasons. You can enable remote connections by adding exceptions to the windows firewall for SQLServer and SQL Browser as described in the following KB article. You can enable xp_cmdshell in SQL 2005 with the following script:

EXECUTE sp_configure 'show advanced options', 1
RECONFIGURE WITH OVERRIDE
GO
EXECUTE sp_configure 'xp_cmdshell', '1'
RECONFIGURE WITH OVERRIDE
GO
EXECUTE sp_configure 'show advanced options', 0
RECONFIGURE WITH OVERRIDE
GO

If you're really itching to do this prank but they don't have Powershell or SQL Server installed, there are still lots of options. All you really need is a way to shell out a command against someone else's computer since the underlying voice capabilities come from a COM component, which you can call from vbs script. Have fun...

Learning Powershell Without Leaving the Command Line

Russell Ball — Tue, 10 Jul 2007 12:48:16 GMT

I've been impressed by the attention paid to discoverabiltiy in powershell, which has allowed me to quite a bit of learning without ever leaving the command line. Here are a few of my favorite features:

Guessing - This may seem strange to list as the number one discoverability feature, but I think the Powershell design team did an excellent job of exposing functionality through well scoped cmdLets that are logically and consistently named. With cmd.exe, the majority of the heavy lifting is done by executables with terse names that have become bloated with too many responsibilities so that you have to constantly rely on references to figure things out. In powershell, the verb-noun pattern is strictly enforced and the names are always consistent so that I can write Get-Command *service and be assured that I will get all the cmdLets related to services and then figure out what they do through the verb part of their name.

Built-In Help - If you're not sure what a cmdLet does, then use the Get-Help cmdLet to see the documentation. DOS exes usually have a ? switch for help, but what really makes this powershell feature shine are the -full and -example switches that bring back detailed examples and additional notes about usage and each of the parameters. The powershell team also embedded plenty of conceptual help outside of cmdlets that follow the about_ pattern. You can see them through Get-Help about_*.

Trusting Operations - Are you afraid to execute a script because you're not sure what it will do? Try the -whatif parameter that is ubiquitous to all commands. For example, del C:\f*.txt -whatif will just tell you which files would have been deleted rather than actually deleting them.

Get-Member - I find this cmdLet most useful when I'm not sure what object I am getting back from the pipeline. I simply add | Get-member to the end of the command and I can see what additional methods I have to work with or what properties I can perform filtering and sorting on.

Get-Alias- I love all the transitional and convenience aliases provided by powershell to maximize productivity for throw-away, administrative tasks, but sometimes it makes it hard to decipher examples that you see on the web. Calling Get-Alias gps will return the full, logical name of the cmdLet and will usually allow you to figure out its function. Better yet, use this command with no parameters to return all the aliases so you can learn them and increase your own command line speed.

Other resources - Despite all these great features, it would be silly to not also seek outside resources. Here are a few that I've found helpful

WebCasts - I've made my way through 2 of the 5 Powershell Week web casts. They are a little long (usually over an hour), but are full of good information and perfect for the visual learners.

Blogs - The best is probably the one put out by the Powershell Team. I also recommend Keith Hill and The Powershell Guy.

PodCasts - I highly recommend the all 3 shows that Scott Hanselman did on the subject. The Powerscripting Podcast is a little too slow paced for my taste, but it could be good if you're brand new and want something to listen to while mowing the lawn.

Tutorials - The Powershell Owner's Manual on the technet script center isn't bad, although the authors went a little overboard at times to make the writing more interesting than the average tech spec.

Books - I agree with Chris Sells and Don Box that books are still the best way to grok the zen of a technology. I'm finishing up with an excellent book by the Powershell Developer Lead, Bruce Payette, called Powershell in Action that I would highly recommend.