(Error 1706) SOURCEMGMT : Source is invalid due to invalid package code

[ross.s...@gmail.com]

Hi there,

I have a problem using InstallShield 10.5 when actioning a repair on a
product from one XP machine to annother across the network and in the
same domain.

I get the error : Error 1706.No valid source could be found for product
<product>. The Windows Installer cannot continue.

looking back at the trace log the following lines seem to be the cause
of the problem (I have replaced the actual name of our product to
<package> in this snippet):

MSI (s) (F8:C4): Executing op:
ChangeMedia(MediaVolumeLabel=DISK1,MediaPrompt=Please insert the disk:
1,MediaCabinet=MsiData1.cab,BytesPerTick=32768,CopierType=2,ModuleFileName=1\<package>.msi,,,,,IsFirstPhysicalMedia=1)
MSI (s) (F8:C4): Executing op:
FileCopy(SourceName=msxml3.dll,SourceCabKey=msxml3.dll.7E4F6CB4_E769_4917_AA7E_0E3CA074ABB3,DestName=msxml3.dll,Attributes=16896,FileSize=1129472,PerTick=32768,,VerifyMedia=1,,,,,CheckCRC=0,Version=8.40.9419.0,Language=0,Ins
tallMode=58982400,,,,,,)
MSI (s) (F8:C4): File: C:\Program Files\Common Files\Microsoft
Shared\SFPCA Cache\msxml3.dll; To be installed; No patch; No
existing file
MSI (s) (F8:C4): Resolving source.
MSI (s) (F8:C4): Using cached product context: machine assigned for
product: EB76782D55ED8A14ABB5C941C3B593BC
MSI (s) (F8:C4): Using cached product context: machine assigned for
product: EB76782D55ED8A14ABB5C941C3B593BC
MSI (s) (F8:C4): User policy value 'SearchOrder' is 'nmu'
MSI (s) (F8:C4): User policy value 'DisableMedia' is 0
MSI (s) (F8:C4): Machine policy value 'AllowLockdownMedia' is 0
MSI (s) (F8:C4): SOURCEMGMT: Media enabled only if package is safe.
MSI (s) (F8:C4): SOURCEMGMT: Looking for sourcelist for product
{D28767BE-DE55-41A8-BA5B-9C143C5B39CB}
MSI (s) (F8:C4): Using cached product context: machine assigned for
product: EB76782D55ED8A14ABB5C941C3B593BC
MSI (s) (F8:C4): SOURCEMGMT: Adding
{D28767BE-DE55-41A8-BA5B-9C143C5B39CB}; to potential sourcelist list
(pcode;disk;relpath).
MSI (s) (F8:C4): Using cached product context: machine assigned for
product: EB76782D55ED8A14ABB5C941C3B593BC
MSI (s) (F8:C4): SOURCEMGMT: Now checking product
{D28767BE-DE55-41A8-BA5B-9C143C5B39CB}
MSI (s) (F8:C4): SOURCEMGMT: Media is enabled for product.
MSI (s) (F8:C4): SOURCEMGMT: Attempting to use LastUsedSource from
source list.
MSI (s) (F8:C4): SOURCEMGMT: Trying source C:\WINDOWS\System32\.
MSI (s) (F8:C4): Using cached product context: machine assigned for
product: EB76782D55ED8A14ABB5C941C3B593BC
MSI (s) (F8:C4): SOURCEMGMT: Source is invalid due to invalid package
code.
MSI (s) (F8:C4): Note: 1: 1706 2: -2147483646 3: <product>.msi
MSI (s) (F8:C4): SOURCEMGMT: Processing net source list.
MSI (s) (F8:C4): Note: 1: 1706 2: -2147483647 3: <product>.msi
MSI (s) (F8:C4): SOURCEMGMT: Processing media source list.
MSI (s) (F8:C4): Note: 1: 2203 2: 3: -2147287037
MSI (s) (F8:C4): SOURCEMGMT: Source is invalid due to
missing/inaccessible package.
MSI (s) (F8:C4): Note: 1: 1706 2: -2147483647 3: <product>.msi
MSI (s) (F8:C4): SOURCEMGMT: Processing URL source list.
MSI (s) (F8:C4): Note: 1: 1402 2: UNKNOWN\URL 3: 2
MSI (s) (F8:C4): Note: 1: 1706 2: -2147483647 3: <product>.msi
MSI (s) (F8:C4): Note: 1: 1706 2: 3: <product>.msi
MSI (s) (F8:C4): SOURCEMGMT: Failed to resolve source

I am unsure where the negative value has come from. The routine is
defined in Installshield as having caching turned on and it is an
application object.

please any advice would be most welcome.

[Eric Pearson]

Since you didn't specify... is the package on the network the exact same
build that was installed?

If it IS a different build, Installshield by default will change the package
code in each build. MSI doesn't like trying to grab files for one package
from another package's media since it can't be sure it's grabbing what it
thinks it is, and so when MSI is running a repair and needs files, it will
only use a package with a matching package code.

Hello ross,

[ross.s...@gmail.com]

Hi Eric,

The proceedure i'm following, and it results in the same error. Is
installing a new build over the top.

This in turn produces the error.

Any subsequent repair also causes the error. It appears that everything
has updated though.

I have arranged the procedure to prompt so that I could select the .msi
file. Using the one from the install path or the one located in the
c:\windows\system32 directory causes the error.

I should add that this is not a problem when uninstalling the product
and reinstalling as new from our latest build. Further updates and
repairs from this scenario work ok even when rebuilding and
incrementing the release.

The difference between builds is the addition of the application ->
object containing the MSXML 3.0 being cached.

I have read a similar thread : "Windows installer writes corrupted
source list" but my key paths seem to hold the info from the HKLM for
the products SourceList\LastUsedSource as "n;1;c:\Windows\System32"

any ideas?

[Phil Wilson]

Eric is right. You can't create a new MSI package and replace the one that
is a source for repairs etc. That won't work. The error log is saying that
it wants the original source MSI file but that it's no longer valid because
the packagecode isn't the one used to install the product. The repair wants
the exact same MSI file that was used to install the product, and your
process has replaced it. Even if you made the packagecode the same as the
original source it's not safe to let the repair occur from it because it's
not the same as the real MSI file used to install the product, and the
product may just end up getting broken, needing constant repars or not
uninstalling properly etc.
--
Phil Wilson
[Microsoft MVP-Windows Installer]
Definitive Guide to Windows Installer
http://apress.com/book/bookDisplay.html?bID=280

<ross.s...@gmail.com> wrote in message
news:1138114547.4...@o13g2000cwo.googlegroups.com...

[ross.s...@gmail.com]

Thanks Phil,

I understand what you're saying, that the package code is changing and
therefore the reference is invalid. I'm going to try get the
reinstaller to recognise current settings and hopefully bypass this
call.

[ross.s...@gmail.com]

ross.s...@gmail.com wrote:

I feel my problem has evolved somewhat and I hope someone can advise me
as this is my first venture in Installshield.

I realise that the problem is being caused by the reference to the
<product>.msi having being changed. What I wish to achieve is when
updating to a newer version, for the merge module object to uninstall
itself so that the newer version and the updated .msi file can be used
without the 1706 error.

To clarify my settings:

I have in 'Application Data' -> 'Object' a merge module : MSXML 3.0
that within the 'UI options' tab is set to 'No msi' and is using both
the status text boxes. The 'other options' tab is set to be cached in
the System32 directory. I have the 'Uninstall the msi package during
the uninstall of a product' unchecked (I have tested this both checked
and unchecked with no joy). The 'msi engines' tab is used and the
current default is to use version 2.0 for 'windows 9x and windows
nt/2000'

In 'Organisation' -> 'Feature' looks to be the default with no
functions specified and with the 'File need' property set to 'Critical'
and the 'Include in build' set to 'Yes'

The help file(see attachment) talks of using the call
FeatureRemoveAllInLogFile() which I have tried to put in before each
FeatureReinstall() is called but with no success. Perhaps this should
be called at a specific place?

Does anyone have any ideas\implementation as to how this scenario could
be resolved without the need for the origonal .msi file?

thanks to anyone who has any ideas.

Ross

help
definition---------------------------------------------------------------------------------------------------------------------

Upgrades - There are no Windows Installer upgrades or patching.
However, you can still use create updates in InstallShield. In one
possible scenario, you have Feature1 in your original installation, and
in your update you add a Merge Module Object under Feature1. In this
example, the update performs correctly, installing the Merge Module
Object.

The tricky part of updates is handling the situation in which the
original installation has Feature1\Merge Module Object and the update
also has Feature1\Merge Module Object. The original Merge Module Object
is always uninstalled during the update and then the new one that is in
the update is installed. The reason why this occurs is that
InstallShield creates new ProductCode values in the .msi package for
every build. This is because Windows Installer patches and updates are
very difficult to understand and maintain, even for Windows Installer
experts. By uninstalling the original and installing the new one in
this case, the problems with Windows Installer patching and upgrades
are eliminated. This is to keep everything as simple as possible. So if
you call the function FeatureRemoveAllInLogOnly(), the original Merge
Module Object in the example above is uninstalled and the new Merge
Module Object in the update is installed. If you do not call
FeatureRemoveAllInLogOnly(), the original Merge Module Object is not
uninstalled during the update. The drawback to this is that the
original Merge Module Object is left on the machine after an
uninstallation of the product.

It is recommended that if you use a Merge Module Holder Object and you
want to update the product, and the Merge Module Holder Object has
changed-for example, you have added another merge module-you should
call FeatureRemoveAllInLogOnly() to remove the original Merge Module
Holder Object.

If you set the Uninstall property to FALSE, then the Merge Module
Holder Object is uninstalled, even if FeatureRemoveAllInLogOnly() is
called.

----------------------------------------------------------------------------------------------------------------------------------------

[Eric Pearson]

One can spend a very long time creating large installations, upgrades, etc,
and still be baffled by the complex rules that are in effect.

My suggestion would be to not try an "upgrade" scenario unless you have important
business reasons to do so. If you do, you'll be better off creating Patches
and that takes a lot of careful attention to component rules. Be prepared
to do a lot of reading.

To avoid all this , go to the "Upgrades" section in IS, and in "Small/Minor
Upgrade Settings" select Disable. This will force your users to uninstall
the previous version first.

If you'd like the uninstall to happen automatically, make any update a "Major
upgrade" and set it to uninstall the old one completely.

Hello ross,

>>>>>> eFile Name=1\<package>.msi,,,,,IsFirstPhysicalMedia=1)

>>>>>>
>>>>>> MSI (s) (F8:C4): Executing op:
>>>>>>
>>>>>> FileCopy(SourceName=msxml3.dll,SourceCabKey=msxml3.dll.7E4F6CB4_E
>>>>>> 769_4
>>>>>> 917_AA7E_0E3CA074ABB3,DestName=msxml3.dll,Attributes=16896,FileSi
>>>>>> ze=11
>>>>>> 29472,PerTick=32768,,VerifyMedia=1,,,,,CheckCRC=0,Version=8.40.94

>>>>>> 19.0, Language=0,Ins

[Stefan Krueger [MVP]]

I suspect that you are using a InstallScript (non-MSI) project type and
include a merg module using InstallShield's Merge Module Holder object -
which creates a .msi file for you at build time and calls that at install
time. This is a tricky scenario and there might be caching issues with it.
Maybe Microcosoft provides a install package for XML 3 that can be launches
as an exe? You could then run it using LaunchAppAndWait instead of using the
merge module holder object.

--
Stefan Krueger
Microsoft Windows Installer MVP

Please post your questions in the newsgroup or vist one of these web sites:

Windows Installer FAQ
http://www.msifaq.com - http://www.msifaq.de

InstallSite - Resources for Setup Developers
http://www.installsite.org
http://www.installsite.de (GERMAN)

<ross.s...@gmail.com> schrieb im Newsbeitrag
news:1138202309....@g14g2000cwa.googlegroups.com...