I found that being able to right-click a .sln file and open it as Administrator in Visual Studio is a huge help because I always open solutions by finding the solution file and opening from there, not opening Visual Studio first. Anyway, based on the Elevation Power Toys stuff, I write an “Elevate VS Solution” Power Toy that lets you right-click a .sln file and open it as Administrator.

Download the zip file, extract the .inf file, right-click, install. Standard disclaimers (“works on my box!”) apply.

[Download ElevateVSSolution.zip]

NOTE: I’m no longer maintaining the Command Prompt Round-Up. Instead, visit the Command Prompt Here Generator.

I won’t lie - I’ve been doing most of my development up until now in Windows XP (not by choice) and as I move into Windows Server 2008 territory, there are little gotchas I’m finding as I work as a non-admin user. The one I ran into today is that our build script runs regsvr32 to register and unregister NCover during the build (so different products/projects can use different versions of NCover without having to actually install them). That’s only something an admin user can do.

The problem comes in when I right-click on a folder and choose “VS.NET 2008 CMD Prompt Here” - it’s running as me, not an administrator. Even if I do a runas /user:Administrator "msbuild default.msbuild" from there it’s not doing what I want it to because the environment’s not set up or whatever. Point is, I needed “VS.NET 2008 Admin CMD Prompt Here” so that’s what I made.

I updated my “Command Prompt Here” Round-Up to include “VS.NET 2008 Admin CMD Prompt Here” so you can download that and away you go. It basically just does the runas /user:Administrator before running vsvarsall.bat, but it works great from what I can tell. YMMV.

Something else I found while I was searching to see if someone else had already done this - the Elevation Power Toys over on TechNet. This is a gargantuan array of scripts and installers for everything from “Command Prompt Here (as Administrator)” to “PowerShell Prompt Here (as SYSTEM)” and more. It’s well worth the time to check out - enough so that I’m not replicating all of that in my own roundup. Go ahead and grab those Power Toys. You’ll be glad you did.

I’ve been working on a few projects lately that have a very time-sensitive aspect to them. That time-sensitivity is accompanied by an overly-short planning cycle, so things are being handled in a more “reactive” manner than I like. I’m a “proactive” person, I like a good plan (though it doesn’t have to be a 500 page doorstop, a plan is a good thing).

Every time one of these “reactive” projects gets going, these included, I always re-discover the importance of keeping a cool head. Rather than lighting your hair on fire to run around with the rest of the folks, stop for a second. Step back, assess the situation, and take your time in solving the problem. Don’t waste time, but take enough time to consider all of the angles of the problem in the context of your proposed solution.

When executing on a solution, work fast, but don’t work quick. The difference is important - fast work will get you done while respecting the time-sensitivity; quick work will find you cutting corners and making errors that you wouldn’t normally make.

That’s the crux of this one - take enough time so you’re not making those stupid mistakes that you wouldn’t otherwise make in a less time-critical project. We all know what happens when you do make those mistakes, right? In software, the solution will get sent back from QA (or doc, or - worse - the customer) as insufficient, incomplete, or incorrect. That’s bad news that will actually put you further behind schedule than had you not cut those corners, not made those mistakes.

One of the positive side effects of keeping a cool head in solving the problem is that it’ll reduce some of the stress you might be prone to due to things being “out of control,” which, in turn, will ease some of the interpersonal communication issues that inevitably arise in these situations.

I think it’s time for me to put the fire in my hair out, step back, take a breath, and solve some problems.

This is my first post on the upgraded blog using Subtext 2.1.0.5. After a failed upgrade, I ran through an upgrade on a full staging environment, got it working, and repeated the process in production… huh, I guess that’s sort of what you’re supposed to do, anyway, isn’t it?

I won’t lie; my heart was pounding near out of my chest while I was doing the upgrade, scared I’d have to call upon my web host to restore me from a backup (I don’t have admin access so I can’t do it myself).

Right-o. Anyway, it looks like I’m up and running, which rocks, and I like the new features. Only issue I’ve run into so far: The HTML editor in the admin interface doesn’t really work with Firefox. Specifically, when you try to add a hyperlink to something, the little “edit hyperlink” box pops up, but when you click “OK” the box doesn’t dismiss and the hyperlink gets made into some crazy JavaScript placeholder link. Solution: Post using IE.

If you see soemthing wrong with the site, leave me a comment or contact me (see the link in the navigation bar) so I can see about fixing it.

It’s been a long time in the making, but since the last time I tried to upgrade my blog to the latest Subtext failed so miserably, I wanted to build up a full staging environment and test the heck out of it before trying to do it in production. To that end, I got a Windows Server 2003 VM up and running, complete with my web host’s slightly-customized Medium trust configuration files and a copy of a recent database backup, and ran through the upgrade process.

Turns out it’s a good thing I did it in staging first. I discovered a few things that didn’t upgrade too smoothly so it’s good I caught them.

First, a couple of spots in the web controls changed from List<T> to Collection<T>, which isn’t a big deal but does cause a bit of a headache if you’ve got some custom stuff in App_Code that fails to compile because of that. Again, though, no big deal.

The showstopper ended up being this second problem: While the home page would load fine, going to any individual entry page would yield the Yellow Screen of Death with a FileIOPermission problem in Ssytem.Web.UI.ScriptManager:

Exception Details: System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.

Stack Trace:

[SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.]
   System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet) +0
   System.Security.CodeAccessPermission.Demand() +59
   System.Reflection.Assembly.VerifyCodeBaseDiscovery(String codeBase) +118
   System.Reflection.Assembly.get_CodeBase() +32
   System.Web.Handlers.ScriptResourceHandler.GetCodeBaseWithAssert(Assembly assembly) +31
   System.Web.Handlers.ScriptResourceHandler.GetLastWriteTime(Assembly assembly) +36
   System.Web.Handlers.ScriptResourceHandler.GetAssemblyInfoInternal(Assembly assembly) +58
   System.Web.Handlers.ScriptResourceHandler.GetAssemblyInfo(Assembly assembly) +59
   System.Web.Handlers.RuntimeScriptResourceHandler.System.Web.Handlers.IScriptResourceHandler.GetScriptResourceUrl(Assembly assembly, String resourceName, CultureInfo culture, Boolean zip, Boolean notifyScriptLoaded) +336
   System.Web.UI.ScriptManager.GetScriptResourceUrl(String resourceName, Assembly assembly) +114
   System.Web.UI.ScriptRegistrationManager.RegisterClientScriptResource(Control control, Type type, String resourceName) +115
   System.Web.UI.ScriptManager.RegisterClientScriptResource(Control control, Type type, String resourceName) +9

What the heck?

Turns out Subtext 2.1.0.5 ships with a copy of the ASP.NET AJAX 1.0 System.Web.Extensions assembly in its bin folder. On a system with .NET 3.5 SP1 installed, you don’t want the old one - you want the new one, particularly since it’s in the GAC and will run with Full trust.

To fix the issue, I deleted the local copy of System.Web.Extensions.dll from the bin folder and added the following bindingRedirect to the web.config file:

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Extensions" publicKeyToken="31bf3856ad364e35" culture="neutral"/>
        <bindingRedirect oldVersion="1.0.61025.0" newVersion="3.5.0.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Done and done. After that, everything seemed to work perfectly. There are a lot of new featues in Subtext 2.1.0.5 that I’m looking forward to taking advantage of, so now I’ve got to schedule some time to do the upgrade. Probably not this weekend - I really want to take it easy. But soon.