This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Accept
Reject
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Not applicable
‎Oct 09, 2014 12:49 PM

InstallShield and .Net Dll Versions and Minor Upgrades

Hi,

I have this question, any help/suggestion on this matter is highly appreciated.

I have a bunch of .Net Dll to be deployed and perform a minor upgrade on them to deploy only the changed Dlls in subsequent builds.
Also, we have a third party software, which enhances the DLL assembly version, with every build for all components. For example : Installer Build 1.1 deploys Dlls/exes whose version number is 1.1 and so on.

Now, my requirement is that, when build 1.2 upgrades build 1.1, it should replace only those Dlls which have undergone a change programmatically. Thus I chose Minor Upgrade for this job.
After implementing the Minor upgrade, I saw that all components(dlls/exes) were replaced instead of the "changed" components. I figured out that this is because the Assembly version of all components were changed.

Now, My question is.. How do I force only the "changed" Dll to replace the older ones through a minor upgrade ?

Please let me know, if I have to make my question more clear.
Labels (1)
Labels
0 Kudos

(1) Reply
DLee65
Level 13
‎Oct 09, 2014 01:03 PM

Some options to consider:

1. If you release a patch file, you have the option to distribute the bits that have changed or a whole file. If you choose the bits that changed, then make sure your customers have the original MSI cached so that upgrades can occur properly.
2. I had a scenario like this once where we wanted to do whole files. So when creating our patch, we had to stage all of the files from the original package, maintain a list of 'changed' files, and copy in the 'changed' files to the stage area. I think it is programmatically possible to 'detect' the truly changed files by ignoring the header and footer of the files. The footer often contains digital signature information, the header should contain file version info, create date, etc.I do not know if there is a utility available to do a diff against the 'meat' of a file.

In all that you do, you should honestly consider the rules for major upgrades, minor upgrades, and hotfixes. If your app is delivering major functionality difference then use a major upgrade, if it is just fixing a series of bugs, then a minor upgrade works, etc.
0 Kudos