RobMensching.com /Blog
when setup isn't just xcopy

WiX toolset bug count after February 26th, 2009.

It might not look like it but we made progress on WiX toolset bugs tonight. There is a fix inbound for the remaining candle and pyro bugs. The documentation bug is actually something on the MSDN side of things, I believe. Votive and DTF still are not seeing progress due to missing members. Net we're up 3 bugs from last week with 35 as the total.

The most interesting news on the bug front is that Brian has almost completed the mission I sent him on to apply everything that we've learned over the last couple years about generating MSI identifiers to heat. It changes a lot but I believe the changes will address the core weaknesses in heat that are the focus of the bugs. Brian said he'd do a detailed write up after he gets everything checked in... which hopefully is next week.

Finally, one of the reasons the resolve rate was lower this week was that Eric tracked down a second performance issue in the WiX toolset. I already knew there was a performance problem in the smart cabbing feature but Eric found a slowdown in the .wixpdb generation introduced in the last month. There have been a couple random mentions of performance degradation but this was the first time we had a repro that we could dig into. We'll have fixes for those performance issue soon.

In the meantime, keep coding. You know we are.

 

[Sorry, this is delayed, been having server issues.]

Interesting. How did you guys get the SHA1-generated identifiers to work given that they would be 160 bits versus MD5's 128 bits?

We didn't. Currently, the numbers are just truncated. With the limited number of people that should require -fips, if there is a collision, they can route around it by hand. At least, that's the current thinking. Note, this algorithm is only used for internal MSI ids, not GUIDs. Another (recent theory) is that if we use SHA256 any 128 bits should be pretty unique.