The Windows SharePoint Services SDK has shipped. It’s basically a help file – no bits. And no RTM version of WSS as of yet. I guess that has to wait until October 1st like the rest of the Office System.

It started as a weblog entry describing an issue with the way ASP.NET’s __doPostBack method. Basically, the __doPostBack method doesn’t fire the form’s onsubmit event. But as I was writing the entry, I built a module that worked around the issue. So I posted the issue and the fix as an article and source code.

I’ve been doing a little spelunking the last few days. Unfortunately, much of it has been to no end, but I thought I’d share anyway.

• The deeper I dig into Windows SharePoint Services, the more impressed I am. While it’s well known you can customize at the data level (custom lists) and the web part level, it turns out you can do a lot of customization at the page layout level. Don’t like the default page layout of WSS? Go ahead and change it. You can customize the pages within a specific site using Front Page 2003, or at the server level by hacking files in the web server extensions60template1033 directory. I was able to add my own custom site templates, use my own custom default.aspx page, define my own custom list types, etc.
• One WSS downer – as far as I can tell, you can only have one instance running on a given machine. Which means if you go hack on the templates at the file level, everyone running on that server gets the changes. Which means I’m guessing most WSS hosting providers won’t let you hack on the templates.
• I’ve also been playing around with custom designers and WebMatrix. One of the cool things about WebMatrix is it’s ability to render UserControls in the pages where they are used – something VS.NET can’t do. I wanted to know how WebMatrix did it since I want similar functionality in my custom designer. However, it appears that this capability is specifically tied to WebMatrix as a designer host. If you look in Microsoft.Matrix.Packages.Web.dll, there’s a Microsoft.Matrix.Packages.Web.Designers.MxUserControlDesigner class. I’m guessing WebMatrix silently substitutes this designer for the default UserControlDesigner provided by the framework. In the GetDesignTimeHtml method (part of the designer infrastructure), the designer is able to walk the project hierarchy in order to find the file the control instance refers to. This project hierarchy is all written in managed code and is provided to the designer via the standard designer services infrastructure (ControlDesigner.GetService). VS.NET project hierarchy is accessed as part of the old COM-based DTE (design time environment) object model. Furthermore, there doesn’t appear to be a consistent way to retrieve that DTE base object unless it is explicitly passed to you (as in the case of an add-in). According to the docs, you should be able to get a DTE reference to the currently running instance of VS.NET by calling System.Runtime.InteropServices.Marshal.GetActiveObject(“VisualStudio.DTE.7.1″). However, if there are multiple instances of VS.NET running, that call to GetActiveObject actually retireves the DTE reference to the first instance of VS.NET, not the current instance. Woops.
• The upshot of the above spelunking is that in WebMatrix, a designer can easily find, open and read the contents of another file in the project (or should I say directory since WebMatrix doesn’t use projects per se). In VS.NET, it can’t. Seems odd that the free product has features the non-free product doesn’t. Of course, some of that probably comes from the fact WebMatrix is simpler and built with managed code. Here’s to future versions of VS.NET being built using more (or better yet exclusively) managed code.

I ran across an interesting rebuttal to Harvard Business Review’s now-infamous article “IT Doesn’t Matter“. It focuses on the article’s claim that a resource’s strategic value is derived from its scarcity and that since IT is a commodity, it isn’t scare and thus has no strategic value. The rebuttal rightly points out that a resource’s strategic value is actually derived from the way it is managed. Resources like capital and talent have wide ranging impact, based on how well or poorly they are managed. (The rebuttal suggests HBR should print an article titled “Talent Doesn’t Matter”). However, I think that HBR’s article is further flawed in its basic premise that IT has become a commodity.

The article draws an analogy to the effect electricity had on manufacturing. Before electricity, manufacturing plants were constructed around a central source of kinetic energy such as a steam engine or waterwheel. A complex system of pulleys and gears distributed that kinetic energy to the various workstations within the plant. This system of pulleys and gears was cumbersome, inflexible and costly, but it was the only choice. When electricity was first introduced, electric generators replaced the waterwheel and were used to power the complex system of pulleys and gears. Eventually, someone figured out how much more efficient it is to distribute electricity directly to the workstations. This electricity powered smaller, cheaper and more flexible machines directly at the workstation. For a while, companies that were smarter about the use of electricity gained an advantage on those that weren’t. But eventually, everyone caught on and that advantage was lost.

This is amazing analogy to the current state of distributed system technology. However, HBR draws the wrong conclusion. They conclude that IT has become a commodity, and that while it provided a short term benefit to early adopters, that that advantage is largely gone today. On this issue of commoditization, HBR is only half right. Technology is a commodity, but information is not (or at least, not yet). Taking the waterwheel/electricity analogy forward, early computer systems were constructed around the mainframe as the central source of information processing. A complex system of programs and terminals distributed that information to the various workstations within the company. This system of applications and terminals was cumbersome, inflexible and costly, but it was the only choice. Now, even though we have powerful information processing systems right on our desktops, we continue to distribute information via a complex system of programs and terminals browsers. Building web applications is the computerized equivalent to replacing the waterwheel.

I imagine that for the factory owners back in the early days of electricity, the value proposition of replacing the water wheel with an electric generator was very compelling. No need to replace the entire infrastructure, simply swap out the current source of kinetic energy with one that was cheaper and more reliable. After all, building the system of pulleys and gears in the first place had been expensive, and the cost of replacing it would be tantamount to rebuilding the factory from scratch. Budgets were tight back then too, after all. And I’m sure that the old system of pulleys and gears powered by electricity worked just fine, right up until the company got its ass kicked in the marketplace by a company that had embraced electricity even if it meant scraping their previous infrastructure of pulleys and gears.

Eventually, I believe forward-looking enterprises will figure out how much more efficient it is to distribute information directly to the desktop the way forward-looking manufactures distributed electricity. This information will drive smaller, cheaper and more flexible applications directly at the desktop. For a while, companies that are smarter about their use of information will gain an advantage on those that just replacing waterwheels. I assume eventually, everyone will catch one and that advantage will be lost. But there’s a long long time between now and then.

Sean Alexander had a link to WMP Mixer Friday. This is a cool app that lets you have two media streams and mix between them DJ style.

I used to DJ back in college for the campus radio station. We had a remote kit so we could spin tunes for frat parties. Typically, my job at these remotes was to lug heavy DJ equipment, but I did occasionally spin at parties. The one thing WMP Mixer is missing is the ability to preview the next song while the current song is playing. Of course, you’d need more than the standard single audio out that most PCs have these days. I have a 5.1 sound card that I bought for my Media Center and haven’t installed. I wonder if you could play media streams to separate channels (rear speakers could be used for preview). I’m curious if different instances of WMP will let you drive different sound card outputs. I’m guessing no, since I can’t seem to find an option to change the sound output of WMP.