Monday, June 29, 2009

MSI: Uninstall left some files not removed

I created a MSI package and tested the installation and uninstallation. Everything looked good except for one file. The abc.exe file could not be removed by the uninstallation process. The INSTALLDIR started clean. And file was not used at the time of uninstallation.

I created the extensive log using /L*v option with msiexec command. After studying the log file and comparing the ComponentId in the msi, I found out that the file was marked "PreviouslyPinned".

MSI (s) (50:C0) [15:22:31:932]: Executing op: ComponentUnregister(ComponentId={4CA897DC-C1DD-1A1D-CA93-FF18DA884529},,BinaryType=0,PreviouslyPinned=1)1: {2E9A386D-9B96-4E7C-9AE9-B614A86EEFA5} 2: {4CA897DC-C1DD-1A1D-CA93-FF18DA884529}

Sure enough, I found an entry of the file in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs.

After deleting the entry, the uninstallation of the MSI worked properly. The MSI package was correct, the problem resided on the testing environment.

Friday, June 5, 2009

Configure Cygwin sshd for Build Automation

Our build is initiated from a UNIX build server, then invokes the Windows build portion.

1. create a local build user on the Windows build server. Use the same id as in the UNIX server. Password can be different.

2. install cygwin on the Windows build server.

3. set up sshd service.
There is a very nice article about how to set up sshd using cygwin, including which cygwin packages to install, how to install and configure ssh service, how to generate user pulib/private keys, and how to add the user to the password file.
In summary, use the following command.
You should be able to find a "CYGWIN sshd" service in Windows machine. Make sure the service is started.

4. in the ssh client (UNIX build server), login as build id, generate rsa (or dsa) public/private keys. entry cartridge return (empty) for passphrase.
# ssh-keygen -t dsa
public key is save to ~/.ssh/
private key is saved to ~/.ssh/id_dsa

5. sftp the public key( to ~/.ssh directory on the ssh SERVER (Windows build server).

6. create an authorization file in the ~/.ssh directory on SERVER, add the public key in.

server> cat / >> /.ssh/authorized_keys
7. To verify that you can connect to the target system, log in through from the client. An entry will be created in the ~/.ssh/known_hosts file in the server.
$ ssh id@target
Now you can integrate the Windows build with UNIX build process.

ssh -n -o NumberOfPasswordPrompts=0 ccadmin@winbuild "rm -rf /cygdrive/e/CBFE_Build/${RELEASE}"
ssh ccadmin@winbuild "cd /cygdrive/e/CBFE_Build/${RELEASE}; /usr/bin/unzip -u /cygdrive/e/CBFE_Build/${FILENAME}"
ssh ccadmin@winbuild "cd /cygdrive/e;/cygdrive/c/Program\ Files/InstallShield/2009/System/IsCmdBld.exe -p CBFE_Build/IS_Projects/${RELEASE}/CBFE_Common/CBFE_Common.ism -z BUILD_VERSION=${BUILD_LABEL}"

Thursday, June 4, 2009

Run InstallShield ISCmdBld.exe under cygwin, ssh

After installed and configured cygwin (sshd) in the Windows build server, I tested the ssh connection without any issue. The next step is to launch the InstallShield command line builder ISCmdBld.exe through ssh from my UNIX build box.

ssh myUserid@myWindowsBuildServer "cd /cygdrive/e;/cygdrive/c/Program\ Files/InstallShield/2009/System/IsCmdBld.exe -p CBFE_Build/IS_Projects/myProject.ism -z BUILD_VERSION=${BUILD_LABEL}"

Nothing happened. The command prompt returned immediately. After more testing, I found out that if I logged in to the Windows build server using myUserid, or other id, I had no problem running ISCmdBld.exe in a cygwin session. However, logging in through ssh from other boxes (UNIX or Windows) did not work. It was not X server. And it was not the ACL on the executables. Even power user group is not sufficient.

Finaly, by adding the user to the Administrator group on the Windows box, the problem solved.