Peter Johnson's Blog

Structs seem to be largely ignored in .NET. Everyone uses them (Int32 is pretty common!), but rarely pay attention to the fact that they're structs instead of classes, and rarely need to. I've worked on several projects where I don't think a single custom struct was defined. A good .NET/C# programmer should understand the differences between classes and structs as they consume them, but when creating a new type, most folks just create a class without a second thought (a class is usually the right answer anyway).

One topic I recently dove into in my continuing tech education is blockchain.

A couple years ago, one of my email addresses was transitioned from the classic Outlook Web Access to Office 365. I appreciated the cleaner & more modern looking interface, but noticed a few steps backward that made me scratch my head. Things that seemed easy & intuitive in the old OWA, and in Hotmail, were harder or even impossible in Office 365 Outlook.

If you've dug into the .NET documentation much, you've probably seen the framework has unsigned versions of the integral types we use all the time, and C# considers them built-in types with language keywords to easily use them--ushort, uint, and ulong. If you haven't, you may be unfamiliar with them--in 14 years of C# development, I could probably count on a hand or two the number of times I've seen them in production code.

I've had an opportunity to do WPF development professionally (as opposed to hobby-tier) for the first time over the last year or so, & while the improvements over WinForms are staggering (and as a lifelong web developer, also familiar), there's plenty that's not intuitive.

ASP.NET MVC's HtmlHelper extension methods take out a lot of the HTML-by-hand drudgery to which MVC re-introduced us former WebForms programmers. Another thing to which MVC re-introduced us is poor documentation, after the excellent documentation for most of the rest of ASP.NET and the .NET Framework which I now realize I'd taken for granted.

As a corporate developer by trade, I don't get much opportunity to create from-the-ground-up web sites; usually it's tweaks, fixes, and new functionality to existing sites. And with hobby sites, I often don't find the challenges I run into with enterprise systems; usually it's starting from Visual Studio's boilerplate project and adding whatever functionality I want to play around with, rarely deploying outside my own machine. So my experience creating a new enterprise-level site was a bit dated, and the technologies to do so have come a long way, and are much more ready to go out of the box. My intention with this post isn't so much to provide any groundbreaking insights, but to just tie together a lot of information in one place to make it easy to create a new site from scratch.

We recently upgraded to the 64-bit Oracle client. Since then, Visual Studio 2010 unit tests that hit the database (I know, unit tests shouldn't hit the database--they're not perfect) all fail with this error message:

I've been delving into ASP.NET MVC 4 a little since its release last month. One thing I was chomping at the bit to explore was its bundling and minification functionality, for which I'd previously used Cassette, and been fairly happy with it. MVC 4's functionality seems very similar to Cassette's; the latter's CassetteConfiguration class matches the former's BundleConfig class, specified in a new directory called App_Start.

I've found Unity to be a great resource for writing unit-testable code, and tests targeting it. Sadly, not all those unit tests work perfectly the first time (TDD notwithstanding), and sometimes it's not even immediately apparent why they're failing. So I use Visual Studio's debugger. I then see SynchronizationLockExceptions thrown by Unity calls, when I never did while running the code without debugging. I hit F5 to continue past these distractions, the line that had the exception appears to have completed normally, and I continue on to what I was trying to debug in the first place.

In settings where Unity isn't used extensively, this is just one amongst a handful of annoyances in a tool (Visual Studio) that overall makes my work life much, much easier and more enjoyable. But in larger projects, it can be maddening. Finally it bugged me enough where it was worth researching it.

I've had an excuse to mess around with custom route ignoring code in ASP.NET MVC, and am surprised how poorly the IgnoreRoute extension method on RouteCollection (technically RouteCollectionExtensions, but also RouteCollection.Add, and RouteCollection.Ignore which was added in .NET 4) is documented, both in the official docs by Microsoft, and various bloggers and forum participants who have been using it, some for years.

I was thrilled that T-SQL finally got the TRY/CATCH construct that many object-oriented languages have had for ages. I had been writing error handling code like this:

I've started using Windows Workflow Foundation, and so far ran into a few things that aren't incredibly obvious. Microsoft did a good job of providing a ton of samples, which is handy because you need them to get anywhere with WF. The docs are thin, so I've been bouncing between samples and downloadable labs to figure out how to implement various activities in a workflow.

I recently helped migrate a ton of code from Visual Studio 2005 to 2008, and .NET 2.0 to 3.5. Most of it went very smoothly; it touches every .sln, .csproj, and .Designer.cs file, and puts a bunch of junk in Web.Configs, but rarely encountered errors. One thing I didn't expect was that even for a project running in VS 2008 but targeting .NET Framework 2.0, it will still use the v3.5 C# compiler. As such, it does behave a bit differently than the 2.0 compiler, even when targeting the 2.0 Framework.

I bought my current PC almost three years ago. I've had my own PC for 15 years or so, and, aside from my first desktop and a laptop I only use when traveling, that was the only time I've bought a whole PC, rather than buying parts and assembling my own (a Frankenputer as former coworkers affectionately referred to them). Like many of my colleagues who work in Microsoft technologies, I looked into buying a Dell, and they had a fine deal, and more importantly, they had finally started selling AMD processors, which I can proudly say without qualification is the only CPU in any computer I've owned. I configured one with a dual core, 64-bit processor, and all sorts of new technologies I'd never heard of but were (and appear to still be) the latest and the greatest. ("What's SATA? We use PCI for video again?" I asked myself.)

One problem I've had in Team Foundation Server since Visual Studio 2005 and still in VS 2008 is when items are deleted by someone else, they still show up in Source Control Explorer, with a gray folder with a red X icon, even with "Show deleted items in the Source Control Explorer" unchecked in VS's Options dialog. Sometimes getting latest of the parent clears things up, but other times it doesn't, even with Get Specific Version with both Overwrite boxes checked to force a get. In this case, the only option I've found is to delete my workspace and recreate it, which means checking in everything beforehand, and getting latest of my working branches afterwards. It's a pain, but as specified here and approved by a Microsoft employee, that may be your only option until it's fixed--fingers crossed for VS 2010. (We won't get into the other things for which my fingers have been crossed since I first used TFS in 2005, things that VSS did just fine, such as rollback, check in changes and keep checked out, and search.)

It's official! In one of the first of a few dozen posts you'll read about it, Scott Guthrie announces Visual Studio 2008 and the .NET Framework 3.5 Beta 2 have been released.

In working with my company's offshore developers, I was tasked with providing them documentation on a set of class libraries we use in our applications. In the .NET 1.0/1.1 time frame, we used NDoc, which, sadly, passed away last year, to turn the XML comments output by the C# compiler into CHM help files. After a bit of googling and a false start, I discovered Sandcastle, which Microsoft uses to build the .NET Framework documentation itself. I also discovered from the Sandcastle blog that it takes a whole mess of manual steps to use, which appeared daunting at first glance, and, being a programmer, I was looking for an easier (lazier) way.