Sep 29

UPDATE: See Paul’s comment below – sounds like the latest cygwin upgrade process isn’t as easy as it used to be.

If you install GitExtensions, up through the current 2.24 version (which comes bundled with the latest msysgit version 1.7.6-preview20110708), and use OpenSSH for your authentication (as opposed to Plink), you’ll likely notice some painfully slow cloning speeds. Like 1MB/sec on a 100Mb network kinda slow.

Thankfully, it’s a pretty easy fix. Apparently msysgit still comes bundled with an ancient version of OpenSSH:

$ ssh -V
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007

Until they get it updated, it’s easy to do yourself. Simply install the latest version of Cygwin, and make sure to search for and install OpenSSH on the package screen. Then go into the /bin directory of where you installed Cygwin, and copy the following files into C:\Program Files\Git\bin (or Program Files (x86) if you’re on 64-bit):

  • cygcrypto-0.9.8.dll
  • cyggcc_s-1.dll
  • cygssp-0.dll
  • cygwin1.dll
  • cygz.dll
  • ssh.exe
  • ssh-add.exe
  • ssh-agent.exe
  • ssh-keygen.exe
  • ssh-keyscan.exe

Checking the OpenSSH version should yield something a bit higher now:

$ ssh -V
OpenSSH_5.8p1, OpenSSL 0.9.8r 8 Feb 2011

Your clone speeds should be faster too. This upgrade bumped ours from literally around 1MB/sec to a bit over 10MB/sec. Nice.

Jun 17
TortoiseSVN 1.6+ Hot Keys
icon1 Darrell Mozingo | icon2 Quickie | icon4 June 17th, 2009| icon3No Comments »

The latest releases of Tortoise SVN (above 1.6) have taken away the ALT+O hot keys that used to be on every dialog (though it sounds like they’ve added them back in to the trunk). This caused quite an uproar by many keyboarders, myself included.

Until the trunk is stable and the ALT+O keys are reintroduced, though, know that CTRL+ENTER will substitute on pretty much all the dialogs (or ESC for Cancel). These are the “standard” Windows OK & Cancel shortcuts, and apparently the custom accelerator keys are hold overs from legacy WinAPI code.

I’ve grown accustomed to CTRL+ENTER at this point, but I’ll be happy to hopefully have my old friend, ALT+O, back soon.

Mar 9
Layout tweaks
icon1 Darrell Mozingo | icon2 Quickie | icon4 March 9th, 2009| icon3No Comments »

OK, maybe not so much tweaks as borderline major reconstruction. I change the layout to give it a fluid width and replaced my syntax highlighter, which was getting on my nerves, with a new one that appears to be working much better. Time will tell, though.

If you’re reading this through an RSS reader (and honestly, who isn’t?), the code samples should be a bit more legible, and less mangled up for no good reason, going forward. If by some chance my touching up all the previous posts relisted them as new in your reader – and it hasn’t for Google Reader – then I apologize. I’m done now, I hope.

Anyway, on to more actual posts.

Jan 28
ASP.NET MVC RC 1 Visual Studio Crash
icon1 Darrell Mozingo | icon2 Quickie | icon4 January 28th, 2009| icon36 Comments »

After installing the newly released ASP.NET MVC RC 1, Visual Studio started crashing on me when opening a View (.aspx filer), always with the following error in the Application event log:

Error 1/28/2009 10:50:31 AM .NET Runtime 1023 None
.NET Runtime version 2.0.50727.3053 – Fatal Execution Engine Error (707F5E00) (80131506)

Though every few tries, this one would pop up too:

Error 1/28/2009 10:41:27 AM devenv 0 None
The description for Event ID 0 from source devenv cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

The data source ‘{130bada6-e128-423c-9d07-02e4734d45d4}’ specifies no supporting providers or a set that are not registered.

Oh, and as an FYI, this is on a Vista 64-bit box.

Seems quite a few people had this almost identical problem with the Preview 5 release last time. Uninstalling all my add-ins (Visual SVN, ReSharper, Gallio, etc.) didn’t help, nor did a complete MVC re-install after rebooting.

I eventually found a post here that mentioned whacking the bin folder and all its contents helped their Preview 5 issue. It didn’t quite work for me, however, after removing and re-adding the references to all four MVC assemblies (Microsoft.Web.Mvc, System.Web.Mvc, System.Web.Abstractions, and System.Web.Routing) and doing a full rebuild, my problem disappeared and I was good to go.

It’s odd how an assembly reference would cause Visual Studio to crash. It must be trying to do something with them when you open the .aspx page in the source view. Even odder is the fact that I overwrote the old Preview 5 assemblies with the new ones, so I thought doing a full rebuild in Visual Studio would have automatically used those new assemblies. Guess the IDE needs them re-referenced, though. Oh well, works now.

Jan 17
Running IIS 7 In 32-bit Mode
icon1 Darrell Mozingo | icon2 Quickie | icon4 January 17th, 2009| icon312 Comments »

I recently got a new machine at work with a 64-bit quad-core CPU, dual 15k RPM SCSI drives, 4G RAM, and, *gulp*, Vista. I’ve never used Vista before, and after all the horror stories I’ve heard, I was pretty hesitant. We’re using ASP.NET MVC with our new project, though, and deploying out to Windows Server 2008, which runs IIS7, so I figured developing with the same thing on my local box was a good idea. That means running the apps through IIS and not the built in Visual Studio 2008 Cassini server, which is what I was using back on XP.

So I set everything up, check out our project, fire up Visual Studio, hit debug, and BAM! I get a nice looking yellow screen of death, which, incidentally, isn’t our application’s start-up page. Here’s the exception it throws:

System.BadImageFormatException: Could not load file or assembly ‘OurProject.Core’ or one of its dependencies. An attempt was made to load a program with an incorrect format.

WTF? It was working fine on my old box. I recompiled our app after changing all the projects to explicitly compile in 32-bit mode and still got the error. As it turns out, IIS will, by default, run in 64-bit mode on a 64-bit box. Makes sense. If you open Task Manager, you can see that’s how it works (note there’s no *32 next to the process name like all the other 32-bit apps that are running, like Fire Fox and Visual Studio):

Task Manager showing IIS 7 running in 64-bit mode.

So how do you tell IIS 7 to run in 32-bit mode? I found a terribly helpful post here that details of the situation (both a fix and the reasoning behind it). Basically, go into your IIS 7 manager console, find the application pool your app is running in, right-click on it, go to Advanced Settings, and change the Enable 32-bit Applications setting to true:

Editing the application pool properties in the IIS 7 Manager snap-in.

Now restart IIS (either via the snap-in or the command line w/net stop w3svc & net start w3svc) and you’re good to go. Easy enough, right? Pop open Task Manager again and you should see a lovely *32 next to the World Wide Web Worker Process (w3wp.exe), signifying that it’s basically running in 32-bit compatibility mode:

Task Manager showing IIS 7 running in 32-bit mode.

Hopefully your app should load fine now. Well, at least mine did.

Aug 15
On Throwing Exceptions
icon1 Darrell Mozingo | icon2 Quickie | icon4 August 15th, 2008| icon3No Comments »

Don’t catch exceptions unless you’re prepared to do something meaningful about it, or add more useful information to the exception message/object. There’s nothing more annoying than seeing:

try
{
	SomeOperationThatThrowsAnException();
}
catch(Exception ex)
{
	throw;
}

Or:

try
{
	SomeOperationThatThrowsAnException();
}
catch(Exception ex)
{
	throw new Exception("Some Operation threw an exception");
}

Or anything else along those lines. They add nothing meaningful to the situation, and only aid to obfuscate the call stack when debugging. The only reasonable time you should catch an exception, in my opinion, is to somehow recover the operation, or add meaning and context to it. For example:

int userID = 20;   // Already a class member or passed in as a parameter.
 
try
{
	SomeOperationThatThrowsAnException(userID);
}
catch(Exception ex)
{
	throw new Exception("Couldn't do an operation on userID \"" + userID + "\".", ex);
}

Granted, there should probably be a logging facility setup to handle this type of stuff, or a more robust exception framework that will dump all needed local variables, but you get the idea. The exception is essentially being rethrown, but with more context to help debug the problem later on.

Also, remember that you can have a try/finally block with no catch. There’s no need to throw a catch block in there and rethrow just to get the benefits of cleaning up your resources. This is perfectly legal:

try
{
	SomeOperationThatThrowsAnException();
}
finally
{
	// Cleanup resources.
}
Jul 18
Success Story
icon1 Darrell Mozingo | icon2 Quickie | icon4 July 18th, 2008| icon3No Comments »

Devlicio.us was holding a contest on personal success stories, so I entered with a short one about my current job. The environment and whole attitude of everyone here has changed dramatically in the recent past, and I’m quite proud to share the story.

Here’s the entry, which got me a second place finish:

http://devlicio.us/blogs/sergio_pereira/archive/2008/07/07/doing-a-180-in-a-matter-of-months.aspx

Jun 30

We have a steadily growing collection of small extension methods (including the usual .IsNullOrEmpty(), .To<T>(), etc.), along with corresponding unit tests, setup at my work. I spent some time a few weeks ago increasing the test coverage from around 70% to 100%, along with making the unit tests a bit more robust.

After setting up a build script for the project and adding it to our continuous integration server (which I’ll blog about shortly), I found a few check-ins that were breaking old unit tests. Emails were automatically sent out, by the CI server, about the failed tests and broken builds, but it turns out too many of us were forgetting to run the unit tests before doing our check-in (obviously). We don’t have TestDriven.Net or Resharper – though we’ll likely be ordering copies of the later any day now – so we have no easy way of running the tests besides the standard MbUnit GUI. Yuck.

A few days later I ran into this helpful piece of information, I think perhaps from JP Boodhoo, though I’m not positive. Anyway, if you have a separate assembly for your unit tests, simply go to the property page of that project, click the “Build Events” tab along the left, and enter this in for the post-build event:

"$(ProjectDir)..\UtilityLibrary.Core\Internal\Tools\MbUnit\MbUnit.Cons.exe" "$(TargetPath)"

This statement assumes you have your project checked out to something like C:\MyProjects\UtilityLibrary, and under there you have UtilityLibrary.Core for your actual code, and UtilityLibrary.UnitTests for, well, your unit tests. This command starts in the UnitTests forlder, goes up a directory (into C:\MyProjects\UtilityLibrary) and right back into the Core folder, which has the MbUnit library/program in it. If your situation is at all different, you’ll have to adjust this command accordingly, but it’s a good start.

Now your unit tests will be ran as a step in compiling your solution, and the compilation will fail if any of the unit tests fail:

Useful for smaller utility projects like this, but I imagine it’d become a pain in the ass for larger projects that take a bit of time to compile on there own, never mind having to run the unit tests on top of that every time. Sometimes you just want to see if the code compiles, not necessarily run all the tests too.

May 26
C# 3.0 Automatic Property Gotcha
icon1 Darrell Mozingo | icon2 Quickie | icon4 May 26th, 2008| icon3No Comments »

One of the neat new features of C# 3.0 is the automatic properties syntax. It’s basically a quicker and simpler way to declare properties, as you don’t need to create a private backing object for each one as you’ve always had to. Here’s an example:

public class Person
{
	// Original way:
	private string _name;
	public string Name
	{
		get { return _name; }
		set { _name = value; }
	}
 
	// New, automatic property, way:
	public int Age { get; set; }
}

Using the second example, the compiler will basically create a private Age member in the background and use in the generated getter/setter of the new property. If it’s a numeric type, as Age is, it will default to 0. If it’s a reference type, such as another class or a Nullable type (i.e. int?), it’ll default to null.

Now for the semi-gotcha: strings are reference types, so they’ll default to null. This may not be a problem in your situation, but I personally like to default all of my string to string.Empty (unless the situation calls for a null, which I find isn’t very often). I just don’t like the hassle of dealing with null strings, though the string.IsNullOrEmpty() method helps mitigate that.

So there ya go. Take it for what it’s worth – something to keep in mind when using the new automatic property feature.