Recently in .Net Development Category

Wow. Microsoft will bundle the jQuery library with all ASP.NET MVC projects, enhance its interaction with Visual Studio through IntelliSense, use it in future ASP.NET Ajax controls, and provide support for the library itself. This is huge because most of the Microsoft universe doesn't take note of anything not provided by Microsoft in a standard distribution.

I've been a consumer of the Facebook.NET framework for a few months now as I've developed several Facebook applications in ASP.NET. I chose that framework instead of the official Microsoft one because it seemed more logical and straightforward.

Honestly, I'm not at all certain why I originally chose one over the other. I read all of the blog commentary about each, I looked over the source, and I checked out the sample applications included. Facebook.NET struck me as elegantly designed, well conceived, and actively developed. Sure, Microsoft had commissioned and paid for the development and maintenance of the Facebook Developer Toolkit, which meant it was more likely to be around in the future. This possible objection was easily dismissed since Facebook.NET was open source and could be extended privately as long as need be.

What I couldn't have foreseen were sweeping changes by Facebook to the underlying API within six months and a complete abandonment of the open-source project by its sole maintainer. Facebook has made a lot of mistakes in handling the transition but there's precious little that I, as a third-party application developer, can do about that. So my sole responsibility is to keep up with updates to the framework and alter my code to accommodate the new (or changed) functionality.

Faced with a framework that isn't getting updates, the responsibility expands considerably. One must either abandon the abandoned framework to search for greener pastures or one must take up the mantle of leadership by forking the project. Neither is a path to be chosen lightly for each entails considerable pain.

The choice was made easier for me by the fact that the Facebook Developer Toolkit was just as inactive at the time. I tried corresponding with the Facebook.NET maintainer and even succeeded a couple times: I would much rather have been a developer on a project than the man responsible. In the end, it became clear that the maintainer had moved on to other projects and that I was going to have to fork.

The result is fb.net. I largely brought it up to parity with the API changes in a span of two days but then I got distracted by work, family, and other projects myself. As it stands, there's just a little more to go and then I can make a release candidate.

My only hope is that I can get this framework ready for a full release and then start looking to build a community that can assist in its maintenance. The Facebook.NET maintainer got it off to a good start; now it's my turn to finish the job.

I generally don't like to showcase other's inelegant code, but this couldn't be more timely given yesterday's Twitter created_at parsing tip. There's always more than one way to do something, I guess.

       private static DateTime ParseDateString(string DateString)
        {
            Regex re = new Regex(@"(?<DayName>[^ ]+) (?<MonthName>[^ ]+) (?<Day>[^ ]{1,2}) ↵
            (?<Hour>[0-9]{1,2}): (?<Minute>[0-9]{1,2}): (?<Second>[0-9]{1,2}) ↵
            (?<TimeZone>[+-][0-9]{4}) (?<Year>[0-9]{4})");
            Match CreatedAt = re.Match(DateString);
            DateTime parsedDate = DateTime.Parse(
                string.Format(
                    "{0} {1} {2} {3}:{4}:{5}",
                    CreatedAt.Groups["MonthName"].Value,
                    CreatedAt.Groups["Day"].Value,
                    CreatedAt.Groups["Year"].Value,
                    CreatedAt.Groups["Hour"].Value,
                    CreatedAt.Groups["Minute"].Value,
                    CreatedAt.Groups["Second"].Value));

            return parsedDate;
        }

For me, the lesson here is to know your libraries and always assume that someone else has done it better than you already. It then becomes a quest to find that better solution to the problem.

If you were wanting to interact with the Twitter API under .NET, you might find yourself trying to convert a date value from the XML results over to a DateTime in your code. Twitter uses a weird format for their dates—Thu Sep 04 11:09:28 +0000 2008—that doesn't get converted properly with just a good ol' DateTime.Parse. You could spend a lot of time iteratively trying to figure out the correct format to use. Or, you could just use the following (my free gift to you, dear Twitter-API-consuming reader):

directMessage here is an XmlNode representing a single direct message extracted from a list of direct messages. I found this out after many iterations since all of the .NET libraries for Twitter just punt on this conversion.

Microsoft has unveiled its new project code-named Velocity {via}, which is a .NET version of memcached for the Microsoft orbit. It's not at this point baked into the OS or IIS, but it's a start.

It's got some additional features that go beyond memcached. One of the great things about memcached is its simplicity and limited feature set. It doesn't worry about security and it's essentially a glorified hashtable. For example, it offers named cache stores, regions within those caches, object searching, and different concurrency models. I can envision a lot that such functionality would get me if I were to replace memcached with it.

But I'm most curious as to the future of this project and its official position. If it's going to become a supported technology and/or officially bundled, then I'd be willing to invest the effort in switching. But if it's a one-off and never gets much attention, then I'd rather stick with the power horse that is memcached. There's plenty of hope listed in their future feature list. I'm subscribed to the blog and I will be following this project closely.

Today I discovered that there's a new port of memcached for Windows! This one reflects memcached v1.2.4, which added a bunch of new features like multi-get, append/prepend, and check and set. This is a huge release even though it's in beta and is the first pass from the new maintainer. I am especially happy because I was considering putting in some time to do the port myself; I wasn't looking forward to it since I'd have to learn C++ and it'd take me awhile.

I also found the BeIT memcached client library, which purports to improve on Enyim. I haven't had a chance to try it out yet, but I like the embeddable, lightweight nature of its code. It supports a few commands that Enyim doesn't so I'm going to give it a try. Enyim had a couple quirks that we found and worked around so I'm always willing to find a more straightforward framework if possible. I don't understand the hashing issues enough to ascertain which is using the better-performing or more consistent algorithm so I don't have a preference on that front.

All in all, these were two very welcome developments. It's never been a better time to be a memcached fan in the .NET world!

I deployed my most recent project at work today. It's a Facebook application that allows Quick Blogcast customers to link their accounts to their Facebook profiles.

I know that bringing a blog into your Facebook profile is nothing new. There are many such applications out there right now that can do that. But I think this Quick Blogcast version is unique in that you can make it so that your friends and visitors never leave Facebook, even to comment! What's more, we leverage nearly all of the Facebook integration points. This allows the Quick Blogcast customer to publicize his or her blog to the fullest extent while still respecting the conventions and norms of the Facebook world. While that may not sound like much, it's been quite a learning experience for me.

For one thing, I had to master the Facebook API. Luckily, I only had to learn it secondhand because I had an excellent framework called Facebook.NET to lean on. After a month or so of experience, I even felt conversant enough to help others and supply patches. In so doing, I apparently really helped the developer of Thugz Passion, a game which I've grown to enjoy.

It was also a chance to get to know memcached better. I used the terrific Enyim.com Memcached framework to interact with a Win32 port of the service. I wish I knew enough C++ to move that project to the current version of the Linux original. I futilely check the danga email archives to see whether anyone's gotten impatient with progress and just did it on their own.

I was (and am) very impressed by memcached, which is an excellent (and free) distributed caching system. ASP.NET is top-notch at scaling but its caching mechanisms (namely, the object bags like Cache, Application, and Session) can easily become bottlenecks after enough usage is thrown at them. I think memcached offers a way out—it's certainly worked wonders in the Linux world.

I affectionately call this integration app Quick FaceBlogBookCast. It cracks me up every time; it's easily the most cumbersome portmanteau I've come across. (I can't believe I forgot the other Facebook app I released today: Domain Center for Facebook! It's a way to spontaneously generate domain name suggestions from the information contained on your Facebook profile. The algorithms right now are pretty coarse, but I plan to refine them each and every release until they're uncannily right some day.)

[The views expressed on this website/weblog are mine alone and do not necessarily reflect the views of Go Daddy Software, Inc.]

Longtime readers may already know that I am a big fan of JetBrains' ReSharper add-in for Visual Studio. I recommend it highly to any .NET developer, but especially to any of those who are interested in being more productive. You'd think that that'd be everyone, but I've found it not to be the case. Many developers I recommend the tool do don't want to learn a new tool, aren't particularly keyboard-enthusiastic, or mistakenly believe that ReSharper is superfluous. On that last point, I've stumbled upon a nice comparison chart showing that that is not the case.

There's overlap, to be sure, but in nearly every instance I've encountered ReSharper's implementation is more thorough and more thoughtful. It's worth every penny.

At work today, I ran into some trouble trying to set up a virtual directory as an application in IIS. My two applications, the parent and the child, occupied different locations in the filesystem, had separate app pools, and different app names. Due to the inheritance of Web.config, though, the HTTP modules defined in the parent app were throwing configuration exceptions in the child app even though the child app never referenced any of the HTTP modules.

I thought about adding an httpModule section to the child app's Web.config with a remove call, but that seemed klunky to me. Frantic Google searching wasn't giving any better solutions. Following the link chains from blog entry to blog entry to comments to more blog entries, I stumbled upon the answer:

<location inheritinchildapplications="false">
  <system.web>
   <httpmodules>
    …
   </httpmodules>
  </system.web>
</location>source

Of course! This breaks the inheritance chain and it only touches the parent app's Web.config.

Pardon me while I vent for a few minutes. I'm doing some contract development work for a non-profit—cleared long ago through my company's legal team to make sure that I wasn't running afoul of my non-compete clause—and to say that the conditions are sub-par is to put it mildly.

First, they've got a custom CMS that they've licensed from a local design house but they don't have rights to the source code. So it took me forever to set everything up because I'd keep hitting little errors that stymied me because I couldn't go code spelunking. But I persevered (barely) and now I've got a local instance of the CMS running. (The custom CMS, it must be said, is overly complex and often inscrutable. Even the design house's lead developer had trouble explaining how it worked.)

The only way for me to develop what they need is to inject custom user controls into the page lifecycle. That's no big deal, just an annoyance. But if I want to see how something looks, I have to copy my DLL from one directory to another each and every time.

Second, the CMS is written and hosted in .NET 1.1. That means Visual Studio 2003 (retch) and trying to remember what subset of C# isn't available. A task which would be much simpler if I had a copy of my trusty ReSharper, which I don't. $149 is a lot of money to spend but I'm getting close to throwing in the towel and ponying it up. (I would never even think of pirating it.)

The final abomination is that the database is hosted on SQL Server 2000 and that means Enterprise Manager/Query Analyzer. SQL Server Management Studio, part of SQL Server 2005, is so much nicer than that combo. Every time I fire up this suite of blast-from-the-past apps, I feel so dirty and ghetto. I'm hoping that someday soon they'll have the budget to allow me to convert over to an open-source CMS built in .NET 2.0.

The relationship with the non-profit and my belief in the rightness of its mission is what keeps me going on this when every fiber of my being says, "Go elsewhere, youngish man!" They got screwed with this custom CMS—the peril of being non-technical—and I wonder how the design firm sleeps at night seeing some of the atrocities I've come across. (If I ever feel spunky or get to migrate away from their CMS, I'll have some excellent horror stories to share. I should probably write them down somewhere for that eventuality.)

I've been tweaking ReSharper something fierce lately. I've talked about it before, but some day I'm going to write up all the things that make me love that little Visual Studio add-in. I know some suggest you should learn to love defaults, but others argue for knowing thy editor.

One of my favorite features are live templates. If you can get used to them, your productivity will soar since your hands will never leave the keyboard. I have gotten used to them and regularly create new ones when I find myself repeating.

Today I created an awesome template for doing StringBuilder.Appends. Now all I type is sb and it expands to actualStringBuilderObject.Append("MESSAGE"); with the cursor replacing the "MESSAGE" string and the enter key dropping the cursor off at the end of the line. That description doesn't do the template justice, so just make one using the screenshot below:

You can get to that dialog by clicking ReSharper > Options > Live Templates and then clicking on the + icon.

It's done! Today at 12:45 PM, I submitted my latest project to the Google Gadget Directory, marking the final step in the deployment process. It's a Domain Search gadget that's actually quite a powerful little application. What's really great about it is that it marked my first foray into serious test-driven development!

In the past, deadlines and inexperience had always prevented me from doing the kind of layered, thorough unit testing I'd wanted. That little application, actually the server-side piece that's powering it, has 65 unit tests underneath it. It's so refreshing to make changes and see that no tests were broken in the process.

TDD is one of those things best experienced firsthand. Now that I've had a taste, I don't think I'll ever go back. It just makes too much sense: the rigor added is intoxicating. Not literally, but it is self-reinforcing for sure. Anyhow, here's how you can get your own Go Daddy Domain Search Gadget for your iGoogle homepage—until the gadget gets added to the directory officially when I will replace these instructions:

1. Go to www.google.com/ig/directory.
2. Click on the "Add feed or gadget" link in the right navigation section.
3. Type or paste http://gadgets.godaddy.com/Google/domain-search.xml into the text field.
4. Click OK in the dialog box that comes up.
5. Click on the "Back to iGoogle home" link right above the iGoogle logo.
6. You should now see the gadget.

[UPDATE (1/10/2008): I completely forgot that Google has an easier way: ]

[UPDATE (1/14/2008): It's in the iGoogle Directory now!]

[UPDATE (1/17/2008): I just deployed a revision to it that adds in plain, Candice Michelle, and Dale Earnhardt, Jr. themes. Time to start working on the next version and it's going to be huge. Sorry, that's all you get.]

The views expressed on this website/weblog are mine alone and do not necessarily reflect the views of GoDaddy.com, Inc.

So I'm looking for the best open-source .NET CMS out there. Here's what I've found for options:

• Cuyahoga
• Umbraco
• Rainbow Portal
• AxCMS.net
• Sharp CMS
• mojoPortal

This is the part that I really dread: deciding amongst competing technologies. Each of them has features that I like and some of them even have user interfaces that I prefer. But then, at the same time, you have to look at the codebase and decide which is the one that is extensible, maintainable, and understandable. And the two assessments rarely overlap.

In this situation, there is no overlap. Rainbow Portal has probably the best user interface, but it's development seems completely stalled and the codebase is, well, terrible. Cuyahoga has an okay user interface (from what I can surmise given the lack of a demo site), an okay codebase (no unit tests, NHibernate pain, fairly straightforward separation of modules from core code), and decent development cycles but a rather lackluster slate of sites using it. Umbraco has an odd codebase (I found it very confusing at least), unknown user interface (really hard to pin it down from the code), good development cycles, and a pathetic slate of sites. The rest of them I didn't like for one reason or another.

Ultimately I have to pick based on which CMS has the codebase that I can live with most. If the user interface isn't that compelling, I can make it better if I have source that I'm comfortable with. Plus, I'm going to be extending the hell out of it so it's got to be robust enough that I'm not fighting the tool to expand and create new applications or modules.

Cuyahoga seems to be it. I just wish I could be more satisfied with the choice; I guess that couldn't happen unless I was rolling my own.

Boy, do I really want to love this technique. I mean, who wouldn't prefer this:

[PersistField(Location = PersistLocation.Session)]
public bool IsLoggedIn;

Over this:

public bool IsLoggedIn
{
get
{
return Convert.ToBoolean(Session["IsLoggedIn"]);
}
set
{
Session["IsLoggedIn"] = value;
}
}

It's so elegant and so concise. But it operates through reflection and reflection has a bad rap for being hoggy. Can you imagine checking every property for the attribute on load and then checking to see if they've changed at on unload? Talk about a tax on resources.

This beautiful snippet trades readability for performance and I think the bargain isn't worth it. The time it takes to write out the getters and setters of a property is a one-time deal. The decoration method outlined above makes the code easier to read and easier to describe, but at the expense of perennial runtime delays.

It's just not worth it.

I love regular expressions. Okay, I love the challenge of crafting regular expressions. I do not enjoy reading regular expressions that I have not created or, really, even the ones I do create. But give me a problem and tell me to make a regular expression to match things and I am all over it.

A co-worker wanted a regular expression to turn unlinked URLs in text into HTML links and to correct linked URLs that lacked a protocol into valid URLs. In other words, if "www.google.com" appeared in some text, it needed to be replaced with <a href="http://www.google.com/">www.google.com</a> and <a href="www.google.com">some link text<a> needed to turn into <a href="http://www.google.com">some link text<a>

My first pass was a monster regular expression that handled both situations but I couldn't get the replacement string to account for the fact that there was already link text in the invalid URL example. And I couldn't adequately cover the situation where there were attributes before the href attribute. So scrap that one.

This is what I came up with after separating it into two replacement passes. I share it with you both as a testament to my regular expression abilities (good or bad, you decide) and because this situation seems like one that might come up pretty frequently.

Inspired by Brian D. Foy's entry and Titus Brown's one for Python, here are five things I hate about C#:

1. You can't have methods whose signatures differ only in their return values. I think I understand why it might not have been a good idea in the past, but with VisualStudio.NET I don't see how anyone could get confused any longer.
2. You can split a class into partial classes. Why you'd want to do that is beyond me. Luckily, it's a 2.0 thing so I was able to refrain from seeing it for most of my development life.
3. virtual. I hate how you have to explicitly state which methods can be overridden by descendents.
4. Constructor chaining. I wish it could be done like normal method overloading where you can have the constructor do something and then call another constructor. Again, I understand why that's not feasible since the CLR would have to divine when a constructor was being called by another constructor versus a normal call to limit object creation. But the way that it's handled currently obscures what's actually happening when it treats the called constructor as a sort of pass-through to another one.
5. Documentation. This appears to be a universal language complaint. MSDN is quite comprehensive but shallow at the same time. Everything is minimally documented and I can generally start there. But I can almost never end there: I invariably have to go to places like CodeProject in order to get a decent example of the syntax in action. Even that is generally not the final word because I usually then have to go to the blogs to see if there's any "gotchas" involved in using the language construct. Oh, and MSDN does a horrible job of differentiating between .NET 1.1 and .NET 2.0--something I desperately need because I'm currently working in both versions of the framework.

That was a lot tougher than I thought. I had to comb through the code to find things that I hated that were specifically C# and not ASP.NET. C# is really quite a lovely language. In general, it's the bee's pajamas.

Just for grins, here's five things I hate about ASP.NET:

1. WebControls. Yes, I generally can't stand WebControls. I'm quite obsessive about my HTML and CSS; a lot of that combination's power is stripped away when you use a WebControl because Microsoft makes a lot of assumptions about how you're going to be using them.
2. AutoEventWireup defaults to true in 2.0. Okay, so I just talked about this one
but it's so wrong to change the default like that.
3. Application event lifecycle. There's really no adequate documentation about the ASP.NET sequence of events. This article from Peter Bromberg was the best I found. I ended up spending a lot of time in debugging trying to determine what is available when in the event sequence.
4. I hate ViewState. It is nothing but massive bloat and there's almost always a better way of storing data. I've also had several utterly inexplicable errors caused by ViewState corruption or changing.
5. PostBack. There's a reason why the <form> tag has an action attribute, Microsoft. I know that the Javascript trickery involved in POSTing to the same page allows for some nice automagical black-boxing. I just don't like that model of Web application development.

That one was a whole lot easier. I had to limit myself to just five.

The Page_Load event was firing twice—inexplicably. If I removed the explicit declaration in the code-behind class, then it fired once. That pointed clearly to two bindings, but I could not find anything in the usual haunts of global code. Nothing had changed except that we moved to .NET 2.0.

Of course, I found out that in ASP.NET 2.0 AutoEventWireup defaults to true even if no Page declaration is present. Well, that's a fine how-do-you-do! In 1.1, it defaulted to false, which made abundant sense. When migrating an application, you'd think that that would have been accounted for since it is such a potentially-disastrous change.

I mean it's one thing to have Page_Load fire twice. It's another entirely if you've got initialization stuff in OnInit or if you're doing any multicast delegation. Crazy!

Oh, so the easy fix is to change it in machine.config or Web.config by adding a autoEventWireup="false" to the pages element. Problem solved.

Today I finally had the chance to revisit the first service I ever wrote. I christened it Pingarooni and it handles all the outgoing trackbacks and pings for Quick Blog. It's been a long time since I've been in a position to re-examine early code done in a state of relative ignorance—I've been coding in ASP.NET for so long that my code is generally something of which I'm quite proud.

But I had never created a Windows service. The only non-Web application I'd ever created was a console application—certainly a world apart. I didn't really know what I was doing so my code evinced a certain textbook formality that subsequent services I wrote had thankfully shed. The flow of it was horrendous and I'm surprised it lasted as long as it did.

Here are the things I learned in revising it:

• Make your service work on batches at a time. By doing so, you'll be able to see progress and some freak error will only affect a small number of work items.
• Make the service work on discrete work units so that many instances of the service can be run in parallel.
• Make the service update the database to report its progress as soon as possible. At the least, it should report every batch if not throughout the batch.
• Make the service run continuously if possible, stopping only when an OnStop event is raised. If the work load is neverending, there's no sense in pausing between runs.
• Make the service use plugins along command pattern lines to define its work. If possible, these plugins should be put into a separate assembly or module so that additional plugins can be introduced with a simple restart of the service.

The views expressed on this website/weblog are mine alone and do not necessarily reflect the views of Go Daddy.com Software, Inc.

If you normally do a Regex.Escape(string) in C# to get some text ready for use as a regular expression, be aware that a string like ^Lijit (+http://www.lijit.com/)$ will be escaped like so ^Lijit\ \(+http://www\.lijit\.com/\)$ instead of ^Lijit\ \(\+http://www\.lijit\.com/\)$ as you would expect.

Using that "escaped" regular expression will result in an ArgumentException along the lines of parsing "^Lijit (+http://www.lijit.com/)$" - Quantifier {x,y} following nothing. That message is virtually un-Google-able until now.

The .NET exception occurs, I think, because the parser just doesn't understand the unescaped quantifier being next to an escaped control character. I believe that the escaping misses it because it uses that same parser because the plus sign is definitely one of the characters that the Escape method can handle.

If there is one thing I cannot stand at work it is wrestling with my tools. I've got two Web projects in Visual Studio 2003. I hate Web projects, hate 'em—there is no reason that I've found that you cannot do a Web application using just a standard project and it makes life so much easier since Web projects are the devil.

Anyhow, I have to make this mission-critical change to one of the Web projects and neither one will load automatically. Fine, I've danced this dance before about a month ago when suddenly Visual Studio refused to allow those Web projects into the solution. You just have to remove them and re-add them each time you open Visual Studio or change solutions. Man, after writing that, I can see how messed up my work life is—constantly rerouting around lost settings, malfunctioning applications, and halfassery in order to get things done.

So I did that and one of the Web projects loaded. Well, it loaded on the second attempt to add it. Again, not an unusual thing as I also discovered that the first Web project added generally needs to be done again since the Web server takes too long and times out. At least, that's my presumption because it works the second time. (Insert existential scream here.) The second one, however, refuses to load, giving me a timeout every single time I try it.

Usually, I can just f'ing Google the error message and have a handful of things to try. Unfortunately, this seems to be a problem unique to me since I couldn't find a single instance of my particular error message. The help, unusually helpful on this topic, didn't even list my failure as one of the options in its lengthy catalog of possible messages and vague steps to resolve them.

I tried the usual panoply of magic actions that sometimes yield results: restart VS, restart Windows, go directly to the project instead of using the braindead Web project loader, create a new solution, and try again the next day hoping that last night's hell was just a bad dream. Nothing worked. Went to the IIS logs to see what sort of things Visual Studio was trying to do to load the sucker: lots of unfamiliar actions ("PROPFIND", never heard of it—oh it's a WebDAV thing, interesting) and lots of 403s.

Ahh, the 403. Permissions. I know something about that. The permissions for both Web projects appeared to be the same, but let's just give those muthas full control. The panacea of frustrated users (and bane of administrators). Nothing. Machine.config: give the app SYSTEM access instead of ASPNET. NOTHING. NOOOOOOOOOOOOOOOOOOOOOOOOOTTTTTTTTTHHHHHHHING!

So three hours completely wasted while a mission-critical fix waits. I ended up editing the file in Notepad; now I just have to figure out how to csc a Web application. I hate wrestling with my tools.

[UPDATE: Great news! I got the Web project loaded … but the source control bindings were lost. The words "Pyrrhic victory" spring to mind. Visual Studio and source control binding problems are a separate level of hell unto themselves. Bleh.]

[UPDATE 2: In a dramatic turn of events, it bound. I hit the "Bind" button in the Change Source Control dialog and it came back in a few seconds. I was dumbfounded. It's never worked that well without manual diddling about in the VSS-VS project files. Finally.]