Installing Visual Studio 2008

We finally got around to installing Visual Studio 2008 at work the other day and while everyone had a simple time of it on their clean new Vista machines (quad core, 4GB, 500GB, dual 22" monitors) my icky old XP SP2 laptop refused to play the game. Setup was repeatedly failing to install the Web Authoring Component. The .NET Framework 3.5 went in without hassle.

I tried uninstalling 3.5 and starting fresh, checked the event log and the install log but had nothing to guide me on my way. Error info was hard to come by but the Web Authoring Component installer was definitely faltering, identified by this: ISetupComponent::Pre/Post/Install() failed in ISetupManager::InternalInstallManager() with HRESULT -2147023293.

For the record, this machine has VS 2003, VS 2005, MCMS 2002, VSS 2005, SharePoint Designer 2007, and Office 2007 (including Visio and Project) installed.

I got it working in the end so here are a handful of tips to assist with your troubled install journey:

• Nothing of use gets logged to the event logs with this problem so don't bother looking there.
• The install log presented by the installer on failure is high level and won't tell you much.
• Additional install logs get dropped to your %temp% directory (in my case this was C:\Documents and Settings\mhanes\Local Settings\Temp). dd_error_vs_vstscore_90.txt identified the HRESULT error mentioned above but Googling this wasn't too helpful. dd_install_vs_vstscore_90.txt didn't hold much info. A MS site somewhere suggested clearing the contents of this directory before attempting to reinstall again but that didn't help in my case.
• SetupExe.log (from the same directory), however, was quite useful. It informed me, like others, that I had Office 2007 beta software installed on my machine (and this same problem most likely prevented me from installing Groove a few months back). The VS 2008 installer is apparently tied up with the Office 2007 installer or something like that. At the bottom of this file, I was told "Catalyst beta product conflict check failed. Office Beta product conflict is detected on the computer, productcode={30120000-00B2-0409-0000-0000000FF1CE}". As far I knew, I didn't actually have any Office beta software installed so I was puzzled by this one. The error message went on to say: "The 2007 Microsoft Office system does not support upgrading from a prerelease version of the 2007 Microsoft Office system. You must first uninstall any prerelease versions of the 2007 Microsoft Office system products and associated technologies." Fun.
• A few other bloggers out there seemed to have a similar problem and identified 30120000-00B2-0409-0000-0000000FF1CE as the Compatibility pack for the 2007 Office System. M'kay, so I uninstalled it the normal way (early versions were based on beta software and I'd had it installed for ages so this was a likely trouble-maker). Reinstall, no luck, same error message. Running this: MsiExec.exe /X{30120000-00B2-0409-0000-0000000FF1CE } also indicated this thing wasn't installed.
• A few bits of info also suggested investigating HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall so I peeked in there at the 30120000-00B2-0409-0000-0000000FF1CE key and it was identified as Office 2007 Add-in - Microsoft Save as PDF or XPS (Beta). Eureka! Sort of. I uninstalled this in the normal way, re-ran setup, but still no luck--same error message.
• I finally tried MsiExec.exe /x {30120000-00B2-0409-0000-0000000FF1CE} and this time it had some positive feedback.

And the VS 2008 install finally worked! It was even quick about it!

Authored Links Don't Update Between Environments

We have yet to install the latest and greatest content deployment update (the so-called Infrastructure Update) but I think we've pretty much given up on content deployment ever working with the custom controls and web parts used on www.westernaustralia.com. To this end we built our new Tourism Western Australia "partners" solution on the concept of a single environment used for both editing and anonymous access--no more disconnected authoring and production.

So far so good with this solution: we've got the first of many sites out the door (www.australiassouthwest.com) and there's been no looking back despite some unrelated issues. That said, we have come across one very odd problem with authored links not updating from http://edit to https://edit to http://www. We use a reverse proxy in production and do some content rewriting to ensure any stray "edit" anchor tags are rewritten as "www" but as our remote content editors access the secure site, any content links and images created internally on http://edit forever refer back to that site. Relative links don't help in this case because SharePoint helpfully changes relative URLs to their absolute equivalent.

I've isolated the problem to the custom columns or a custom content type deriving indirectly from ArticlePage. We provision these columns and content types via features. Existing columns inherited from the base content type are updated automatically between environments by SharePoint. To top it all off, adding a new column to the existing content type works fine and links are updated correctly in that column.

I've reviewed our feature code and can't even think of a mechanism for disabling this functionality. We're using similar techniques on the westernaustralia.com site (which until recently was RTM plus a bunch of hotfixes while the partners environment was built as SP1) and have no issues in this area when moving content between out authoring and production environments.

I've come across a single technet forum post with a similar problem and the MSFT respondent suggested a case be logged with MS... I imagine we'll soon be taking that path ourselves.

[Update: We raised a case and MS got to the bottom of the problem on our behalf. Here's the solution.]

Uncustomising MOSS Pages - Part 2

The other day I wrote about the frustrations of uncustomising a page layout deployed via a feature to the master page gallery. I've since done some additonal hunting and come across the SPFile.RevertContentStream ( ) method to revert a page layout or master page to its original state so feature deployments work again.

Calling this successfully reverts/uncustomises/reghosts the file in question, although I did notice the version history accessible through the master page gallery remains as-is. Nevertheless, a change to the file system .aspx file after running this code is honoured by MOSS.

Here's the code I wrote to encapsulate that call (it's a bit rough but for a one-off excercise does the trick). I simply run this from a console application (which you can download from here).

// Wait for debugger to attach
Console.WriteLine ("Waiting for debugger to attach. Press any key to continue...");
Console.ReadLine ();

const string FILE_PATH = "/_catalogs/masterpage/ThreeColumns.aspx";

using (SPSite site = new SPSite ("http://dev:30000/"))
{
    using (SPWeb web = site.AllWebs ["/"])
    {
        SPFile file = web.GetFile (FILE_PATH);

        Console.WriteLine ("File status before change: " +
                            file.CustomizedPageStatus);

        if (file != null &&
            file.Exists &&
            file.CustomizedPageStatus == SPCustomizedPageStatus.Customized)
        {
            Console.WriteLine ("Reverting file...");

            try
            {
                file.RevertContentStream ();
            }
            catch (Exception e)
            {
                Console.WriteLine (e);
            }

            Console.WriteLine ("File status after change: " +
                                file.CustomizedPageStatus);
        }
        else
        {
            Console.WriteLine ("Unable to retrieve file");
        }
    }
}

Uncustomising MOSS Pages

The newly-launched www.australiassouthwest.com site is live but suffers a small problem: at some point during development, after we imported content from MCMS 2002, someone or something checked out and published our trusty three column page layout. We deploy our master pages and page layouts using solutions and features, which means those artefacts live in the server's file system and are referenced by MOSS directly. Checking out and publishing one of these pages "customises" or "un-ghosts" the page by effectively moving a copy to the content database; changes made to the original file system content (ie. during a subsequent deployment) are then ignored.

As far as I've been able to determine, it's impossible to roll back to the original version 1.0, although you can sort of do it by checking out the page again, restoring v1.0, and publishing it as v3.0. This will pick up the latest file system content but any future changes won't be automatically reflected. Today I found a system page which does exactly the same thing: /_layouts/reghost.aspx. As the name implies, the end result for the page, page layout, or master page specified is a re-ghosted, or uncustomised, version of the page. I ran this with the page checked out and logged in to the site as administrator so my version update was logged as System Account (it failed using my own domain credentials).

All well and good but I'm still not back to a clean starting point and I think the next easiest option is to create a copy of the page layout in question and point all content pages to that layout. But that's really ugly.

[Update: Here's my solution]

Loving Google Analytics

I'm absolutely loving Google Analytics. The interface is incredibly responsive and the wealth of information made freely available is truly awesome. To date GA has yet to prevent me accessing a particular bit of data the way I want it whereas Omniture's ability to drill into specific reports is stymieing at times. The menu is simply intuitive where I often find it difficult to find specific Omniture reports in their convoluted menu structure.

It's so interesting to know where you're coming from, how you're arriving here, and which posts attract the most attention! Thanks for reading!