Update: What Internet Explorer 9 needs in order to make me switch from Chrome

I may as well post an update now that I’ve used IE9 for a couple weeks now.  (Also, Dimitri hassled me about it.)

The verdict is that IE9 is a great improvement over IE8.  In fact, I don’t even need to follow that up with a “but I’m still not going to use it because…”  In fact, I use it about as often as I use Chrome now.  I generally switch back and forth depending on which happens to be causing me trouble at any given time.

But to address my criteria:

1. Spell-check

Still absent, annoyingly.  It’s 2011.  Supposedly it can be included via some plug-in which was not immediately obvious when I tried to find it.  If I open the “Manage Add-ons” window, I see nothing in the list that shows any indication that it’s spell-check-related.  Even when I click the link to find more add-ons online, I’m directed to some pretty-but-unusable web site which allegedly should allow me to search for add-ons, yet when I click the Search button, it merely opens to an unusable tiled list of addons (none of which I need) with no search text field to speak of.  I clicked Search, not Browse.

2. Tab-dragging/removal/insertion

Excellent, works well.

3. The ability to switch to another tab while the previous tab is loading/rendering content

Also excellent.  I was really skeptical about MS getting this one in.  It’s one of those features that rarely finds itself in a design spec, and yet is vitally important to user perception of performance.

4. More efficient URL auto-completion

It seems to work exactly as in Chrome now, which is excellent.

 

So there you have it.  I still use both Chrome and IE, and I may lean toward Chrome but whenever it fails for some reason, I don’t hesitate to switch to IE.  At any given time I seem to have tabs open in either browser.  Oh, and having Windows 7 jump-list preview-whatever-you-call-it support is nice, too.

Performing a Simple Build Task with the Microsoft stack

First of all, I hate it when the term “stack” is used in this context.  Speak in plain English, people.

Now on to the issue at hand.  I have a Visual Studio 2010 solution I want to build.  Because of limitations in Visual Studio’s ability to customize builds of different configurations (e.g. Debug vs Release), I have to execute a custom build step to mess with some of my project files before they get built, and do some custom stuff depending on whether I’m running the Production or Development configuration.

This is fine; at this point I’ve come to terms with Visual Studio’s limitations and will gladly write some hacktastic pre-build step.  So, being the good citizen that I am, I consider alternatives for approaching this:

1) I can write a custom C# console app to do whatever it is I need to do.

2) I can use the BATCH language or some ancient WScript script or something.

3) I can use this newfangled PowerShell thing I keep hearing about (I say “newfangled” despite it being several years old).

#1 would work fine, but the nice thing about scripts rather than built executables is that you can modify them on-the-fly; the source code is right there at your fingertips.  In short they’re transparent.

#2 might also work fine, but this is an older and more convoluted technology and the solution may be more roundabout.

#3 PowerShell sounds like the perfect combination!  I can allegedly execute .NET code in a script!

So, after wading through the horrendously over-complex MSDN documentation which takes about 10 minutes of wading through links before you can see a concrete code example, I gave up and utilized my handy-dandy Safari Books Online subscription to virtually crack open a book about PowerShell.  The explanations were clear and I was finally ready to test out a simple code example, written into a custom .ps1 file that I created.

So, I tried running it and… FAIL. 

File [myscriptfile].ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about_signing" for more details.

Oh, that’s just great.  I read the wall of documentation.  Not only is the execution of scripts disabled, but to enable them in a way that wouldn’t unduly molest other people’s systems when they ran this step would require me to actually sign my script with a certificate.  In short, are you F’ing kidding me?  I want to run a script on the systems of a handful of people who assumedly trust me, and I’ve got to go through convoluted steps of signing my script, having my coworkers manually allow this thing to run, likely introducing extra confusing steps in the build process?  No.  Not acceptable.  Once again, #1 is looking like the best option despite its drawbacks.