Hi all,

Here's another problem, at least I think its a problem....

In our previous release we had included the VC++ 2008 runtime via Merge Modules. We also have them included in the latest release.

However, post install, a repair is fired. After further investigation of the Event Log and .msi, I found that the problematic component pointed to one of the Merge Modules.

Also, from the log I got this...

MSI (c) (C8:50) [17:40:33:205]: skipping installation of assembly component: {634088A3-D67E-336D-9425-767BA6907C74} since the assembly already exists
MSI (c) (C8:50) [17:40:33:205]: skipping installation of assembly component: {3C582984-7607-3E35-A337-D3D327097351} since the assembly already exists
MSI (c) (C8:50) [17:40:33:205]: skipping installation of assembly component: {229E8F96-1AE0-32E6-8428-D2CBCA122740} since the assembly already exists
MSI (c) (C8:50) [17:40:33:205]: skipping installation of assembly component: {CB438DD9-2B1B-32E0-9AA6-D6DA82CE9D97} since the assembly already exists
MSI (c) (C8:50) [17:40:33:205]: skipping installation of assembly component: {6D321E57-3E99-3B87-BF23-2CDFF3361CB4} since the assembly already exists
MSI (c) (C8:50) [17:40:33:205]: skipping installation of assembly component: {AE56AAF5-F3C0-3D4B-8859-A1E50A3E27BF} since the assembly already exists
MSI (c) (C8:50) [17:40:33:205]: skipping installation of assembly component: {63E949F6-03BC-5C40-A01F-C8B3B9A1E18E} since the assembly already exists
MSI (c) (C8:50) [17:40:33:205]: skipping installation of assembly component: {98CB24AD-52FB-DB5F-A01F-C8B3B9A1E18E} since the assembly already exists


What the heck is going on here? If it's not something I'm doing wrong, its got to be a bug, no?

Our prevous install was made with Wise so maybe the Merge Modules used with that have a higher version that what is included with install shield. ??

Any help is GREATLY APPRECIATED!

Thanks in advance!!
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
I believe, the log entries that you have specified(skipping assembly installation) is generated before upgrade takes place.
You may need to re-sequence the 'RemoveExistingProduct' action.

If adding the component as a pre-req works well, you won't need to bother on this.
Answered 03/01/2011 by: WiseAppPackager
Purple Belt

Please log in to comment
0
Upgrade wouldn't be able to install the component as AssemblyVersion may be same.
Sequence the RemoveExistingProducts action after InstallFinalize.
Answered 03/01/2011 by: WiseAppPackager
Purple Belt

Please log in to comment
0
We've had a lot of problems in the past with sequencing RemoveExistingProducts at the end of the install. For example, we've just recreated our installations with InstallShield. When we push it out the door, it will be a major upgrade to a package installed using Wise. I know once it's in .msi form everything should act the same, but I mention this because in the new package, all component codes will be different. I fear, from past experience that...

Upon completion of the install, the Wise package component {1234...} with file OurApp.exe v1 is seen as no longer needed because its not contained in the new package with that code. As a result the InstallShiled component {5678...} with file OurApp.exe v2 will not be in place because the file has been removed as part of the earlier component. Therefore, a repair will be needed when the app is launched.

It this would be the case, we cannot sequence REP later in the sequence.

The funny thing about this is that when we were building our packages with Wise, we included VC++ Runtimes via Merge Module and I don't recall the same problem occurring.
Answered 03/01/2011 by: Superfreak3
Black Belt

Please log in to comment
0
can you check by sequencing "REP at 750 value. i.e.,(before costfinalize if im right)

Also, what is the attribute value you are using in UpgradeTable entry?
Answered 03/01/2011 by: mekaywe
Brown Belt

Please log in to comment
0
Quoting actual sequence position numbers for REP (or any Action, come to that) is pointless: it could be anywhere.
Answered 03/01/2011 by: VBScab
Red Belt

Please log in to comment
0
The attribute in the Upgrade table is 256.

I'm trying to move REP up to try but I want to be certain its in the righ place with respect to components being processed/marked for installation. Is that the CostFinalize action?
Answered 03/01/2011 by: Superfreak3
Black Belt

Please log in to comment
0
@Ian, actual sequence number for REP is 1450 ( between InstallValidate and InstallInitialize) but I wanted the OP to test it by sequencing REP at 750 ( before CostInitialize)

@Matt, Also try with attribute value 512 in upgrade table.
Answered 03/02/2011 by: mekaywe
Brown Belt

Please log in to comment
Answer this question or Comment on this question for clarity