This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Patching .NET applications
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 06, 2009
12:16 PM
Patching .NET applications
Hi,
We're using an InstallShiled Evaluation software to test if it will fit our requirements to install our software.
We have a huge .NET Windows.Forms application that consists of lots of files (dlls, exes, text, others). Our software is strongly signed and obfuscated with obfuscation software.
We built a first version (lets call it 2.1.2) - it was a DVD with msi package, etc.
Then we build a new version with some code modifications - a 2.1.3 version - it was a similar DVD.
At the end we wanted to test if the InstallShield could build a proper Patch (Update.exe) that will patch our users v2.1.2 software to v2.1.3 one.
Using a PatchDesigner we created a PatchConfiguration supplying our two msi packages (2.1.2 and 2.1.3).
We left default settings, but told to include whole files.
The patch was built successfully.
Then we took a machine that had our v2.1.2 software Installed and run the newly created patch. It patched the sowtware. But when we launch patched software it crashed. We made a diff of installed from scratch 2.1.3 software and this patched one and found that really only a few files were patched!
so the questions:
1) why Patch doesn't patch some files that should be patched?
2) Can we just tell Patch to replace files that are different between 2.1.2 and 2.1.3. MSIs ? So no versions and other checks performed?
Please, we need a good answer ASAP 😞
Cheers,
Alex
We're using an InstallShiled Evaluation software to test if it will fit our requirements to install our software.
We have a huge .NET Windows.Forms application that consists of lots of files (dlls, exes, text, others). Our software is strongly signed and obfuscated with obfuscation software.
We built a first version (lets call it 2.1.2) - it was a DVD with msi package, etc.
Then we build a new version with some code modifications - a 2.1.3 version - it was a similar DVD.
At the end we wanted to test if the InstallShield could build a proper Patch (Update.exe) that will patch our users v2.1.2 software to v2.1.3 one.
Using a PatchDesigner we created a PatchConfiguration supplying our two msi packages (2.1.2 and 2.1.3).
We left default settings, but told to include whole files.
The patch was built successfully.
Then we took a machine that had our v2.1.2 software Installed and run the newly created patch. It patched the sowtware. But when we launch patched software it crashed. We made a diff of installed from scratch 2.1.3 software and this patched one and found that really only a few files were patched!
so the questions:
1) why Patch doesn't patch some files that should be patched?
2) Can we just tell Patch to replace files that are different between 2.1.2 and 2.1.3. MSIs ? So no versions and other checks performed?
Please, we need a good answer ASAP 😞
Cheers,
Alex
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 06, 2009
12:47 PM
you need to verify that the files to be patched have a different file versions between the versions of your software.
Generally if files are not being replaced it is because the version on the machine already is the same as the one in the patch installer.
Is this a Minor or Major upgrade you are doing? If you are attempting to do a minor upgrade, make sure you are following the guidelines for minor upgrades. The guidelines can be found in the Installshield help.
Generally if files are not being replaced it is because the version on the machine already is the same as the one in the patch installer.
Is this a Minor or Major upgrade you are doing? If you are attempting to do a minor upgrade, make sure you are following the guidelines for minor upgrades. The guidelines can be found in the Installshield help.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 07, 2009
03:38 AM
The problem is we use obfuscation. So with each build the obfuscation software do its job.
We have our Framework that has another version that is not updated from build to build. So patch won't patch it because the version was unchanged, but the obfuscation software renamed it's method that will be different from our software build to build 😞
So, how to tell InstallShield to skip version check and update all assemblies?
We have our Framework that has another version that is not updated from build to build. So patch won't patch it because the version was unchanged, but the obfuscation software renamed it's method that will be different from our software build to build 😞
So, how to tell InstallShield to skip version check and update all assemblies?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 10, 2009
10:08 AM
You should change the versions. Since they are incompatible, they should at least have different version numbers. Arguably it would be better yet to change their names since they aren't even backwards compatible, but that may be too much of an imposition. Consider, if nothing else, how hard it is to diagnose mismatches when you have to figure out which version of the dll labeled 1.2.3.4 you're dealing with.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 10, 2009
03:21 PM
if nothing is backwards compatible, then you should be doing a Major upgrade and changing the product code. You can force the overwriting of a file by going into each file and choosing the "always overwrite" option but this is strongly discouraged by the best practices.
Only other option I am aware of is to not do an upgrade and force the end user to uninstall previous versions before the new version can be installed.
Only other option I am aware of is to not do an upgrade and force the end user to uninstall previous versions before the new version can be installed.