cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Not applicable

Creating a minor upgrade

I thought this was going to be easier than I thought but I'm beating my head against the wall on this one. I'm just trying to update one .dll through a minor update and it won't update that file.

Our 'SP0' project has been released. I took that project and made a copy of it, called it SP1. From there I made the following changes:

-Changed the Path variables to where my new files are located (all the same as SP0 except for one .dll)

-changed the package code GUID and updated the product version (from 209.000.00000 to 209.111.00000)

-Went into 'Upgrades', created a new minor upgrade item (called SP0) and pointed the setup to upgrade to the release folder that SP0 is in.

-changed upgrade settings to 'prompt' user

Built the install and that was it. If I run this SP1 install by itself without the prior install, everything installs fine, including the new file. If I run this install over SP0, it will say 'this will perform and upgrade, continue?' I say yes, install continues. When it's all done I go look at the directory and old file has not been replaced.

This can't be that difficult to do, can it? What else am I missing?
Labels (1)
0 Kudos
(10) Replies
Not applicable

Okay, so to make things even stranger I decided to right click on my 'minor upgrade item' (SP0) under my upgrade tree and chose 'validate item'.

I say 'yes - perform validation on latest release' and it starts to validate. Returns an error:

"The data in component 'test.dll' differs from the previous setup. However, this component will not reinstall in an upgrade scenario. Therefore, the changes will not be applied to the target system during the upgrade."

Well of course it differs from the previous setup, it's the file I'm trying to upgrade!

I have no idea what I'm doing I guess.
0 Kudos
wolverine
Level 4

Open both projects in install shield observe the component code for component containing new .dll

Check if it is same?
0 Kudos
Not applicable

I'm now getting this error:

Val0010: The data in component '_559E9D73BABC4017EA2F6FF3E79967BB' differs from the previous setup. However, this component will not reinstall in an upgrade scenario. Therefore, the changes will not be applied to the target system during the upgrade. Table: 'MsiAssembly' Record: '_559E9D73BABC4017EA2F6FF3E79967BB;Our_company_name;_24386AA3C6074489AE5A1E716425366D;reportgenerator.exe;0' Setup.exe created

I'm not even sure what component '_55E9.....' is. I'm looking at all of the component codes I have for my files and none of them look like that. This is frustrating.
0 Kudos
Reureu
Level 10

Hi,

Am I right in thinking that you are working on a Basic MSI project?
It looks like a randomly generated component ID.
Did you use dynamic file linking in any component?

If yes, that might well be the culprit.

This dynamic file linking is evil.
It works reasonably ok if you dynamically link a directory that only contains ressources (text files, pictures, etc...) and if you can guarantee that you never remove any file from this directory between 2 builds of your MSI package. This is not something you can guarantee in practice.
But you should never link an assembly (dll, exe, ocx,...) dynamically in a component.

You somehow loose the control of the components that use dynamic file linking.

This has several drawbacks, for instance if a developer deletes a file in a folder you have dynamically linked:
[LIST=1]
  • If the application requires the file that has been deleted, Installshield will not fail when building your setup. Your project does not know which files must be linked. It just links whatever file it finds in this folder.
  • You don't know which files are key files. If the file the developer deleted was a key file, the entire feature will somehow be flagged as advertised when performing a minor upgrade. Then on the first time you open your application after the upgrade, it will reinstall the feature.
  • You can't use the RemoveFiles table, as the component ID's and the file keys have been randomly generated.
  • Chances are that you end up with orphan files after performing your minor upgrade.
  • As you probably know, deleting files or components is not supported in a minor upgrade scenario.


    I hope that helps.
    Regards
  • 0 Kudos
    Not applicable

    Hey thanks for the response!

    Unfortunately (or I guess fortunately) I didn't use Dynamic File linking for this - manually added the files through the app files option in the project assistant.

    ended up coughing up $250 to talk to an IS tech support rep. Sent him my project, hoping to hear back from him. He had said something about IS 2009 fixing this, there was a problem with component IDs being randomly generated with IS 2008. Beats me. Guess I'll wait to hear back from him.
    0 Kudos
    Reureu
    Level 10

    Hi,

    ok, maybe the project assistant has randomly generated a component ID. I must admit I never used it.
    But that really looks like the consequence of dynamic file linking.

    Let's hope Acresso finds a solution to that problem.

    Did you try to produce an MSI logfile when upgrading?

    Regards
    0 Kudos
    Not applicable

    I did create a verbose logfile (sent it to the tech rep as well) - I took a look for it, didn't see anything glaringly obvious though. The _559E..... component looks like it was installed, scrolled to the end of the log, looks like everything was fine.
    0 Kudos
    Reureu
    Level 10

    Hi Colorado,

    Can you post that logfile, or send it to me as a zipped attachement?

    Regards
    0 Kudos
    Reureu
    Level 10

    Hi,

    did you finally get an answer from the Acresso technical support?

    Regards
    0 Kudos
    Not applicable

    Tech support is still looking at it. Sent them my uncompressed installs the other day.
    0 Kudos