So you want to make a CAB?

Some of my recent work revolved around working with Cabinet files. They're so common, you think this would be simple. In some ways it is, in some ways it isn't.

Let's say you're not a developer. You're simple a user who wants to compress files into a CAB.

From within Windows:

Start->Run>cmd, then enter "Makecab"

And there you go. Easy, right?

You can also leverage IExpress. Start->Run->IExpress. Now you've got a wizard. Cool.

What if you're a software developer and you want to programmatically create a CAB?

If you're a masochist, you could roll your own implementation using the Cabinet.dll API in windows.

My preferred approach would be to download and install the Wix toolset, create a C# project with references to Microsoft.Deployment.Compression and Microsoft.Deployment.Compression.Cab, and just use the CabInfo class. See example here.

These are all techniques that create a simple CAB file. If you want to compress files that span multiple CABs (because of the 2.0 GB limit) or if you want self-extracting CABs, that's a whole other ball game...

WF Rules

One of my recent projects involved an installation application. Before we could install, we needed to examine the current computer, what software is installed, install any prerequisites, detect any conflicting applications, etc.

Ideally we would have used a rules engine for this. In fact, the .Net framework provides one in the form of the PolicyActivity in WF. But didn't necessarily need to do a full WF implementation with the WF runtime in the background.

It turns out that Guy Burstein has a sample of using the rules engine API without hosting it in a workflow:

http://blogs.microsoft.co.il/blogs/bursteg/archive/2006/10/11/RuleExecutionWithoutWorkflow.aspx

Team Leadership

Roy Osherove's 5 Why's Team Leadership blog is fantastic. I've had the benefit of working with individuals who practice some of these techniques, and it has a huge impact on the quality and productivity of the team.

How Does It Know?

I couldn't sleep last night. Something was troubling me.

In my example from yesterday, the PriorityBindings were referrring to plain old C# Properties, not DependencyProperties. Yet...They received update notification. How is this possible?

I've spent many hours debugging bindings. PresentationTraceSources.TraceLevel=High and then you get to see the debugger output as it looks for PropertyChanged events to wire up. So my previous thinking had been that without the properties being DependencyProperties or without the class implementing INotifyPropertyChanged, you wouldn't get updates.

But my explorations from yesterday clearly demonstrated that a PriorityBinding can observe a changing property.

How is this possible?

The only thing that makes sense is if there's some kind of value polling going on in the background. Sure enough, in my searches, I found some references to another thread being used to retrieve values when you use IsAsync. I also stumbled across a patent issues for a priority binding system. "Two-way binding enables changes in the target to be reflected in the model, as well."

I can think of a number of uses for this in my current project. Apparently the rest of my team wasn't aware of its existence either, otherwise it would already be in use. Clearly, I've been missing out on something.

How Many Bindings Are There?

Someone posed an interesting question to me today: How many different types of bindings are there in WPF?

Day in and day out, I use the Binding class, so that was the first that came to mind.

But we also have BindingBase, and wherever there's a base class, there's probably a reason.

MultiBinding is another obvious one, though I've rarely had need to use it.

But what else? I had to look for it, but there's also PriorityBinding. Per the class hierarchy described in BindingBase, that's the last of them.

So what is this PriorityBinding? I've been doing WPF development for several years now and I'm ashamed to say I've never encountered it. Or if I did, it didn't make it past my relevancy filter.

Like MultiBinding, it has a Bindings property that contains a collection of BindingBase. Though the type of this collection is Collection it only supports Bindings. That's what it is, but what does it do?

Its purpose is to prioritize the result of a collection of bindings. You'd use this when some bindings are more "right" than others. A classic example of this is when you're waiting for an asynchronous result. At first you'd want to display an immediate value to your user, maybe something like, "Loading...". But when your asynchronous operation completes, you'd want to display the returned value:


<TextBlock>
    <TextBlock.Text>
        <PriorityBinding>
            <Binding  Path="LoadedString" IsAsync="True" />
            <Binding  Path="LoadingString" />
        </PriorityBinding>
    </TextBlock.Text>
</TextBlock>



public string LoadedString
{
    get { Thread.Sleep(3000);
          return "Loaded!"; }
}

public string LoadingString
{
    get {  return "Loading..."; }
}


Will show "Loading..." for 3 seconds and then it will change to "Loaded!"

Parallel.For and I lose faith in Vista

Jennifer Marsman has an excellent post regarding Parallel.For in .Net 4.0. I love any information that encourages the developer to actually test their code for performance, rather than blindly accepting that the newest approach is necessarily better.

In regards to my Vista debacle...Flipping the registry bits didn't solve a thing. I wiped the disk, did a fresh install, everything worked fine.

This emphasizes the point that there wasn't anything wrong that the original install CD couldn't address. It just means that the authors of the repair utility either didn't or couldn't include this particular fix in their app. Epic fail.

Vista might be the worst OS ever

I'd been living in the world of single-core processors for too long. Yesterday, I decided to do something about it. I went out and got a new motherboard, Core2 Duo, and more RAM. Came home, giddy as can be, swapped out the hardware, booted up my PC. Everything's great Vista starts to load...

BSOD! And then it immediately rebooted so I couldn't even see the message.

BSOD! Immediate reboot.

BSOD! Immediate reboot.

Seriously? Tried the automatic repair, it completetly failed even though it could detect the existing Vista installation. All the "obvious" things one would do when you have a perfectly good installation failed. Time to go a level deeper.

So I had to undo all my lovely new hardware changes, roll back to the original hardware, implement the changes necessary to prevent automatic reboot on failure, put the new hardware back in, and boot again.

BSOD! Except this time I got to see the error:

STOP 0x0000007B (0x80603BA0, 0X00000034, 0x00000000, 0x00000000)

And I eventually found my way to this article which had some insights:

"During the Windows Vista installation process, any unused storage drivers are disabled. This behavior speeds up the operating system's startup process. When you change the boot drive to a driver that has been disabled, you must enable the new driver before you change the hardware configuration."

Lovely. Both mobo's are using IDE cables, so it should be PATA in both cases; one works, the other doesn't...So I'm not sure why this would be an issue, but I'm not a hardware guy, so I'll follow the chain. More importantly, why didn't putting in the original installation media detect and correct this? Vista Ultimate SP2 on the HD, and the installation media was something I won at PDC 08.

I went into the registry and the default StartValue was set to 4, which per this article indicates disabled. I'm backing up my data in case I end up doing a clean install. If this is the fix, there was an awful lot of hardware swapping involved just to change a simple registry value.