Software Deployment

Hi,

Since it doesn't matter if there is a previous installation can't you just creat a package that installs the application? As long as the GUID are different that should work.

Depending on what the previuos package is and how it is distibuted you can also simply remove a key component from the target machines. Msiexec then will try to reinstall. removing one or more key components can by done by a command line execution from a login script.

Does this help you any bit at all?[8|]

Edwin

Hi Edwin,

Not really. When I try changing the GUID, it installs it as if it's another application. When you look inside add / remove programs, you've got a line item for each installation. As I am deploying updates and bug fixes alot, this is a problem.

I am thinking of doing this - Small updates, but I don't have a clue on how to achieve it. Anyone got any ideas?

Tjoppie,

Create two directroies, one main one update.
Create main.msi and save in the main directroy. Save it again in the update directory.
Run the main.msi
Change the package code of the main.msi the is located in the upgrade directroy.
Copy the main.msi form the update dir to the main dir. It will override your org main.msi.
Now in appwiz.cpl Support information ther is a extra button named repair.

Good luck with it.

Edwin

Edwin,

Eish... Still not gonna cover it. See my client pc users, have limited pc experience, and I mean... Real limited. As in where do I switch on the pc limited.

They should not even know when and how it updates. My application I deploy checks for updates when it opens, and when there is an update, it updates (reinstalls) but this all runs in basic mode. So is there any way where the user has nothing to do with the installation but it just reinstalls the package?

Tjoppie,

You need to be more specific on the distribution methode that is used.

Edwin

Edwin,

The way my application updates. I use SQL Server as my back end database. Update versions are kept in a table in sql server. Every time my application opens, it checks which is the newest version of the application. if it is the current installed version, then it ignores updating, and continues. When it sees that there's a new update version captured. It attempts to update. Now the setup files are on our file servers. (currently only the raw files, and I'm using a .bat script to copy the files over to the client pc, so I want to move over to msi now) So when it "sees" there's an update, sql server tells the application where the new files are which it needs to copy.

My Problem is: As I am deploying my application to our network alot, I need to be able to "reinstall" the application alot on client pcs. Now When I package my application (using Microsoft Access developer extentions). It installs fine on client pcs. When I have a new revision of my application, and repackage, then the application does not install on the client pcs. I get the error "Another version of this application already exists, please first uninstall in the Add / Remove control panel applet"

Now that is my problem. I want the application to reinstall, if it already is installed. so it uninstalls or just reinstalls, it does not tell me "go and reinstall in control panel" That will lead to my phone starting to ring like mad 5 min after I deploy my package everytime.

I want the msi application to install if the application does not exist (First time installing) and when it updates, it only reinstalls the application.

Thanks for the help so far.

Tjoppie,

I do understand that you don't want to have the phone ringing ever 5 min. After I've created a package and distributed it I do not want to see or hear a customer with an isue.

So now your problem. The command line for reinstall is msiexec.exe /fa package.msi. the command line for silence installing is msiexec.exe /i pacakage.msi /qb. For removing a package its is msiexec.exe /x package.msi

So within a logon script you can use this 3 lines to install, forced reinstall and remove if nessecary. It needs some pretty good planning ahead to figure out the method But I'm sure that you can make it happen.


Edwin

Hi Edwin,

Maybe this is gonna be a stupid question but.

My package gets distributed for writing onto a cd. So my directory structure looks like so:

| --- Autorun.inf
| --- Setup.exe
| --- Files\Accessrt.zip
| --- Files\ACCESSRT.msi
| --- Files\JMS.msi
| --- Files\Setup\Setup.ini

Now in my setup.ini file, the following lines is written:

This is the original:
==================================================
[MSI]
; The MSI section gives the name of the MSI file to install. This file must be in
; the same folder as Setup.exe, and both must be in the root of the installation
; tree.
MSI=\Files\jms.msi
===================================================

I changed it to this:

MSI=msiexec.exe /fa \Files\jms.msi

The error that I'm getting upon running setup.exe from the root is:

"Can't Locate the msi file specified in H:\Deploy\20050624\Files\Setup\Setup.ini"

It doesn't help when I change the path to the full path aswell... any suggestions?

Tjoppie,

I've been thinking about it but I don't have a clue how teh setup.exe interpreter the setup.ini.

Perhaps there is someone else.

Edwin

you cant issue a command using MSI= section instead try using the Cmdline= on the startup section

regards
rick

The way my application updates. I use SQL Server as my back end database. Update versions are kept in a table in sql server. Every time my application opens, it checks which is the newest version of the application. if it is the current installed version, then it ignores updating, and continues. When it sees that there's a new update version captured. It attempts to update. Now the setup files are on our file servers. (currently only the raw files, and I'm

Hej Tjoppie,

I had a similar problem. Not exactly the same but a similar. You see I am receiving a software version updates time to time. When I install the package, it does not remove the old package. So, this is my workaround;

I find the CLSID of the package that I have to remove. This will be in the registry here and will look something like this;
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{3248F0A8-6813-11D6-A77B-00B0D0150020}

So I create a .bat file and place it under the logon process of the client,
In the .bat file,
I remove the old package by this lijn;
start /wait msiexec /x {3248F0A8-6813-11D6-A77B-00B0D0150020} /qb-
start /wait msiexec. /i \package\package.msi /qb-



If you want to make it more advanced, you can add a autologon(under RUNONCE in Registry), reboot the machine, autologon with Administrator credentials, install the new package, clean up autologon entries from the registry and the new app. is installed.



Voila !
This works, I guarantiee you that...

Wow, lots of suggestions to do it the hard way. Research use of the Upgrade Table.

In a nutshell, it's a list of upgrade codes and a version ranges that will be scanned for and removed before the MSI's installation begins. When that MSI goes on, it first takes these MSI(s) off. Once the upgrade table is defined, no further thought is required. It just upgrades properly.

ORIGINAL: VikingLoki

Wow, lots of suggestions to do it the hard way. Research use of the Upgrade Table.

In a nutshell, it's a list of upgrade codes and a version ranges that will be scanned for and removed before the MSI's installation begins. When that MSI goes on, it first takes these MSI(s) off. Once the upgrade table is defined, no further thought is required. It just upgrades properly.



now why didnt i think of that? ahehehe[8D]
rick

Actually, I think Tjoppie threw everyone off when he kept saying "reinstall". I think he meant "upgrade". They're two very different things. (I kept wondering why he wanted to reinstall an old version to upgrade to a new version. I was baffled.)

Hehe... Sorry for the confusion,

Thanks VikingLoki, I'm gonna look at this upgrade table thingy today, I'll get back to you.