Ramblings & Rants : Windows Installer

DeployNow.com and "Smoke"

Michael — Fri, 13 May 2005 01:10:00 GMT

I’ve had a lot of people asking me lately what has become of the DeployNow.com site and more importantly, about Smoke – my Windows Installer validation tool.

As enthusiastic as I was about building a community site for installation developers, the idea just didn’t take off on it’s own, and I just don’t have the time to invest in it right now. The domain expired a while back and I just never bothered to renew it. I just paid the renewal fee a few minutes ago, so it should be back online in a day or two, but please don’t expect any updates or new content anytime soon.

In the meantime, you also fine Smoke here.

Guru.com & Dispute Resolution

Michael — Sat, 15 Jan 2005 14:30:00 GMT

If you’ve been following along, I am trying to recover some money that I paid for web design work that I ultimately learned had been stolen from http://www.creative.com by Shayna McCullough under the name of a non-existent company called Iconic Media.

Early on in the process, I went to guru.com which is where the transaction took place, hoping that they had some policies in place to protect me under these circumstances. I search ed all over the place and couldn’t really find anything, so I eventually ended up scouring their terms of service. I was disappointed to see how vigorously they position themselves as a provider of payment services. I guess I understand this in a way since they really don’t have any control over who does what when it comes to actually executing these projects, but it does seem that a basic tenant of their service is to provide some insulation and protection should thing go bad.

I did not get guru involved in this early enough, I guess because I just didn’t think they would offer any help. I was wrong to have made that assumption, and while this is not yet resolved, I think their actions thus far are commendable and I’d like to thank them for the effort they have already expended.

Within a couple of hours of filing my complaint on their website, I received a fairly lengthy reply that was organized and well thought out. This wasn’t the kind of template based reply you might expect, but a couple hundred words that dealt specifically with this case and the people involved. The message described exactly what they would do to try to resolve the matter, and what my options were if they were not successful. They asked for more information, which I supplied to them, and they followed up again to let me know exactly what they were planning to do.

I have not heard what the outcome of those efforts were yet, but I am really impressed by the sincerity with which they are pursuing this. I still don’t know if I’ll hire anyone off guru.com again or not, but I do feel a lot better knowing that they do care.

I think the lesson here is that it is always better to try to get someone to help you than to just conclude based on the their legal mumbo jumbo that you are all alone in these kinds of matters.

To the folks at guru, I thank you for your efforts, whatever the outcome may be!

Business Fraud Alert!

Michael — Fri, 14 Jan 2005 14:49:00 GMT

A few months agao, I contracted a “company” that goes by the name “Iconic Media” through http://www.guru.com to design a new site for an eCommerce project of mine which was to be launched at http://www.xambi.com. A woman named Shayna McCollough was the one and only person from this outfit with whom I have dealt with. After paying her $2000.00 and investing significant amounts of time in waiting for a design, she finally delivered what I initially believed to be a decent design. After having a few peers review the design, it was brought to my attention that the design was an exact rip-off of http://www.creative.com. When approached about this flagrant theft, Ms. McCollough mysteriously disappeared and has not been heard from since.

Please be aware that this work was contracted through Guru.com which portrays itself as a safe intermediary between companies and contractors, yet has done absolutely nothing to help us resolve this situation.

At all costs, please avoid using this company and if you are so inclined, drop Ms. McCollough an email of better yet, a phone call and let her know what you think of her dishonest, if not criminal acts. Here is all the info I have:

http://www.iconic.cc

Shayna McCollough
smccullough@iconic.cc
Phone: (727) 507-0424
Fax: (310) 388-5747

A whois search turned this up:

Registrant:
   Iconic, Inc.

   468 N. Camden Drive, Suite 200
   Beverly Hills, California 90210
   United States

   Registered through: GoDaddy.com (http://www.godaddy.com)
   Domain Name: ICONIC.CC
      Created on: 26-Oct-03
      Expires on: 26-Oct-05
      Last Updated on: 19-Oct-04

   Administrative Contact:
      Manager, Domain info@gmi.cc
      Iconic, Inc.
      468 N. Camden Drive, Suite 200
      Beverly Hills, California 90210
      United States
      8882888135      Fax -- 8882888135
   Technical Contact:
      Manager, Domain info@gmi.cc
      Iconic, Inc.
      468 N. Camden Drive, Suite 200
      Beverly Hills, California 90210
      United States
      8882888135      Fax -- 8882888135

   Domain servers in listed order:
      NS1.IDX.NET
      NS2.IDX.NET

A google search on that address revealed a plethora of businesses using the same address, which would seem to suggest that it is a mail drop of some sort.

A State of California Corporate Search turned this up:

Corporation
GEMINI MEDIA, INC.
Number: C2390033	Date Filed: 2/4/2002	Status: suspended
Jurisdiction: California
Address
6176 PERWINKLE WAY
WOODLAND HILLS, CA 91367
Agent for Service of Process
SCOTT C LONIS
6176 PERWINKLE WAY
WOODLAND HILLS, CA 91360

Lastly, if you are an attorney, know an attorney, or have contacts in law enforcement, please send their info on to me as I can use all the help I can get in working this out.

Thanks!

UPDATE:

Here are some image links:

A snaphot of each site:
http://msmvps.com/images/msmvps_com/michael/1069/o_Full1.png
http://msmvps.com/images/msmvps_com/michael/1069/o_Full2.png

The Header of each site up close:
http://msmvps.com/images/msmvps_com/michael/1069/o_Header.png

The footers:
http://msmvps.com/images/msmvps_com/michael/1069/o_Footers.gif

Left Nav:
http://msmvps.com/images/msmvps_com/michael/1069/o_LeftNav.png

Lower portion of left nav:
http://msmvps.com/images/msmvps_com/michael/1069/o_LeftNav2.png

Page Headers:
http://msmvps.com/images/msmvps_com/michael/1069/o_PageHeaders.png

Also, you should know that the differences you do see between these designs is in every case, a result of my feedback to them during the process. Of course at that time, I had no idea the design had been stolen from Creative...

Washing my hands...

Michael — Tue, 11 Jan 2005 02:19:00 GMT

So, after all that ruckus with Rob Mensching about COM Advertising from before Christmas, and my sincere gesture to clear the air, it seems that nothing is really resolved after all.

Just before I posted my very nice attempt at clearing the air, I put together a little sample that exactly duplicated the scenario Rob gave me under which COM Advertising had the alleged ‘bugs’ or ‘wonky’ behavior. Of course, no matter how hard I tried, I could not break COM Advertising or even come close to reproducing the behavior Rob described. It worked perfectly every time in every scenario I threw at it. I wanted to clear the air between Rob and I, but wasn’t and never have been willing to concede that there was a bug there unless Rob could tell me what the bug was. Of course he never did, so I very thoroughly documented my test rig and the scenarios I threw at it, and emailed it to him for him to comment on. I told him I wanted to clear the air and would be posting an apology to that end, and asked that he either show me the alleged bug(s) or concede (publicly) that there are no bugs in COM Advertising. It’s been almost three weeks now, and I’ve never heard from him again. At first, I thought he was working like a mad-man trying to create some bizarre scenario in which it would break, but eventually I concluded that when faced with irrefutable evidence against his position, he just decides he’s too busy to back up his allegations. This is not the first time, but actually the second time. The first was over some bogus comments he made about using INSTALLDIR instead of TARGETDIR, but that’s a story for another day…

So, while I wish him and the WiX project well, I am done with him. He lost my respect through this episode, and in my opinion is a poor reflection on Microsoft’s integrity.

I’ll be working on an update to smoke sometime this week, then be posting the source code for anyone who is interested in using it.

Setting things right...

Michael — Thu, 23 Dec 2004 18:12:00 GMT

The last few days have been pretty interesting around the WiX Toolkit community, and I guess I’ve been the catalyst for most of the commotion. A lot of folks have been following along as I publicly aired by feelings about some of Rob Mensching’s comments on COM Advertising, but what you may not know is that Rob and I have also been exchanging some very lengthy emails offline. In spite of what you may have seen publicly, our offline emails have been anything but a shouting match. We both shared our feelings on a number of issues that we were both concerned about and I think we both benefited from the exchange by learning about each other and how to interact with the community. I’m writing today to own up for my mistakes and set things right.

My comments through this whole thing have been motivated SOLELY by my passion for Windows Installer and deployment technology in general. I have committed myself to this segment of software development and that commitment has been both a blessing and also an enormous curse for me personally. The result of everything that I’ve been through is that sometimes I tackle things a bit too aggressively. So, while I adamantly insist that both my intentions and arguments were honest and correct, I recognize now that my demeanor and mannerisms were easily perceived as being brash and abrasive. For that, and that alone, I extend my sincere apologies to Rob, and to anyone else following along who may have felt insulted by my words. I do see now that I might have been able to achieve my goal of making this an important issue without resorting to “shock” value to get people’s attention.

I’m happy to be putting this behind us, and look forward to working with Rob and everyone else in a much more productive (but less exciting) fashion in the future!

Oh – and by the way – I realize that the underlying issue of COM Advertising may still be a question in some of your minds, so I think you can expect to hear more on the topic from either Rob or myself very soon! ;-)

Doh! - My Secret Agenda Revealed...

Michael — Wed, 22 Dec 2004 22:56:00 GMT

Ha! Ha! Thanks for the laugh Justin!

Seriously now. How anyone can come to the conclusion I have a secret agenda to promote some other product when I am in the process of contributing smoke, and fighting hard to keep features working with WiX Toolkit is a mystery to me, but I guess stranger things have happened…

For the Record:
I have NO AFFILIATION with any company anywhere. I am NOT pimpin’ any commercial product, and frankly, even if someone wanted to pay me to evangelize their product, I don’t think they could afford me (but they are welcome to try!). I’ve got big plans for the future and a great relationship with industry leaders like Wise and InstallShield. I may do work for them from time to time, but the only agenda I am pushing is my own, and there is certainly nothing sinister about that...

COM Advertising Support in Windows Installer

Michael — Wed, 22 Dec 2004 12:35:00 GMT

Yesterday I mentioned some discussion on the WiX Toolkit mailing list about the use of COM Advertising support and the challenges that go along with it. Rob Mensching argued that the tables which enable this functionality should be avoided due to some “strange behavior” that he has seen. I pressed him for more information, pointing out that most of the 43 merge modules that you can get here and the MSXML, SOAP, FoxPro, and Crystal Reports Merge Modules all use this technique without any problems whatsoever. Additionally, Office 2003 makes extensive use of this feature, so I really wanted to know what was driving Rob to make such a statement.

Rob followed up today with a vague reference to some bizarre scenario where if you install Office XP and the Speech Control Panel Applet in a particular order, a repair would occur the next time you launched the Speech Control Panel applet. While I appreciate Rob’s follow-up, I am disappointed as it does nothing to explain what the specific problem was and why this scenario proves that COM Advertising is fatally flawed. Based on what he said, it sounds like a one-time repair that is required to get Office and the Speech API in synch. While having to dig for your Office CD is a bit of a bummer, it does not sound like that outrageous of a scenario to me. For what it’s worth, my searches of the Knowledge Base did not turn up any results that seem to describe this problem.

We have to move on, so I wanted to post these as my final thoughts on this issue:

Rob is a Microsoft employee with strong ties to the Office and Windows Installer team. If his assertions are correct, why didn’t the Windows Installer team deprecate the use of these tables in Windows Installer 3.0? Why does Microsoft continue to advocate the use of these tables in the Windows Installer docs? Why can’t he cite a specific technical problem that supports his position? Why is there not a single Knowledge Base article that even mentions this problem?
WiX supports authoring <Class/>, <TypeLib/>, and <ProgId/> elements which should be built into the Class, TypeLib and ProgId tables respectively. In spite of you specifically authoring these elements, WiX will ignore your intentions and dump the data into the registry table instead. WTF? I mean, come on. If you want to make your own personal and unsubstantiated assertions that COM Advertising if fatally flawed, then fine. That is your opinion, but why the hell would you make WiX ignore what the author obviously intended? Wouldn’t it have been better to not even include (or remove) these elements? At least then you would not be deceiving authors…
COM Advertising is a really important part of the application resiliency that Windows Installer delivers. There are very few “entry points” that will cause Windows Installer to check the integrity of your application. Shortcuts and file associations are the most common, but may apps don’t have those. What about services? What about Web Apps? What about Web Services? What about background apps that start with windows? What about apps that are programmatically started by another app? COM Advertising support is the ONLY entry point that Windows Installer can use to try and keep those apps in a properly installed and configured state. Selling out and simply writing off this feature is a really bad idea at it’s face value alone, but doing that when you can’t even make a half-assed reasonable case for why you are doing it is – well – ridiculous… If there is a problem, let’s identify and document it. Let’s educate WiX authors on how to avoid that problem. Let’s work with the Windows Installer team to get it fixed. I know those guys, and I know if it’s broke, they’ll want to fix it.
Decisions like the one used in tallow’s implementation are self-defeating. Basically the approach is to dump all of the COM registration data into the Registry table. Unless by some stroke of luck, your install just happens to install the file to the exact same location as an existing version, the net result is that when your component is installed, it will overwrite previous data in the registry, making the COM subsystem use whatever version of the COM server you’ve installed, even if it is an OLDER version. Given that Microsoft doesn’t let you dump shared components into System32 anymore, there is not a clear or consistent story around what to do with shared components. Most people just dump them into their app folder or \bin folder. Using tallow output, there is no legacy reference counting, no checking the registry to see if a newer version is currently installed elsewhere, no intelligence whatsoever… If you are thinking that through this behavior, WiX is taking us right back to the DLL-hell we all have grown to hate, you are exactly right!
What exactly is the benefit of using tallow? Why not just add the file and have it self-register? I mean the only tangible benefit of tallow I can dream up is that if a rollback occurs, the registry data won’t be written (you can’t rollback a call to DllRegisterServer). Anyone can dump a bunch of crap blindly into the registry table. Isn’t the value of an installation tool to do the hard work for us?

In conclusion, Microsoft competitors are hard at work on intelligent application deployment and management solutions. In many respects, their work is inspired by the powerful features of Windows Installer. We, as developers and deployment advocates, owe it to the Windows Platform to do our part to make Windows Installer work the way it was intended. To educate developers on how to properly use it. To work with the Windows Installer team to improve and refine it. Not to sell out on the vision cause it’s too much work or because you don’t understand it.

That is what I call fighting the good fight for setup!

I'm a pain in the WiX ;-)

Michael — Tue, 21 Dec 2004 22:58:00 GMT

I’m getting beat up a little bit on the WiX Toolkit mailing lists. L It seems that since I’ve been questioning some issues (here and here), and now Rob and Orion think I’m on a war-path. They’ve got me all wrong. I’ve given tons of time to helping other people solve their problems and it would be completely out of character for me to try to undermine everything I’ve done by being obnoxious for no reason. I tend to write passionately and in a very “animated” sort of way. I guess sometimes that comes off like a rant or something, but it’s not intended that way.

Anyway, this got me thinking about what it means to run or be a part of an open source project.

Pride has got to be a serious factor for Rob. I mean, he wrote this thing all by himself and obviously poured his heart and soul into it. Freely and openly sharing something that cost you so much time and energy is hard enough with out someone like me coming along and being critical of your implementation decisions. I know how hard it is to make those critical decisions along the way. ActiveInstall was nearly a half-million lines of code and I can’t begin to count the number of nights I spent staring at the ceiling while trying to make key decisions. At the end of the day, you just have to make the best decisions you can, and be prepared to deal with the fallout if you are wrong. And sometimes you are wrong. I made mistakes, and I suspect Rob has too.

I hope that Rob will come to think of it more like this:

What he did all by himself is excellent! It’s a stellar piece of work for sure. But now, by opening it up for all to see and scrutinize, it can get even better. There’s three ways that can happen:

Bug identification and fixes through normal usage
Enhancement or contributions from the community (think smoke)
Revision/Refactoring driven by public scrutiny

It’s number three that is the most intriguing to me today. The first two are no brainers, but the third is less obvious, yet much more profound in my opinion. It may be painful at first to hear criticism or to have someone challenge what you say, or the decisions you made, but isn’t that the true (or hidden) power of open-source? In my opinion, the real value is not that people can find bugs in your source code, or that like minded people will contribute new code to it, it is that the best and brightest minds around can join in and question everything! The host should encourage discussion and yes – even debates over features and implementation decisions. This only serves to either improve the product or validate the decisions that have already been made.

While I really don’t want to be viewed as a trouble-maker, I’m gonna keep on doing what I’ve been doing. Why? Because I care. Because I like WiX and want to see it grow and mature. Because I want to be a part of it’s success.

‘Nuff said!

Implementing a Windows Installer Validation Engine in VB6 - Part II

Michael — Sun, 19 Dec 2004 14:21:00 GMT

A while back, I posted a code sample on my blog that demonstrated how to implement MsiSetExternalUI in VB6. That post certainly got a lot of hits, but there was a catch that quickly came back to haunt me. The sample I provided worked like a champ in the VB6 IDE, but caused your app to crash when it was compiled. I promised to provide an update, and while it is pretty late, here it is!

http://www.DeployNow.com/Articles/Details.aspx?ID=3

Smoke - Windows Installer Validation Tool (Download)

Michael — Sun, 19 Dec 2004 12:06:00 GMT

The Windows Installer validation tool I’ve been babbling about for a few days now is available for download on DeployNow! Stop by and check it out:

http://www.deploynow.com/Articles/Details.aspx?ID=2

I’ve even enhanced it a bit more to allow for either delimited text output, or xml.

Included in the zip file is a sample batch file that shows how conditional logic can be applied based on smoke’s return value to take alternative courses of action if problems creep into your msi files.

Enjoy – and make sure you link to it, blog about it, and give me some feedback on it!

DeployNow Update Coming Soon

Michael — Tue, 14 Dec 2004 16:23:00 GMT

I've been working on a long-overdue update to DeployNow. If you don't already know, DeployNow is my deployment resource site. I came up with the idea a long time ago, but have just been waaaay too busy to really do much with it. Now that I am settling into a groove, I am ready to start packing it with cool stuff!

Stay tuned!

MSN Toolbar Suite Needs Validation!

Michael — Tue, 14 Dec 2004 14:07:00 GMT

Rob Mensching noticed that the MSN Toolbar Suite's installer was built with WiX. He goes on to admit he was upset to see some “non-ideal” authoring in their .msi file.

Hmmm... If only they had an easy way to incorporate validation of their msi file into their build process...

;-)

UPDATE: Sorry for mangling your name Rob... Fixed!

My Windows Installer Validation Tool...

Michael — Tue, 14 Dec 2004 03:03:00 GMT

I was working on one my next MSDN articles (hint, hint), which deals with writing a custom validation engine for Windows Installer packages (*.msi files), when I had the brilliant idea of going a step further and implementing it as a command line app which could be used with the WiX toolset. It’s working like a champ now, but I’m not quite ready to release it. I’d like to solicit some feedback from anyone who’s interested in this sort of tool!

So, here’s what I have so far:

Command Line executable
Outputs XML to stdout (it assumes you’ll redirect to a file, then do something with it)
Allows you to suppress “info” messages
Allows you to suppress “warning” messages
Allows you to use custom *.cub files
Works for Merge Modules
Free of course! ;-)

So – would this sort of thing be useful for you? What else would you like to see it do?

If you have any ideas, I’d love to hear them!

BTW, I named it smoke.exe. Where there’s smoke, there’s fire. “Smoke test”… Get it? Got a better name?

UPDATE: So, I posted this to the WiX mailing lists as well, thinking those guys would have some good ideas or words of encouragement. What do I get? Cracks about Orca and MsiVal2 as though I did not know they existed... Sheesh...

I'll repeat here what I said there (basically):

Orca does validation, but not from the command line

MsiVal2 does validation from the commandline, but not in a useful way

The idea here is a command line tool that you can integrate into automated build processes. For example, you could:

Transform the XML into a nice html report
Flag the build as being bad if an errors creeps into your msi
Use XSL to filter out noise
Check the return value and take action or bail out
Extend the source code to do whatever the heck you want

Of course, neither Orca or MsiVal2 can do any of that...

Seriously, I would have expected people involved in open source development to embrace new ideas and people interested in contributing... Besides, if the mere existance of another tool mitigates the need for something newer, better or cooler, then what the heck are they doing? I guess they forgot about MsiDb.exe, MsiFiler.exe, MsiMerge.exe...

But whatever... To be honest, I'm not that surprised. I drafted a post a while back on their plans to write an authoring tool, but it was pretty critical, so I opted not to post it. Maybe I'll reconsider...

Anyway, I think it's cool, and I'm already using it on a client project... If you want to check it out, just drop me a line!

Windows Installer 3.0 Redist Now Available

Michael — Tue, 09 Nov 2004 12:07:00 GMT

Microsoft has finally released the redistributable for Windows Installer 3.0!

You can get the download here:

http://www.microsoft.com/downloads/details.aspx?FamilyId=5FBC5470-B259-4733-A914-A956122E08E8&displaylang=en

And read the KB article here:

http://support.microsoft.com/?kbid=884016

Cool Christmas animation from Red-Gate

Michael — Mon, 08 Nov 2004 14:51:00 GMT

My friends at Red-Gate are getting ready to launch a really clever Christmas animation. It’s a high-tech play on the classic scrooge Christmas tale. Check it out:

http://www.red-gate.com/downloads/cc_final.html

Implementing a Windows Installer Validation Engine in VB6

Michael — Wed, 20 Oct 2004 15:10:00 GMT

A recent topic in the msi newsgroups has focused around implementing a Windows Installer debugger or validation engine in VB6. Conceptually, this isn't all that tough. The concept focus around a successful implementation of the MsiSetExternalUI method and the companion callback. Basically, the steps would go something like this:

Figure out exactly which messages you want to get from Windows Installer and calculate the corresponding bitfield
Implement the callback handler method
Call MsiSetInternalUI to ensure that no UI will be displayed by Windows Installer
Call MsiSetExternalUI passing a pointer to the callback method, and the bitfield describing which messages you want to recieve
Invoke an Installer action by running msiexec with the appropriate options, or using the API/Automation methods
Handle messages in the callback
Call MsiSetExternalUI to restore the old handler.

Not so tough, right? Well -- We have to bear in mind that the API's needed to do this were written for C++ programmers and not for VB Programmers. While that is indeed a bummer, it does not stopping us from getting the job done. Instead, it just creates an extra challenge of getting the API declares just right in VB.

To accomplish this, we first need to create a Module in which to implement the MsiCallback.

Option Explicit

Private m_Val As MSIValidator
Private m_OldHandler As Long
'
Const INSTALLLOGMODE_USER = 8
Private Declare Function MsiSetExternalUI Lib "msi.dll" Alias "MsiSetExternalUIA" (ByVal puiHandler As Long, ByVal dwMessageFilter As Long, ByVal pvContext As Long) As Long
Private Declare Function SysAllocStringByteLen Lib "oleaut32" (ByVal lpString As Long, ByVal lLen As Long) As String
Private Declare Function lstrlen Lib "kernel32" Alias "lstrlenA" (ByVal lpString As Long) As Long

Public Function SetExtUI(val As MSIValidator)
    Set m_Val = val
    m_OldHandler = MsiSetExternalUI(ByVal GetAddress(AddressOf MSICallBack), INSTALLLOGMODE_USER, 99999)
End Function

'Simple function to return a long pointer
Private Function GetAddress(ByVal Addr As Long) As Long
    GetAddress = Addr
End Function

Public Function UnSetExtUI() As Long
    UnSetExtUI = MsiSetExternalUI(m_OldHandler, 0, 0)
End Function

'This is the callback function.
'All wee do is call into the MSIValidator class and let it do what it wants
'NOTE: This should always return 1
Public Function MSICallBack(ByVal pvContext As Long, ByVal iMessageType As Long, ByVal szMessage As Long) As Integer
    MSICallBack = m_Val.HandleMessage(ByVal iMessageType, ByVal PtrToVBString(szMessage))
End Function

'Convert a string pointer to a VB string
Public Function PtrToVBString(ByVal lPointer As Long) As String
    PtrToVBString = SysAllocStringByteLen(lPointer, lstrlen(lPointer))
End Function

As you can see the Module above is nothing fancy. It holds a member variable which is a reference to our MSIValidator class. When you call SetExtUI, you have to pass a reference to a MSIValidator class which is then stored for later use when messages are recieved.

Next, we need to create the MSIValidator class. This class will be where most of the work is done.

Option Explicit

Public Event OnInfo(iceNumber As Integer, Info As String)
Public Event OnWarning(iceNumber As Integer, Warning As String)
Public Event OnError(iceNumber As Integer, Error As String)
'
Const INSTALLUILEVEL_NONE = 2
'
Private Declare Function MsiSetInternalUI Lib "msi.dll" (ByVal dwUILevel As Long, hwnd As Long) As Long
Private Declare Function MsiOpenPackage Lib "msi.dll" Alias "MsiOpenPackageA" (ByVal szDatabasePath As String, phDatabase As Long) As Integer
Private Declare Function MsiSequence Lib "msi.dll" Alias "MsiSequenceA" (ByVal hDatabase As Long, ByVal szTable As String, ByVal iSequenceMode As Long) As Integer
Private Declare Function MsiCloseHandle Lib "msi.dll" (ByVal hAny As Long) As Integer

'
Public Sub ValidateMSI(MSIFilePath As String, CUBFilePath As String)
    '
    'Create two Installer instances (might be able to get by with one...)
    Dim oWI As Installer
    Set oWI = CreateObject("WindowsInstaller.Installer")
    Dim oWI2 As Installer
    Set oWI2 = CreateObject("WindowsInstaller.Installer")
    '
    'We need to make a temp copy of the msi to avoid mucking up the original
    Dim oFS As New Scripting.FileSystemObject
    oFS.CopyFile MSIFilePath, App.Path & "\temp.msi", True
    '
    'Open both databases
    Dim oDB As Database
    Set oDB = oWI.OpenDatabase(App.Path & "\temp.msi", 1)
    Dim oDB2 As Database
    Set oDB2 = oWI2.OpenDatabase(CUBFilePath, 1)
    '
    'Merge the cub file into our databse and save the changes
    oDB.Merge oDB2
    oDB.Commit
    '
    'Now we are going to switch to using the API, so let's clean up first
    Set oDB = Nothing
    Set oDB2 = Nothing
    Set oWI = Nothing
    Set oWI2 = Nothing
    '
    'Ok, let's set the external UI
    MSICallBack.SetExtUI Me
    '

    Dim lRet As Long
    Dim lHandle As Long
    'Make sure no visible UI appears
    lRet = MsiSetInternalUI(INSTALLUILEVEL_NONE, 0)
    'Open the package and get a handle
    lRet = MsiOpenPackage(App.Path & "\temp.msi", lHandle)
    'Run the _ICESequence Table
    '****All the magic will happen as soon as we call this method
    lRet = MsiSequence(lHandle, "_ICESequence", 0)

    'Ok, we are done now. Let's clean up
    MsiCloseHandle lHandle
    MSICallBack.UnSetExtUI
End Sub

Public Function HandleMessage(ByVal lMsgType As Long, ByVal sMsg As String) As Long
    Debug.Print sMsg
    '
    Dim sData() As String 'Array to hold the tab delimited data
    Dim iType As Integer 'The type of message
    Dim iICE As Integer 'The ICE which is sending the message
    Dim sDesc As String 'The message text
    '
    Dim i As Long
    '
    'We really don't want any errors being raised here
    On Error Resume Next
    'Split the data on the tabs
    sData = Split(sMsg, vbTab)

    'Grab the data from the array
    iType = CInt(sData(1))
    iICE = Right(sData(0), 2)
    sDesc = sData(2)
    '
    'Raise our events
    Select Case iType
        Case 1
            RaiseEvent OnError(iICE, sDesc)
        Case 2
            RaiseEvent OnWarning(iICE, sDesc)
        Case 3
            RaiseEvent OnInfo(iICE, sDesc)
    End Select
    'Always return 1
    HandleMessage = 1
End Function

Hopefully, the code above is pretty self-explantory. Basically, we make a temp copy of the msi file, merge the .cub file into it, then run the "_ICESequence" table.

Let me close this post with a word of caution. Anytime you are mucking around with API calls from VB, or implementing callback functions, you are treading in dangerous territory. Mistakes are common. Crashes are common. Please don't blame me if you screw up your system or lose some data as a result of toying with this code.

Congrats to New MVP: Dennis Bareis

Michael — Wed, 20 Oct 2004 13:51:00 GMT

Congratulations to Dennis Bareis!

Dennis has been named a MVP by Microsoft in recognition of his contributions to the community.

Announcing DeployNow.com!!!

Michael — Fri, 01 Oct 2004 20:08:00 GMT

I’m really happy to formally announce the launch of my new deployment related community site!

http://www.deploynow.com

Basically, the site is a place for me to post articles on deployment technologies, write about tools and technologies, and to host a forum in which I can help others in the community to achieve success with their deployment challenges!

There are some great sites out there already, run by some folks that I consider to be my friends (Stefan, Bob, Darwin…), and I am not launching this site in an effort to compete with them, but instead, to focus on a more specific goal of providing very specific advice on how to solve common challenges developers face when deploying sophisticated applications today. I hope to provide information that user’s of all commercial tools like InstallAnywhere.NET, InstallShield, and Wise, as well as user’s of the Platform SDK will find of value.

Help me make this a valuable resource for the community by spreading the word! Link to it! Blog about it! Post your questions!

Lastly, I have tons of ideas for articles, but hope that you’ll help me prioritize that list by letting me know what YOU want to read about! Post a comment and let me know!

Rob Mensching on Open Source???

Michael — Mon, 27 Sep 2004 10:47:00 GMT

Rob Mensching put up another post on Open Source stuff today. While I’m sure it is all very interesting, I find myself becoming really disappointed in Rob and his blog. Don’t get me wrong, Rob’s commentary on Open Source is certainly interesting (in moderation), but I don’t subscribe to Rob to hear about Open Source stuff. I want to hear about WIX. I want to hear about deployment technologies. Didn’t he rant about fighting the good fight for “setup” a while back??? Is he still fighting that good fight, or has he found a new fight???

Telligent is Hiring

Michael — Wed, 22 Sep 2004 14:53:00 GMT

So, I just noticed that Rob Howard posted a couple of cool sounding positions at Telligent that they are looking to fill.

http://blogs.msdn.com/rhoward/archive/2004/09/21/232682.aspx

Too bad that the timeframe is 6-8 weeks…