Lifestyle of the MSIdle

I'm a slacker!

I was reminded that I haven't posted in a while and that I've been a slacker. I profusely apologize and hereby seek to remedy that situation.

So here's what I've been up to...

 Why should you avoid using the TypeLib table ?

I have a customer trying to consume a merge module that we produce. The customer is creating his installer using Wise.

I created the merge module using InstallShield 12. The merge module includes a COM dll that is self-registered. In my merge module I set the DLL to extract COM data at build time. This is so that the registration data stays up to date in the installer. Unfortunately, the way that InstallShield works, this causes it to create the registry entries in the TypeLib, AppId, Class and ProgID tables instead of lumping it all in the Registry table. 

The Wise system refuses to consume a merge module with entries in the TypeLib table and errors out. Why?

See the Remarks in this MSDN article about the TypeLib table http://msdn.microsoft.com/en-us/library/aa372092(VS.85).aspx.

So... I'm left wondering at this point, how am I supposed to use InstallShield to dynamically update the COM registration information at build time and yet still produce an 'acceptable' MSI/MSM? I haven't resolved this issue yet. So far I've had to manually modify the MSM for that one customer who's using Wise. Customers using InstallShield don't have a problem.

 CVS is problematic and my builds aren't reliable

I've been having problems with builds failing on an irregular, but annoyingly often basis. I use CruiseControl.NET and CVS at the moment, because these are open source (free!) tools. I'm NOT on the most up to date version of these tools due to the fact that I need to test out these tools in a non-production environment before I can implement the newer versions and I don't have access to a non-production environment yet. It's in process though! The problems I'm having with the builds are these main issues:

• CVS "cannot change permissions on temporary directory" errors. This error appears multiple times a week. I haven't been able to find any solution or explanation for this error in all my googling. All I can find is "yeah, this happens, we don't know why, just try again and it will work". This is true, in that if you immediately do another build it does succeed. But that doesn't make it acceptable to have builds failing. This is an unresolved problem for me at this time.
• CVS times out when trying to apply a label/tag. CruiseControl is using its internal APIs (?) to effect the CVS tagging so I can't get a good detailed log of what's going on during this process of why it's freezing up. Since tagging doesn't happen until after the build is finished and successful, this is really annoying to have it fail at the very end. One potential handling is to stop using CruiseControl to do the tagging, but I hate to so obviously bypass the built-in functionality.I'll probably try this technique soon. Unresolved at this time though I do have this technique to try out.
• Network briefly blips and loses access to the network device on which files are being copied. Using MSBuild to do a copy task which copies dozens to hundeds of files. If there's a momentary blip and it can't copy a single file -- this causes the entire build to fail. The network shouldn't be blipping in the first place, but.. until that is solved, it would be ideal to have a copy function that is more robust which could try copying - if it fails, wait a sec and try again, and don't fail out unless more than one copy attempt fails. I could do this pretty easily in nAnt, but this particular build is in MSBuild and I'm not very familiar with MSBuild yet. The suggestion that was given me was that I need a custom MSBuild task written in a DLL. (sigh! More DLL writing) Haven't tackled this one as yet because we'd prefer to fix the network instead.

InstallScript custom actions fail due to ISBE.dll not registering on Windows Server 2008

Lastly, in a big installer I started working on converting all the VBScripts to InstallScript because management prefers InstallScript to writing new DLLs for custom actions. Unfortunately, The test machine for this installer is a Windows Server 2008 OS and we immediately started gettting install failures due to the InstallScript CA engine (ISBE.dll) failing to register on the machine. I made a test installer and tried it out on other 64-bit machines (XP and Vista) and it works fine, but it fails on this one Windows Server 2008 machine. Currently working with InstallShield to see if they can help get rid of this error. Until this is solved, I can't work any further on converting scripts to InstallScript because it creates a perception in management that InstallScript is unreliable.