when setup isn't just xcopy : bugs

Creative Commons Add-in for Microsoft Office v1.0.1 released.

robmen — Tue, 27 Jun 2006 14:02:30 GMT

As promised, the first two issues reported with the Creative Commons Add-in for Microsoft Office have been fixed. You can go to the download page and get the new version. The installation experience is identical to the previous version and the add-in looks the same. The only changes from v1.0.0 to v1.0.1 were to ensure the Creative Commons license with the correct jurisdiction is downloaded and to have the add-in run correctly when PIAs for Word, Excel, and PowerPoint are not all installed.

The third issue appears to be something with scaling on high DPI systems. The 3Sharp guys spread the dialog out a little bit to help out a little bit. At this time, I do not believe that we are planning another release of the add-in.

I should also note that you do not need to uninstall the previous version of the add-in before installing the new version. The installation will automatically upgrade the previous binaries if necessary.

While no one likes to immediately rollout an update, the events of the last few days have provided me the opportunity to document the story behind the upgrade of the add-in. If all goes well, the next post on this topic from me will actually be about how we built the installation for the add-in.

Supporting the unsupported Creative Commons Add-in for Microsoft Office.

robmen — Fri, 23 Jun 2006 09:52:12 GMT

Tonight I had hoped to be continuing the story about the creation of the Creative Commons Add-in for Microsoft Office. Unfortunately, after a couple days of downloads a few bugs have worked back to those of us working on the add-in. I thought I'd share the known issue list with you and where we are at with them so far.

1. Incorrect Non-Generic Jurisdictions - there was apparently some disconnect on each end of the web service implementation and licenses outside of the Generic jurisdiction were not working. The 3Sharp guys already have a fix for the add-in and the Creative Commons guys are going to tighten up the server-side validation. Of course, that means both of them are waiting for me to get the setup built and rolled out again.

2. PIA Dependency Problems - the Creative Commons Add-in is currently bound to the Word, Excel and PowerPoint PIAs. The tight binding means the add-in has problems loading if all three Office applications are not installed together. Bill Rosenblatt was incredibly helpful as we tracked down why the add-in wasn't working for him (It turns out Bill had Word and Excel 2003 but PowerPoint 2002, this mismatch of PIAs confused the add-in). I'm currently working with the 3Sharp guys to implement a solution for this problem.

3. Funky Wizard Rendering - there has been one report that the controls in the wizard are very large and do not fit in the dialog box. We are all pretty stumped on this one but Martha has an e-mail out to the guy with the problem so hopefully with a bit more information we'll track this one down.

Technically speaking the Creative Commons Add-in for Microsoft Office is an "unsupported technology preview". However, those of us that have been working on this little tool really want you to be able use it. If you hit any issues please send email to "ccfeedbk at microsoft.com".

Finally, expect a Creative Commons Add-in for Microsoft Office v1.0.1 release soon that will address issue #1 above and hopefully fix #2 as well. I'll post more updates on my blog as soon as I have them.

MSN Toolbar Suite Beta setup built by the WiX toolset.

robmen — Tue, 14 Dec 2004 08:45:00 GMT

Since it appears lots of other people are talking about the beta of the MSN Toolbar Suite (Scoble is tracking many of them here and here) so I thought I'd take a look at it. Besides, I'm tired tonight and not up to writing anything superbly technical. Anyway, I downloaded the bootstrapper that kicked off the install. It was obviously a Windows Installer package so I went rooting around for their MSI file to see what I could see. I finally found a copy of it (in the Windows Installer cache that I will talk about some other night) and popped the MSN Toolbar Suite's MSI file open in Orca.

At first, I was pretty excited because the installation package was written using the WiX toolset (albeit a version of WiX built about four months ago). Unfortunately, as I investigated deeper, I saw some non-ideal authoring. For example, the Directory table has a number of entries where the short and long names for the directory are identical. This bloats the package for no reason. More recent builds of the WiX toolset print out a warning to inform the setup developer about that kind of unnecessary duplication. Also, I noticed a large number of invalid identifiers in the MSI file. Those also would have been caught if built by a more recent build of the WiX toolset.

As you can see, the WiX toolset is slowly getting smarter about bad authoring. I've even considered adding a "-pedantic" switch to candle.exe many times to catch things that just shouldn't be done in an MSI file. However, for now there is plenty of error checking to tighten in the WiX toolset without the "-pedantic" switch. But, I digress...

Fortunately, none of the errors described above are fatal with the current versions of the Windows Installer available so the Beta installed just fine (it's indexing my machine right now). However, to ensure future compatibility with the Windows Installer at least the identifier issue should be fixed. Also, fortunately, this release is just a beta package so there is still time for all of the issues to get fixed. Finally, a few of the MSN Toolbar Suite guys are coming up to Redmond this week (they are down at the Silicon Valley campus) and they've scheduled lunch with me to talk about how they are using the WiX toolset. I'll raise these issues with them again there.

Oh, and I agree with Michael Giagnocavo, "What's with the shortcut on the desktop? Don't do that! The desktop is the user's space. At least ask for permission to stick stuff there."

Update on the status of the Office Local Installation Source.

robmen — Fri, 24 Sep 2004 20:23:00 GMT

A while ago I asked for help tracking down what appeared to be a bug in Microsoft Office System 2003's Local Installation Source (aka: LIS, codename: LocalCache) feature that meant the Windows Installer still required the original source media when patching. Many people answered my plea and with their help at least one of the bugs causing the problem was tracked down and killed. It has been a while since I got back to this issue and people continue to send me requests for help so I thought I'd post a follow up that tries to summarize everything that I know about the issue at this point in time.

First, all of the issues related to LocalCache that I will cover here apply only to Office 2003. Office XP and any version of Office before that do not have the LocalCache feature. If you are having issues with Office XP or earlier the only useful piece of information I have for you is my next point.

Second (and I seriously considered making this my first point), if you have reached the point where you are being prompted for the original source media (for example, the Office installation asking for SKU011.CAB) then you will have to find the source media. I am very sorry but I know of no way to get back into a good state without providing the original source media for your copy Office. Over the last few months, I have heard many tales of loss and despair where the common theme was no longer having access to the original CDs and/or network installations. You have my sympathies but all I can offer now is that this problem has renewed my desire to solve the issue at the root cause (the installation technology itself). At least, in the near future expect an explanation here about what causes the source media prompt and why LocalCache came to be.

Third, after you have found the original media I would suggest enabling the LocalCache using the Local Installation Source Tool (listool.exe). I discussed the listool.exe in more detail in a previous blog entry. I suggest using the listool.exe to get back in a good state because it does a number of checks to make sure that your LocalCache is valid. After using listool.exe to fix your LocalCache, you should not see a prompt for the source media again assuming two things: you do not clear the cache yourself and you install Office 2003 SP1. See the next two points for more details.

Fourth, many people that contacted me about Office 2003 requiring the original source media during patching had cleared their LocalCache. There are many ways to clear the LocalCache but three seemed to be most common. First, you can check the box at the end of the Office installation that said, "Delete installation files". Second, you can use the Disk Cleanup Tool and check the "Office Setup Files" box. Finally, you could delete the "MSOCache" directory that appears on one of your drives (note: playing around with this directory is highly discouraged). To be clear, clearing the LocalCache makes it almost certain that you will be prompted for the original source media during patching or other repair operations. That is why I highly recommend using the listool.exe to ensure LocalCache is enabled and then do not clear the cache.

Fifth, you need Office 2003 SP1 to kill off a bug that was causing the LocalCache to inadvertently be cleared. K tracked this down to a case where if rollback occurs during repair or patching (due to an error or user cancel) then too many files could be removed from the cache. The goal was to have only the files requested to the cache for repair or patching to be removed when a rollback occurred. But the bug caused all files necessary for the repair or patching to be removed. The first file to be removed is usually the SKU###.CAB (for example, SKU011.CAB) that is almost always needed for any repair or patching operation. K fixed the bug in Office 2003 SP1 by just removing the code since caching files during a repair or patching is an edge case and it is very difficult to correctly calculate which files were added to the cache during the repair or patching operation. It is safer to leave a couple extra cabinets in the cache than to remove too many cabinets.

Finally, if you'd like more help trying to fix your LocalCache I suggest checking out the microsoft.public.officeupdate newsgroup. There is some great information out there. In particular, I find this post, this post, and this post are particularly pertinent. Sloan Crayton was the Product Support Services (PSS) engineer I worked with for a number of years in Office and I have kept him in the loop with all the information I've gathered from my blog here. He usually has the best answers for any of your Office installation issues.

Best of luck and check back here in the future if you'd like the story behind LocalCache (and how it was supposed to help prevent source media prompt problem).

Weird parsing problems using the Windows Installer XML (WiX) toolset?

robmen — Thu, 08 Jul 2004 15:59:00 GMT

If you are using the Windows Installer XML toolset to compile very large .wxs files, you may have hit a bug where candle.exe or light.exe essentially complain that your XML is invalid. This was tracked down to a bug in the XmlReader class where XML processing instructions are not always parsed correctly. Back then I was told the bug would be fixed in the .NET Framework 1.0 SP3 or .NET Framework SP1.

Well, I just noticed that the .NET Framework 1.1 Service Pack 1 Tech Preview was recently released. If you are daring (or desperate) you can try the Tech Preview, it should contain the fix for XmlReader bug. Of course, the Tech Preview is not release quality code so you might encounter other problems.

In any case, my understanding is that the .NET Framework 1.1. SP1 and .NET Framework 1.0 SP3 should be released later this year.

[Update: Found a link with more information about the .NET Framework Service Pack Tech Previews]

VBScript (and Jscript) MSI CustomActions suck

robmen — Fri, 21 May 2004 06:59:00 GMT

Today was one of those days where you finally get around to looking at the time and wonder where the heck the hours went. It wasn't even like I really got a lot done. I think my context switch costs have been really high lately. It feels good to finally be home chilling out to the Perfecto Chills albums. I thought I'd relate a short story to you why VBScript (and Jscript for that matter) should not be used for CustomActions in an MSI.

Today, I realized it was 15:39 when a fellow developer, we'll call him Joe, called me at work. My first thought was, "Jeez, it's almost 4 o'clock and I haven't got anything done!" My second thought was, "I bet Joe is screwed." Joe only calls me when the WiX toolset has completely failed or he has hit the wall with the Windows Installer. Today, Joe had hit the wall.

"Rob, have you been tracking the email thread about the CustomAction of mine that is failing?" I had seen this thread earlier in the day and remembered Joe mentioning something about a VBScript CustomAction. "A little bit, you're not really using VBScript for your CustomAction, are you?"

That was it. Joe was attempting to debug some rather complex issues with a VBScript CustomAction interacting with some COM components during an install. Everything seemed to work fine if he ran the VBScript (slightly modified) in the cscript.exe or wscript.exe hosts. However, when the script executed in the Windows Installers ActiveScript engine it failed in rather mysterious ways.

Interestingly enough, a Windows Installer developer attached one of the many emails that I send to people when they are having problems using VBScript for CustomActions. In those emails, I always suggest that script never be used for CustomActions in MSI. So, Joe called me and asked, "So what can I do, Rob?"

My answer was simple, "Joe, there is a reason I recommend never using VBScript for CustomActions. It's because there isn't really a whole lot you can do when you get into this kind of situation." Then I provided him a few ideas that started with attempting to get the script debugger to somehow attach and try to then debug over to the COM component and ended up suggesting getting the command-line debugger attached to the COM component on load. None of which is trivial.

What I don't understand is why people completely disregard dire warnings that certain technologies should not be used in certain circumstances. Yes, I understand it is extremely easy to write CustomActions in VBScript. No, that doesn't make it a good thing to use in your install.

So, I'm blogging here tonight at the end of a very long day to share with you three reasons, I recommend you not use VBScript or Jscript for CustomActions:

1. Robust code is difficult write in script. Setup code must operate on machines that are in an unknown state. In such hostile environments, there are many different ways that code can fail. Properly recovering from error conditions is very important (even if it just results in rollback). "On Error Resume Next" is not conducive to proper error handling in code. For this reason alone, Microsoft Office banned all script CustomActions from their MSI files. I am admittedly biased but I believe Office has one of the most impressive, smooth, and stable setup programs for the Windows platform, especially considering its complexity.

2. Debugging script in the Windows Installer is difficult. Some might even argue it is impossible to debug script CustomActions. As Joe is going to find out for the next few days, debugging the interactions between the Windows Installer, the scripting engine, and any other objects is a non-trivial task because the tools are so primitive. There are many tools for C/C++ code that can have very low impact on the machine if you are tracking a particularly skittish bug. Maybe I'm only called in when bugs are really hard, but there have been many times I was thankful for ntsd and pageheap.exe.

3. Anti-virus products kill them. This one just killed me. A couple years after Office banned the use of scripting for CustomActions, Visual Studio shipped their first MSI setup. They decided it would be okay if there were a few script CustomActions. When customers got the product, PSS started getting reports of the Visual Studio setup mysteriously failing and rollingback. After some very long calls, PSS discovered that if the users' anti-virus programs were disabled the installations would succeed. Turns out many of the top name anti-virus programs considered the scripts hosted by the Windows Installer to be virus and would kill the scripts off failing the Visual Studio install.

Anyway, hope you enjoyed the stories and remember, "VBScript and Jscript suck for CustomActions."

Did you LocalCache and find that Office still requires the installation CD when patching?

robmen — Thu, 05 Feb 2004 07:58:00 GMT

Update 09/24/2004: I am no longer looking for more information related to this issue. Please see this blog entry for the latest information about LocalCache issues. Thank you to all who provided information that helped determine just how prevalent this issue is and where to go searching for the bug.

Last year I posted a blog entry that mentioned my work on the local installation source (LIS) feature (that I call "LocalCache") for the Microsoft Office 2003 System. That blog entry generated quite a few comments where people mentioned that patches to Office were still requiring the installation CD. Then I saw a link from Scoble's blog to this blog entry where people were complaining that they needed the original Office CD to install updates. Finally, K (who is the developer in Office that took over LocalCache when I moved to Windows) mentioned over break that his new laptop required the installation CD when demonstrating how installing a patch from Office Update shouldn't require the original source media. Needless to say, it appears there is something not quite right with LocalCache out in the wild.

So K and I spent this last Monday morning trying to reproduce the problem on some machines other than his laptop. Unfortunately, after several attempts we never had the problem occur. Independently, one of the Office testers also tried to reproduce the problem with the MSDN Universal CD (where I first heard of the problem) and couldn't get it to occur then either. PSS hasn't had a lot of people calling in about this one and don't think there is an issue here. However, I think that there haven't been may calls because customers are (unfortunately!) used to requiring the original installation CD when patching.

K and I are going to beat on this problem a bit longer (we thought we found something that might be the issue on Monday but didn't pan out). So, I'm out here asking that if you installed Office 2003 and have subsequently tried to install the patches and the patches required the original installation media, would you please contact me? Just send your email address and I will likely get back to you asking for a bit more information about your machine's configuration and how you installed Office 2003.

I really want to kill off this bug (or at least understand what is going on if there turns out not to be a bug) and any help you can provide will be much appreciated.

WordBlogX and its setup

robmen — Tue, 09 Sep 2003 09:29:00 GMT

It somehow seems appropriate that my first post to a blog destined to focus on setup should be about setup bugs in the tool used to write to the blog. Namely, my housemate just released WordBlogX and when I tried to set it up I hit several issues trying to configure it on my machine. Amusingly, this gets me recognition in his blog.

Anyway, things appear to be moving along and Word is new happily green squigglying (and red squigglying that) comma splices and fragment sentences. Now, we can get on with the show!