Today I decided to check my credit score.  Immediately, I thought of FreeCreditReport.com.  I went there and filled in all the appropriate information.  Then I was asked for my credit card number.  Credit card number?  I thought it was free?  Just to be sure that my idea of free is a correct one, I checked dictionary.com for the definition related to price/cost.  Here it is:

Yep, that's what I thought it meant.  Hmmm...  So the deal was, there was a 7 day trial period, after which they would automatically charge you the monthly fee for "Triple Advantage" membership.  Ok...  Maybe they meant "free" as in free to cancel before you're charged?  Anyways, after reviewing my credit report I tried to do just that.  I could not find anything on their website about how to cancel.  Finally, I clicked "Contact Us" where I found a "FAQ" with the question "How do I cancel my membership?".  Here's, in short, what it said:

What??  You mean I have to call to cancel?  Pssh.  Figures...  But I sent them a lovely e-mail instead:

What, seriously, has this world come to?  Free should mean free.  Free of cost, and free of obligation to cancel within 7 days to avoid being charged.  And if you can register online, you should be able to cancel online.  There should be a law to that effect...

I knew this day would come.  The day I forget the "where" clause of an SQL delete or update statement and delete or update every row in a table.  Here's the code I used:

update tblNCM
set CLOSED = 0, CLOSED_BY = null, CLOSED_DATE = null

Imagine my dismay when SQL Server Management Studio reported that this statement affected 970 rows!!  Here's what I meant to put:

update tblNCM
set CLOSED = 0, CLOSED_BY = null, CLOSED_DATE = null
where NCM_NO = 980

Yes, this was only supposed to affect one row.  So I inadvertently re-opened all of our NCMs and deleted all the closed by and closed date values.  Great.  All I have to say now is thank God for backups!  In this case, it might have cost me my job!  But, within 20 minutes I was able to restore yesterday's backup to a temporary database, copy all of yesterday's values, and check the change log for any NCMs that were closed since yesterday.  Whew!!  In any case, though, the real issue here is that it is too easy to affect every row in SQL.  For select statements, that's ok.  It doesn't cause any damage to select every row.  But had I designed SQL, I would have made it so you would have to explicitly indicate that every row is intended with update and delete statements instead of assuming it when the where clause is missing.  Something like:

update all MyTable
set MyField = 'Value'

Or, even better from a programmer's mindset, make the where clause required:

update MyTable
set MyField = 'Value'
where true

Ok, ok, so "true" isn't exactly an SQL keyword, but it looks so much better than "where 1"...  In any case, I've never liked the SQL language as a language.  This is just one reason why.  It does not communicate intent very well.  For instance, look at my first code snippet above.  How well does that communicate that you intend to update every row?  From the way it looks to me, it seems like CLOSED, CLOSED_BY, and CLOSED_DATE would be scalar variables.  In any other programming language, when you put "set CLOSED = 0", CLOSED is a single variable with a single value.  There is no loop indicated in the language that would iterate every row and update multiple variables.  But when you say "where" afterward, then it implies that changes are made in possibly more than one place.  Omitting the "where" clause omits the part that implies that multiple rows are affected; therefore, the statement doesn't make sense.

"But I'm a lazy programmer," you might say, "and I don't want to have to write 'where true' every time I want to update or delete every row."  What, though, really, is more important?  Saving a few keystrokes?  Or avoiding a situation where a small oversight on your part could cost you your job during a time of economic hardship?  Or, from a less selfish standpoint, avoiding data loss, lost work, potential bugs, etc.?  Fortunately, we do daily backups.  But what if this was a database that was updated thousands of times a day?  Everyone's work on a particular table that day could potentially be lost because of a minor mistake.  Ugh.

For those of you who don't already know, Windows PowerShell is a command shell that pipes .NET objects between commands instead of text.  You can use it to directly create and manipulate full-fledged .NET objects with the entire .NET Framework at your disposal.  It's sort of like a live .NET programming language where your statements are executed line by line as you type them.

So I was writing a class library and got to a point where I wanted to test it.  I could have written a small test application or a unit testing project, but it occurred to me:  What if I just used PowerShell?

Working with your class library in PowerShell

As far as I know, PowerShell doesn't have any Cmdlets or other mechanism specifically for loading external libraries.  But, it doesn't need one!  Remember, you have the entire .NET Framework at your disposal.  A simple call to the System.Reflection.Assembly class will do the trick.

[Reflection.Assembly]::LoadFrom("MyLibrary.dll")

You could capture the resulting Assembly object in a PowerShell variable if you want, but all that is needed is to load it into the application domain of PowerShell, which is exactly what this method does.  Now that it's loaded, you can access your types the same way you otherwise would in PowerShell:

[MyNamespace.MyClass]::MyStaticMethod()
$obj = New-Object "MyNamespace.MyClass"

Setting up Visual Studio

Of course we want to easily start debugging by pressing the "Play" button, and we want Visual Studio to be able to pick up breakpoints and detect exceptions.  Also, we want some PowerShell commands to be executed automatically every time, such as the one that loads the library and possibly some that instantiate some test objects for you.  I opted to create a PowerShell script file in the project folder called "Debug.ps1".  Setting the project's properties in Visual Studio to get it to work, though, was tricky.

Under the Debug tab in the properties for the class library project, select the "Start external program" option.  Browse for powershell.exe.

Now for the command line arguments.  Here's what I used:

-noexit -command . ..\..\debug.ps1

First, "-noexit" specifies that PowerShell is not to exit after the command is executed.  We want this so that we can type our own commands after the initial script is executed.  Second, "-command" specifies that the rest of the command line arguments is actually a command to be executed.  The command is ". ..\..\debug.ps1".  However, if you use quotes, it will think the quotes are part of the command which will make it simply think it's a string, not code to execute.  The initial dot is there so that the script is "dot-sourced".  "Dot-sourcing" a script means that it executes in the current runspace instead of a new one.  This way, any variables set by the script will be preserved so they can be used afterward.  Finally, if you don't specify a working directory, Visual Studio defaults to the output directory for the project.  I kept it this way in case the project is copied to a different directory; for example, if it were added to source control and someone downloaded it to a different local directory.  So to reference the script that exists in the project directory, I used "..\..\" since the current directory is in \bin\Debug inside the project directory.

Here's an example of what your debug.ps1 script might look like:

# Since the current directory is the output directory for the project, simply pass in the name of the DLL file:
$assembly = [Reflection.Assembly]::LoadFrom("MyLibrary.dll")

# Here's how to create an object using a constructor with two arguments:
$testObj = New-Object "MyNamespace.MyClass" -arguments "First argument.", "Second argument."

And as I mentioned before, since the script is "dot-sourced", the variables $assembly and $testObj will remain after the script is done executing.  Also, if you haven't tried to run scripts in PowerShell yet, you might run into a security issue.  Simply type "set-executionpolicy RemoteSigned" into PowerShell to allow unsigned local scripts to execute.