Wise package studio confusion!
We are currently trying to create .MSI distributables for a large NT to XP desktop migration project. We have been trying an evaluation version of Wise Package Studio (version 5).
Previously we used the old SMS packager as provided by Microsoft but feel we need something more up to date. I am experiencing a problem with the Wise package studio that I hope someone might be able to assist me with.
I am packaging an application by means of a before and after snapshot, I then use the installer editor to change some options (not packing user registry keys etc), and then compile to create an MSI
The MSI then installs the application on another PC and appears to load properly but when running the application, it always starts the Wise installer process and tries to locate the original MSI install package, presumably to load a feature.
This is probably something simple, but is causing us problems and we can't seem to find the solution within the help files.
Any assistance would be most welcome.
Previously we used the old SMS packager as provided by Microsoft but feel we need something more up to date. I am experiencing a problem with the Wise package studio that I hope someone might be able to assist me with.
I am packaging an application by means of a before and after snapshot, I then use the installer editor to change some options (not packing user registry keys etc), and then compile to create an MSI
The MSI then installs the application on another PC and appears to load properly but when running the application, it always starts the Wise installer process and tries to locate the original MSI install package, presumably to load a feature.
This is probably something simple, but is causing us problems and we can't seem to find the solution within the help files.
Any assistance would be most welcome.
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
WiseUser
19 years ago
You seem confused about MSI not Wise.
MSI technology requires the original source in order to repair broken components that include files.
If you have user specific components (containing HKLM keys, or profile-based files), these components will have to be installed for every new user. This is normal.
If however, the installation repairs itself over and over again, every time the user logs on, then you might have a component without a key path.
Try validating your package using either the Wise Package Validation tool or Orca.
MSI technology requires the original source in order to repair broken components that include files.
If you have user specific components (containing HKLM keys, or profile-based files), these components will have to be installed for every new user. This is normal.
If however, the installation repairs itself over and over again, every time the user logs on, then you might have a component without a key path.
Try validating your package using either the Wise Package Validation tool or Orca.
Posted by:
upthorpe
19 years ago
Yes it was a missing key path - identified it using MSISpy & ORCA, thanks for the tip. We are using this Wise tool to package up applications for a network rollout and it's possible that sometimes a .MSI might be copied onto a CD for a local install directly onto a PC (i.e. not using SMS).
Is it reasonable practice to code an MSI so it would always look for the source to auto-heal from a static location (network drive where the source is stored), rather than the CD media used to install from as there's more chance of locating the source that way.
Is it reasonable practice to code an MSI so it would always look for the source to auto-heal from a static location (network drive where the source is stored), rather than the CD media used to install from as there's more chance of locating the source that way.
Posted by:
VikingLoki
19 years ago
Definitely! In fact, I'd recommend using a DFS share as opposed to a share on a server. That way you can seamlessly move your package library to another server if it becomes necessary. It also has the benefit of being able to hold your package library in multiple locations for failover and/or scalability. If you have a HUGE emergency deployment, you have the option to add a few servers to take the load and pull them off later.
Still, if you don't use DFS, having source on removable media should be avoided at all costs. It effectively "breaks" the self repair ability since the required source file is probably not present. If you have to pull out a CD, heck you might as well install it manually!
Still, if you don't use DFS, having source on removable media should be avoided at all costs. It effectively "breaks" the self repair ability since the required source file is probably not present. If you have to pull out a CD, heck you might as well install it manually!
Posted by:
WiseUser
19 years ago
ORIGINAL: upthorpe
Yes it was a missing key path - identified it using MSISpy & ORCA, thanks for the tip. We are using this Wise tool to package up applications for a network rollout and it's possible that sometimes a .MSI might be copied onto a CD for a local install directly onto a PC (i.e. not using SMS).
Is it reasonable practice to code an MSI so it would always look for the source to auto-heal from a static location (network drive where the source is stored), rather than the CD media used to install from as there's more chance of locating the source that way.
Just so there's no confusion, I meant "HKCU" in my previous post (not "HKLM")!
You may find this VBScript code interesting?
Const sNEWSOURCE = "\\SomeServer\SomeShare\"
Const sPRODCODE = "{782750FA-653A-4790-B2FD-557A123CA32E}"
Set oInst = CreateObject("WindowsInstaller.Installer")
oInst.AddSource sPRODCODE, "", sNEWSOURCE
Set oInst = Nothing
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.