Merge Modules, Major Upgrade, More Problems...
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...
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!!
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 existsWhat 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
Answers (7)
Please log in to answer
Posted by:
WiseAppPackager
13 years ago
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.
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.
Posted by:
WiseAppPackager
13 years ago
Upgrade wouldn't be able to install the component as AssemblyVersion may be same.
Sequence the RemoveExistingProducts action after InstallFinalize.
Sequence the RemoveExistingProducts action after InstallFinalize.
Posted by:
Superfreak3
13 years ago
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.
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.
Posted by:
mekaywe
13 years ago
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?
Also, what is the attribute value you are using in UpgradeTable entry?
Posted by:
anonymous_9363
13 years ago
Quoting actual sequence position numbers for REP (or any Action, come to that) is pointless: it could be anywhere.
Posted by:
Superfreak3
13 years ago
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?
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?
Posted by:
mekaywe
13 years ago
@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.
@Matt, Also try with attribute value 512 in upgrade table.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.