I'm having a problem with the "Windows Installer" action -- it can't find the .msi package and always reports:
Installing MSI Package...Not found
However, the .msi IS there. In fact, before I execute the "Windows Installer" action, I use the "If File/Folder Exists" action to verify the .msi is present; it consistently reports:
Found file "C:\temp\MyApplication.msi"
I'm using FinalBuilder 6.2.0.1074 on Windows Server 2003 R2. However, when I use the exact same FB project file (.fbz6) on my WinXP SP2 development/staging machine everything works fine! Also, if I use msiexec to run the install package it works fine.
I'm stumped... any idea what might be happening here?
I had a look at the code, and did find one issue which it is not expanding variables in the package path. You didn't say if you were using variables or not. We don't call msiexec to run the package, we execute it using wmi. So another possible cause may be the version of windows installer, which version is installed on the machines? I will check in a fix for the variable expansion and post a link to the build here later today.
Edit : Just looked through the source again and it does expand variables correctly.. so not sure what the problem is.
I was using variables but ended up hard-coding the path to eliminate that "variable". Now, I created a new FB project and the only action is Windows Installer with a hard-coded path to the .msi. Same result -- "Not found".
For the Windows installer version you asked about, do you mean the version of msiexec (which happens to be 3.1.4000.3959 on the Win2K3 machine and 3.1.4000.1823 on the WinXP machine). If this isn't the version you meant, what do I need to check?
That was the version I was talking about, I should have been more explicit. The major/minor versions are the same so my guess is that is not the cause. The only other thing I can think of is security... it may be a permissions issue with the user that FinalBuilder is running under. I will look into this further tomorrow.
I tried running the FB project as the local admin account, but still got the same result.
There may be a WMI problem on the Win2k3 machine. I ran Microsoft’s “WMI Diagnosis Utility” on both machines. The WinXP machine came up clean, but the Win2k3 machine did not:
“WMIDiag detected issues that could prevent WMI to work properly!”
I’m going to look into this – I suspect that is the problem since that action uses WMI.