Learned Something New: CHM on UNC Behavior

Stefan Krueger emailed me asking if I had problems viewing the new MSI.chm. To be honest I hadn't even looked at it yet ( despite my moaning earlier this year about not having access to to it ) because I've been so swamped with recent changes at work and the struggle my wife is going through.

After finally downloading the file and testing it on a clean virtual machine, I stumbled onto the fact that the CHM wouldn't work from a UNC path but that it would work when I copied it locally.

So I did some searching and I found a KB article from Microsoft pointing in the direction of a change to CHM behavior in security bulletin MS05-026.

I had never noticed this behavior before. I love learning something new every day. Now off to read the MSI.CHM and learn a few more new things.

Who Had Some Fun This Weekend?

A recent post by Rob Mensching made me wonder a question:

What cool fun did you do this ( or a recent ) weekend?

You you know I'm what is called a Foodie. Fortunately or unfortunately, I love to eat. Since moving to Texas, I've really grown to appreciate peppers like I never did before.

Poblano, Green chili, Serrano, Jalapeno, Habenero and Scotch bonnet. While I do like the heat ( as anyone who has had my Jamaican Jerk Chicken can attest ) I really like to get past the heat and enjoy the flavor of the pepper.

So my fun for this weekend it was all about one word: Hatch


You see, as the summer winds down it's that time for the annual harvest in a small New Mexico town known worldwide for this yummy peppers. While I can't make it out there to the festival with my father in law ( who lives in ABQ, NM ) I can certainly stop by Central Market and load up. And load up I did! They sell the peppers preroasted but it's just not as fun as doing it yourself. So I spent hours roasting, steaming, skinning and cleaning peppers. Some I used right away for green chili hush puppies, green chili remoulade and green chili tarter sauce. The next day I made green chili guacamole for a seven layer dip. But most of it will be frozen to provide an endless supply until next year.

Of course I also picked up all kinds of goodies like green chili pork sausages. This ensures that when friends and family come to visit to help take care of Cheryl, we'll have plenty of fun foods to grill and eat together.

So don't forget, post a comment telling me about your fun weekend.

Time for Change Again

Well, it's been about a year since I changed employers so I guess it's time for my next move.

I'd like to say goodbye to my friends at Hart InterCivic and say hello to my new friends at Manatron.

Well, kinda.... It seems that my group has been purchased so I'm not really going anywhere other then on paper. Well, kinda... we will be moving to a new building.

For anyone who's curious, I've been trying to count how many jobs I've had over the years and I can't because I can't decide on how to count a job. The answer is somewhere between 7 and 11 though with the longest being 2.5 years and the shortest being 3 months.

FormatMessage Bug?

A recent thread in the PlatformSDK.MSI newsgroup involved a question on why calling FormatMessage() for MSI errors above 1644 didn't return a message.

I had never noticed this before and I'm at a loss other then to wonder if it's a bug in Windows. I tried InstallScripts FormatMessage() wrapper and I wrote up a C# class that DllImports Kernel32.dll to call FormatMessage(). Neither work... I havn't tried on Vista yet.

Has anyone else ever seen this before?

BUGBUG: Yikes!

Black and Yellow Argiope
Argiope Aurantia

I couldn't help taking a picture of this scary looking, yet harmless spider this morning. It's the coolest thing I've seen in awhile so I'm going to let it live what's left of it's short life. Regardless, it's a fitting picture for my thoughts today.

I've been getting contacted by fellow developers thanking me for noticing the InstallShield COM Extraction bug. I did a dinner/movie with a former coworker who expressed relief that this was found.

But the truth is, I didn't catch it, I just finally noticed it. Others have been stung much worse and I'm suprised that given the severity of this issue, that Macrovision hasn't been more proactive in raising attention to this issue. The annoying Update Manager popped up on my screen today and it wasn't listed. There wasn't a DevLetter style email, or anything else.

I decided to do a search of Community and I found this interesting thread:


And just to prove history repeats itself, this has happened before:



BTW, I don't know about you, but when I encounter the same bug more then once, thats a clue to write a unit test. Perhaps my next blog will be an InstallScript ICE that checks for scary registry table entries. Until then, remember two things: Always use an integration test machine that you can virtualize or reimage and always test your uninstalls.

InstallShield COM Problems

In a recent blog I spoke about a nasty experience that I had and a hotfix that was available in IS2008.

I've been thinking about it more, and I realize that I actually experienced that problem using IS12! What this means is that while the hotfix is available for IS2008, IS12 users are actually at risk also. The KB article says that it applies to IS2008 but it should also say that it applies to other versions since the work around notes state:

Workaround
For users who are not using InstallShield 2008, please use the following steps to work around this behavior:

Disable the 'COM Extract at Build' property for the component with the '*' character in the 'Name' column of the registry table
Locate the 'Advanced Settings' -> 'COM Registration' view of the component
Right click on 'COM Registration' in the middle pane, and select 'Extract COM Data for Key File'
In the Direct Editor, locate the offending entry with the '*' character in the 'Name' column of the registry table, and delete it.

A hotfix for IS12 would be good, but to be honest, I don't reccomend using COM Extract at build unless you always plan on doing Major Upgrades and you know your COM components don't have binary compatibility.

InstallShield 2008 HOTFIX: COM Extraction Causes System Corruption during Uninstall

About a month ago I was working on an Installer for a North-Texas company when I did something I would normally never, ever do.... install/uninstall an untested prototype install on my dev box. The results were horrific... my entire network stack was trashed, all kinds of services weren't running and I actually got a message from Windows Vista saying something to the effect that a certain error that should never occur, occurred.

I looked at my package to see what could have happened and I noticed some TCP/IP settings had been picked up as part of a COM Extraction. I grabbed another laptop, transcribed the data and rebooted and all was well. Whew... bad setup developer!

I didn't think much more about this because at my day job we have almost no COM in our solution. The Server Installs ( Web Services and WebUI ) are pure .NET and the client only has some third party controls that we interop with. But all of those COM servers were authored in InstallShield 12 with the Right-Click Extract COM pattern. They never had a chance to be butchered by IS2008.

Then I came across a KB article today that described the exact situation that made me lose a few heartbeats.

I'll let you read the article, but basically it described a situation where the COM Extraction didn't filter well enough and that there is Hotfix available. I'd pick this one up for sure....

.NET CA's are NOT (always) Evil

I recently came across this post on the WiX-Users mailing list:

Be very careful using C# within a Microsoft Installer based installation(like those generated using WiX). By doing so, you place an additional dependency on the .NET framework, and has been discussed many times this is a *bad thing*. Ideally you should choose something (e.g. C++) that can be built to have minimal (ideally no) external dependencies.

I couldn't disagree with this poster more. Adding the .NET framework as an install time dependency is not automatically and blanketly a "bad thing". It is increasingly becoming an "inevitable thing". After all, how else would you publish assemblies to the GAC? How else would you PreJIT assemblies?

I would agree that it's a bad thing to do things like use Installer Classes to use the framework to install services when MSI is natively capable of doing that, but not just because it's a MC CA, but because it's an unneeded CA in general.

The reality is we are now starting to see new API's that have no unmanaged counterpart. We are having developers write managed code and they are now business requirements for doing things that can only be done in .NET or are done in with 95% less effort in .NET.

We can bury our heads in the sand and repeat the '.NET is Evil' group think, or we can get with 2007 and start using .NET to our advantage and demand that the Windows Installer team do the same. Otherwise MSI's days are numbered.... remember after all that only about 50% of the setup space has switched to MSI. Other technologies are still out there.