So, I think I will narrow the scope of this blog to my experiences as CTO of a software company. This will include development, of course, and maybe even some code. But I also want to share nuggets of wisdom I come across, stories of success and failure, and frustrations as well.

We ship our product on June 7. It’s my first commercial software project. Everything I’ve done previous to this has been in the enterprise, relatively safe in the confines of a large corporation where the users were my coworkers and didn’t spend their own personal money on the stuff I created. This is something entirely different.

I do hope you’ll return regularly, or add me to your RSS reader. I will treat you to stories about cloud computing, rich client applications, raising capital, dealing with constant change, and pig farming.

The point of bringing that up is to say that I feel like I’ve been grinding a lot on a particular task at work. It seems like a pretty simple task, involving SharePoint document libraries and Word documents, but something about the whole thing just isn’t sitting right. Not yet. I’ve spent a lot of time on my whiteboard, mapping things out. Each time I’ve come up with a solution, I go into SharePoint and figure out why it won’t work. Content query web part? Nope. Document library web part with querystring filter? Nope. Individual libraries for each user group? Nope.

And so on, and on, and on, until the end of the day comes and I throw my hands up in the air in defeat as I trudge out to my Jeep for my mercifully short commute home through downtown Des Moines. Yet I still have the specter of the problem hanging over me, taunting me, urging me to just stay in bed and pull the comforter over my head until SharePoint somehow magically solves itself.

As a grown up, I have figured out that such solutions aren’t really solutions at all, and I do indeed have to face the music, so to speak. The first step to overcoming the demon is to admit that I am the one with the problem: my skills in this particular area aren’t strong enough, so perhaps I can’t figure this one out on my own.

Tomorrow I’m bringing in another set of eyes to work on the problem with me. Hopefully we can collaborate effectively and devise some kind of solution that will solve the problem without taking forever to implement. This guy’s SharePoint knowledge is next to nil, but he’s a smart developer so maybe just talking about the problem will give me the eureka moment.

I’ll let you know.

But as I started to delve deeper into SubSonic for my current project, I realized I needed to learn a bit more about the product that SubSonic is somewhat based on, specifically ActiveRecord. I figured, what better way to gain insight into how SubSonic works than to understand the genesis of the whole thing.

My foray into Rails development has been swift and deep. Now I get it: Rails lets you build Web applications very quickly, and it does that by requiring an adherence to a specific architecture that is governed by one person. It makes total sense.

That paragraph could be taken as a bash on Rails, but in fact, it’s not. I really like Rails. I really like that Rails is overseen and designed by one person (well, technically two). I think that’s a strong feature of the framework. In the .NET world, we don’t have that. .NET is meant to be general-purpose. It’s designed to let you create your own frameworks, and it gives you a million ways to do everything right and a million ways to do everything wrong. As I said to a colleague several years back, “.NET’s flexibilty is inflexible.”

Learning Rails is making me a better developer. It’s forcing me to learn new ways of doing things. I didn’t expect the exercise to have such an immediate and valuable impact. If I take nothing else away from this experience, I’ll at least have a much broader understanding of this business.

And MVC, of course.

Long story short, the upgrade on both of my servers failed. Looking at the logs, I saw this:

[SPManager] [ERROR] [6/2/2009 10:44:16 AM]: The system cannot find the path specified.

That’s it. That’s all I had to go on. After some hemming and hawing and tearing my hair out, I figured out what the problem was. It’s not that the installer can’t find a path, it’s that the IIS metabase is pointing to a “dead site,” or a site defined in IIS for which the directory structure doesn’t exist. That fixed the problem on the database server.

On the farm’s front-end server, I got the same error, but I didn’t think that it was a problem with IIS.

My solution was to simply detach and reattach the content database, which is what Microsoft says to do in its best practices document for upgrading SharePoint.

If you choose to not follow the directions and end up with the “file not found” error, try this.

First, execute this command (replace the bracketed items with your details, without brackets of course):

stsadm –o deletecontentdb –url [http://example.com] –databasename [contentdbname] –databaseserver [databaseserver]

Don’t worry about the word “delete” in the command. It doesn’t actually delete your database. It just detaches it.

Once that’s done, reattach the content database via:

stsadm –o addcontentdb –url [http://example.com] –databasename [contentdbname] –databaseserver [databaseserver]

Now run psconfig to tie it all together:

psconfig –cmd upgrade –inplace b2b –wait –force

The configuration completed and everything worked.

My suggestion is to follow Microsoft's SharePoint upgrade best practices document to the letter. This is the best way to head off these kinds of issues. And always make sure you back up your content and configuration databases before you upgrade. Few things are worse than rebuilding a SharePoint farm from scratch.