Odd project requirement: change .msi ProductCode through API
Frank
be able to install a "test-mode" of our application before installing
it in production. To make things worse, each needs to be executed
from the the same .msi. My question is this: can one (through the msi
API) change the ProductCode (and upgrade code/package code) on a
Windows Installer package (the .msi file) prior to execution so that
Windows Installer thinks it's a separate application that is being
installed. IOW, if our end-user already has an older version of the
application on the system, but wants to "test out" the latest version
without updating that older version, is it possible to modify the .msi
so that there can be "concurrent" (of sorts) installations?
I've tried opening the .msi through the API and updating ProductCode,
UpgradeCode, and ProductName in the Property table, but that doesn't
seem to work (executing the .msi goes through the normal maintenance
mode)...
Thanks in advance for any insight. These project requirements kill
me... :(
mgama
Unfortunately this will probably mean writing your own setup.exe
bootstrapper which will first put up a dialog giving the user the option of
"test" or "production" (or whatever you want to call it). If the user
selects test, then you will call "msiexec /i <your msi file> /t test.mst"
"Frank" <frank....@activant.com> wrote in message
news:1187096768....@z24g2000prh.googlegroups.com...
Frank
> You can apply a transform (.mst) to your MSI when you launch it.
> Unfortunately this will probably mean writing your own setup.exe
> bootstrapper which will first put up a dialog giving the user the option of
> "test" or "production" (or whatever you want to call it). If the user
> selects test, then you will call "msiexec /i <your msi file> /t test.mst"
>
>
> news:1187096768....@z24g2000prh.googlegroups.com...
>
> > As an off-the-wall requirement for a project, I need our end-users to
> > be able to install a "test-mode" of our application before installing
> > it in production. To make things worse, each needs to be executed
> > from the the same .msi. My question is this: can one (through the msi
> > API) change the ProductCode (and upgrade code/package code) on a
> > Windows Installer package (the .msi file) prior to execution so that
> > Windows Installer thinks it's a separate application that is being
> > installed. IOW, if our end-user already has an older version of the
> > application on the system, but wants to "test out" the latest version
> > without updating that older version, is it possible to modify the .msi
> > so that there can be "concurrent" (of sorts) installations?
> > I've tried opening the .msi through the API and updating ProductCode,
> > UpgradeCode, and ProductName in the Property table, but that doesn't
> > seem to work (executing the .msi goes through the normal maintenance
> > mode)...
>
> > Thanks in advance for any insight. These project requirements kill
> > me... :(
Thanks for the info, mgama.
In such a situation, would the "test" installation be truly isolated
from the "production" version? IOW, since the Feature or Component
GUIDs aren't changing (only the ProductCode, UpgradeCode, ProductName,
and PackageCode), is that going to present a problem (ie, when
uninstalling or updating the "test" installation), or is that
irrelevant?
Sam Hobbs
news:1187096768....@z24g2000prh.googlegroups.com...
> As an off-the-wall requirement for a project, I need our end-users to
> be able to install a "test-mode" of our application before installing
> it in production.
This is not unusual in professional software development. To the extent that
this is uncommon in Windows environments, it is a symptom of Window's
non-professional roots. If this type of thing is not supported by Windows
Installer then that is another example of a serious flaw in the design of
the Windows Installer.
Instead of calling it a test version, a more appropriate name would be
"Release". There should be both release and production directories and
release versions should be promoted in a controlled manner, such as by an
automated script or program. Ideally the source would be promoted to a
controlled directory structure or source control system, then the release
executable built from the promoted code. The test version (directory and
such) would be the version used for development only. When the release
version is accepted by the user, then it would be copied to the production
library or directory.
One way to control where an application (exe and the DLLs it uses) executes
from is the "App Paths" registry key that works like the paths environment
variable except the "App Paths" registry key is specific to each
application. I know that it is documented but I cannot find the
documentation now. If you search MSDN for "App Paths" (with quotes) you will
get many results. The following are some that I found that are relevant.
Dynamic-Link Library Search Order
http://msdn2.microsoft.com/en-US/library/ms682586.aspx
Re: How do I distribute Visual Studio 2005 apps?
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=216150&SiteID=1
There are limitations of "App Paths" so you need to research it to ensure it
works for your software. There are other possible ways to satisfy the
requirements I describe above.
Owen Gilmore
>
> - Show quoted text -
Have you looked into the EXECUTEMODE property? It looks like that may
give you the functionality you need.
Phil Wilson
to go and change the packagecode, that's the other thing that makes it the
same product as one that's already installed.
The install issue is likely to be conflicts, because now you have a
requirement that this new version be completely side by side with the
installed version. It should be installed to a different folder (so it
doesn't overwrite the existing app) and it can't really share anything with
the installed app because then the older version will use updated components
from the new version. If you have things like COM components or GAC
assemblies that could be an issue.
So there a bunch of install issues, but the app has to play nice side by
side too. Does it save state in the registry and will both old and new use
it? Are files with a common name saved in the same location? Are there any
system-singleton objects that will conflict, like services? Do they expect
both apps to run simultaneously on the same system? If so, other objects
like mutexes may conflict. .NET Remoting port numbers? Databases and
connections? Obviously all this depends on the app, and making the install
work won't matter if your app has conflicts with itself.
--
Phil Wilson
[MVP Windows Installer]
"Frank" <frank....@activant.com> wrote in message
news:1187096768....@z24g2000prh.googlegroups.com...
Christopher Painter
versions of MSI. I write about my experiences with it ( using
InstallShield ) here:
http://blog.deploymentengineering.com/2006_10_01_archive.html
Basically I've taken into account everything that Phil mentions and
created installers for an n-Tier system ( web services, WinUI client
and WebUI client ) that supports 16 installed instances which can each
be individually configured and upgraded using the same database
packages. It's really cool stuff.