Nested msi with custom action : msp file

Nested msi with custom action : msp file

Click here to associate this thread with a Package KB article.

Logged in as: Guest

Users viewing this topic: none

Printable Version

All Forums >> [AppDeploy Forums] >> Package Development >> Nested msi with custom action : msp file

Page: [1]

Message

<< Older Topic Newer Topic >>

Nested msi with custom action : msp file - 11/12/2007 10:17:00 AM

mikle_01

Posts: 4
Score: 0
Joined: 6/16/2006
Status: offline

Hi,

i try to make an msi (install Access Runtime 2003.msi with the SP2 - mainsp2ff.msp : the Office 2003 SP2 file) with Installshield 2008.

"msiexec /i .... ACCESSRT.msi /PATCH=.... mainsp2ff.msp -qn" or "ACCESSRT.msi /PATCH=....mainsp2ff.msp -qn" are working fine in the cmd.

But if i try to make a custom action it doesnt't work.

My how to:

New "Basic MSI-Project"
Copy Files to %ProgramFiles%\ACCESSRT2003SP2
Custom action -> nested msi -> Type 7 (inside main setup) -> Execute after Install initialize

But it doesn't work.

Is there any HOW To or template to make a nested MSI with msi and MSP

Post #: 1

RE: Nested msi with custom action : msp file - 11/12/2007 11:08:37 AM

dunnpy

Posts: 335
Score: 24
Joined: 2/15/2006
From: UK
Status: offline

mikle_1,

Maybe I'm missing something here, but can't you create an admin install point of the Access Runtime and then patch the install point up to SP2

msiexec /a "access runtime 2003.msi"

msiexec /p "mainsp2ff.msp" /a <path to admin install point>

When an installation is performed from the patched admin installation point SP2 of Access Runtime will be installed.

Hope this helps,

Dunnpy

(in reply to mikle_01)

Post #: 2

RE: Nested msi with custom action : msp file - 11/12/2007 1:07:34 PM

mikle_01

Posts: 4
Score: 0
Joined: 6/16/2006
Status: offline

Access Runtime couldn't updated with this method!! I try it first as other office slipstreaming methods known.

All other Office 2003 Pro. files were updating except the Runtime

see here:

http://www.cetix.de/OfficeNews/Thread142604-Access_Runtime_2003_when_slipstreaming_SP2.aspx

Access Runtime 2003 slipstreaming SP2 won't work!!

So, I try to make an nested msi with the msp (custom action); any -other- clues!?

Mike

< Message edited by mikle_01 -- 11/13/2007 1:36:21 AM >

(in reply to dunnpy)

Post #: 3

RE: Nested msi with custom action : msp file - 11/12/2007 1:23:42 PM

nheim

Posts: 1177
Score: 55
Joined: 4/5/2004
From: Switzerland
Status: offline

Hi Mike,
you can't use an nested CA for this purpose.
Use an exe type CA and sequence it after InstallFinalize.
Regards, Nick

(in reply to mikle_01)

Post #: 4

RE: Nested msi with custom action : msp file - 11/12/2007 1:46:23 PM

mikle_01

Posts: 4
Score: 0
Joined: 6/16/2006
Status: offline

Hi Nick,

an exe type CA !? You mean msiexec.exe...or what!? I try also this CA with exe (instead of msi)

msiexec /i .... ACCESSRT.msi /PATCH=.... mainsp2ff.msp -qn

no luck, too....

Grützi, Michael

(in reply to nheim)

Post #: 5

RE: Nested msi with custom action : msp file - 11/13/2007 9:04:55 AM

nheim

Posts: 1177
Score: 55
Joined: 4/5/2004
From: Switzerland
Status: offline

Hi Michael,
apparently we both could write in german, but lets try it in english to make it world readable...

We got several problems here:
1. ACCESSRT.MSI lacks the 'AdminExecuteSequence' table. Because of this, a admin install isn't possible out of the box.
2. mainsp2ff.msp would be to big to deploy with this package, it makes it inefficient.
3. Maybe a setup.exe wrapper would make things easier here?

To deploy Access RT with SP2 (or SP3) injected, we have to do the following steps:
1. We need to append the 'AdminExecuteSequence' table to ACCESSRT.MSI.
If you have access to the Installer SDK, search for 'Sequence.msi' and open it in ORCA.
export the 'AdminExecuteSequence' table to your work directory.
Now open 'ACCESSRT.MSI' in ORCA and import the 'AdminExecuteSequence.idt' file from your work directory.
Save it and exit.
in C:\workdir\ type:
msiexec /a ACCESSRT.MSI TARGETDIR=C:\workdir\admin
This write an admin installation point.
now cd to C:\workdir\admin and type:
msiexec /a ACCESSRT.MSI /p ..\MAINSP2ff.msp TARGETDIR=C:\workdir\admin
This applies the SP2 to the install point.
Now we have to generate the new CAB-file for the SP2-version. You need WiMakCab.vbs from the SDK to do this.
Make sure it lies in the path or copy it to C:\workdir\admin.
cd to C:\workdir\admin and type:
cscript WiMakCab.vbs ACCESSRT.MSI ACCESSRT /L /C
After this you have the SP2-version of ACCESSRT.MSI and ACCESSRT.CAB in your C:\workdir\admin.

And finally load ACCESSRT.MSI into ORCA, go to View - Summary Information... and set
the flag on "Compressed by default" and remove the flag from "Administrative Image".

Now, you could add your SP2-version of the runtime to your distribution.

Regards, Nick

< Message edited by nheim -- 11/14/2007 4:40:48 AM >

(in reply to mikle_01)

Post #: 6

RE: Nested msi with custom action : msp file - 11/14/2007 2:56:19 AM

mikle_01

Posts: 4
Score: 0
Joined: 6/16/2006
Status: offline

Hi Nick,

thanks for your detailed and professional support and hint; IT WORKS

, besides the penny issue of needed directory (see the error message im eventlog) despite of making a cab. But no problem; copy the whole Directoy were the msi and cab is - and it works.

I guess, something goes wrong while building the cab (the GDIPLUS.DLL is missing)
-----------------
"Produkt: Microsoft Office Access 2003 Runtime -- Fehler 1309. Fehler beim Lesen von Datei: C:\Dokumente und Einstellungen\Administrator\Desktop\Access Runtime 2003 SP2\FILES\Programme\Microsoft Office\OFFICE11\GDIPLUS.DLL. Systemfehler 3. Überprüfen Sie, ob die Datei existiert und ob Sie darauf zugreifen können."
-----------------

Sorry; for German Windows XP. Analogously in English:

"Error 1309. Error reading from file......GDIPLUS.DLL" Error 3.Verify that the file exists and that you can access it."

Regards, Michael

(in reply to nheim)

Post #: 7

RE: Nested msi with custom action : msp file - 11/14/2007 4:43:04 AM

nheim

Posts: 1177
Score: 55
Joined: 4/5/2004
From: Switzerland
Status: offline

Hi Michael,
we forgot something vital: We need to tell the MSI, that its source is compressed again.
Load ACCESSRT.MSI into ORCA, go to View - Summary Information... and set
the flag on "Compressed by default" and remove the flag from "Administrative Image".
This should do the trick
Regards, Nick

(in reply to mikle_01)

Post #: 8

System Tray Ikon Standards - 11/14/2007 8:41:59 AM

viswanadh.wise

Posts: 1
Score: 0
Joined: 11/14/2007
Status: offline

Hi
Can I have packaging standards supposed to be followed for system tray ikons. As we are supposed todelete the system tray ikons if we have a shortcut under start menu programs. Please provide a detailed or short description regarding the process need to be followed when we have any system tray ikons in the application. Fast responce will ve very much helpful for application release.

Thanks and Regards
MV

_____________________________

MV

(in reply to nheim)

Post #: 9

RE: System Tray Ikon Standards - 11/14/2007 9:30:20 AM

VBScab

Posts: 6623
Score: 190
Joined: 9/5/2006
From: London, UK
Status: offline

I suggest whoever told you to do that takes a "Windows XP for dummies" course. Neither you or anyone else except the developer have any control over what icons appear there, unless the software has an option to not display its icon.

Is there some reason why you have posed your question in a 'Reply' thread rather than starting a new topic?

< Message edited by VBScab -- 11/14/2007 9:31:17 AM >

_____________________________

- Don't know why 'x' happened? Want to know why 'y' happened? ProcMon will tell you.
- Try using http://www.google.com before posting.
- I answer questions only via forums. PMs and personal emails will be ignored.

(in reply to viswanadh.wise)

Post #: 10