To frame this, I have some experience with app packaging using Wise Installer, but mostly at the "just get it done" level. Now we'll improve that.

We want to test applications on any given system, installing our applications. We'll be using typical mainstream apps like Office, Photoshop, Flash, etc.

Here's the kicker: we want to install the apps on a system regardless of pre-existing apps. In other words, installing Photoshop on a system that already has Photoshop installed. Then, after testing, restoring the system to it's previous state.

We will install to a central location, leaving the pre-existing application installation in place. At test time, we will enable our
installation, "disconnecting" the original installation. After testing, we remove the settings pointing to our installation and reconnect the original installation. We realize this will an independent backup mechanism.

Questions:

We could handle installation to a different location by using a transform with an MSI installation. However, research into an MSI shows that it uses identification codes, from the package, to the application, to the components, that normally prevent installation of the same application and components on a system.

Any thoughts on how we could modify the application installations to accomplish installation of the same application on a system?

Or will we have to repackage using a capture? If we repackage, won't we still have to change the identification codes which would prevent reinstallation of the same application?

Or could we just disable or reconfigure the previous installation detection mechanism in the installation package?

Many thanks for your time.
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
You would have to change the package code.

But what about all the associated registry keys, registration information etc etc. I wouldn't recommend doing what you're doing
Answered 01/11/2006 by: timmsie
Fourth Degree Brown Belt

Please log in to comment
0
No, No, No. You can't do this (have two versions of Photoshop simultaneously) and have system integrity. And even if you could, your tests would be useless -- inasmuch as your results would be valid ONLY for such environments as you created - which are environments which should never be encountered in a production context.

You could in theory install two different versions of the same application by changing the product and upgrade codes, and INSTALLDIR property. But whether you'll have stable apps afterwards is up to luck. And uninstalling one afterward will often result in breaking both.

I'm not sure what you are trying to accomplish with this plan. Maybe you'd like to re-post with more context and what objectives you want to test for. Some of us might have some ideas for a test-plan which could be more effective.

Regards,
William


ORIGINAL: Shasta_man

Here's the kicker: we want to install the apps on a system regardless of pre-existing apps. In other words, installing Photoshop on a system that already has Photoshop installed. Then, after testing, restoring the system to it's previous state.

We will install to a central location, leaving the pre-existing application installation in place. At test time, we will enable our
installation, "disconnecting" the original installation. After testing, we remove the settings pointing to our installation and reconnect the original installation. We realize this will an independent backup mechanism.

Questions:

We could handle installation to a different location by using a transform with an MSI installation. However, research into an MSI shows that it uses identification codes, from the package, to the application, to the components, that normally prevent installation of the same application and components on a system.

Any thoughts on how we could modify the application installations to accomplish installation of the same application on a system?

Or will we have to repackage using a capture? If we repackage, won't we still have to change the identification codes which would prevent reinstallation of the same application?

Or could we just disable or reconfigure the previous installation detection mechanism in the installation package?

Many thanks for your time.




Answered 01/11/2006 by: williamp
Orange Belt

Please log in to comment
0
Thanks very much for your response.

Sorry for not all the info but some readers get info overload so I opted for straight to the point then provide more as needed.

Here's what we're trying to do:

We are trying to test application performance. We will supply a complete installation system which installs the applications as well as the testing harness and scripts which control the applications to perform the operations we desire.

Our problem is that our customers typically use systems you would buy from retail. The systems come preloaded with applications. Requiring a "clean" system is a burden for the tester, and changing the system might change the experience from that typically experienced by a normal user who buys this system. Ideally, our benchmark could install on a system which has pre-existing installations matching those applications we will be installing. Perhaps simplifying the process is that we will install our application to a central location, outside of the Program Files directory. We can modify our installation so that the installation does point to this new location. We don't want both copies of the application to be functional simultaneously. In fact, it is a requirement that only our application is "functional".

Basically, the technique would be to back up the existing application and all of its settings, then install our application onto the system, overwriting the files and registry settings in the places we can't change the application from expecting them, and perform our test. (We can change the application installation location, but we cannot change the application using the registry and Documents and Settings user specific areas) After the testing is completed, we uninstall our application and restore the original installation.

As we will install to a different location from the standard Program Files directory, any original installation won't be harmed from that. The backup process will then handle every thing that must be installed into the standard locations such as application user files under Documents and Settings, Windows common files and all the registry settings. Like I said, the goal is to essentially "disconnect" the old application, leaving its installation directory in place, while installing our copy of the application and connecting all references to our installation location. After testing has completed, we remove our changes to the application user files, registry settings, etc. and then reconnect the original application by restoring their original application user files, registry settings, etc. so, we won't really have two simultaneous installations, but only one which is actually "connected". The old installation is just a bunch of file sitting there. Yes, monster job. However, this would greatly simplify use of this tool.

The question is how to do that. We would envision the backup process handling a lot of the backup however, if we could manage some of those tasks through our application installation, perhaps it would be easier. We don't know exactly what is possible, thus we are checking with you good people.

For example, if it was as simple as breaking up our installation into two pieces, first, a package which has the check for pre-existing installations removed and which installs the files which would normally go into the Program Files directory, into a different location, then another package which contains all of the elements (registry entries, files) which would overwrite a pre-existing installations elements. Then we could handle the backup, and restoration of the pre-existing installation, while the installation of our application is relatively simple.
Answered 01/13/2006 by: Shasta_man
Yellow Belt

Please log in to comment
0
How about doing this (should work for MS Win XP):

Begin
1. Create a System Restore Point, ensuring that drive C and any other volume which may be affected, is included.
2. Upgrade the product you wish to clobber (either by removing the existing one and installing yours, or installing yours as a Major Upgrade if your MSI supports that).
3. Run all your tests and save results to a network share
4. Restore the system using the restore point you created in step 1.
End

Of course, you will want to test this method for yourself, don't just trust me.

You can do the same thing as System Restore if you do a complete backup of the system including "system settings". You can't simply back-up/restore the target application, because you won't know where all the shared components reside (if any)

If you are testing for functional issues rather than performance issues, you can do it all in a VM for even faster turn-around. Take a look at http://www.vmware.com for info on vmware if desired.

Have fun!
Answered 01/13/2006 by: williamp
Orange Belt

Please log in to comment
0
Ok, thanks for the input.

I understand about System Restore. I have to study that.

However going further into the backup restore mechanism, why don't you think you would know where the shared components are? I would think, and this is where my knowledge is limited so far, that you would have the possibility of, in the case of an MSI installation, be able to study the MSI to learn what it does, or use a setup capture to capture all of this.

Doing it this way won't tell you why they do it, but at least what they do.
Answered 01/13/2006 by: Shasta_man
Yellow Belt

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