Repair failing
Neville Lang
Now that I can install and uninstall my MSI file (a previous post describes
a problem I had with a CA on uninstalling), I have found another problem.
In the Control Panel, I click on Add/Remove programs and then click on my
installed app's Support information link to display a screen. On that
screen, there is a Repair button. When I click on this, to check that a
Repair can be done correctly as a test, it returns with an error:
"Exception occurred while initializing the installation:
System.ArgumentException: Invalid directory on URL".
I cannot understand what this error message is telling me.
Further to that, using Start / Run, I typed in the following:
MsiExec.exe /f {...ProductCode...} /l*v c:\mylogr.log
and very soon after this is launched, I receive an error message:
"This installation package could not be opened. Verify that the package
exists and that you can access it, or contact the application vendor to
verify that it is a valid Windows Installer package."
I checked that the original MSI package still existed on my hard drive and
also that the cached version existed in C:\Windows\Installer. The cached
version had various filenames in testing but were like "2cc2adf.msi".
Can anyone shed some light on why the Repair is failing with different error
messages as it is started in two different ways?
Regards,
Neville Lang
Neville Lang
What I should have added in my previous post is that this Repair problem
occurs each time I build the solution with VS .NET 2003, install it and try
to run the repair after that new install.
I just wanted to make it clear that this is not an app that has been
installed sometime ago nor is it one where the cached package could be
corrupted as a new one is created each time. I have even opened up the
cached package with ORCA and ran the validation checking for any internal
corruptions, and everything seemed fine.
Still the problem persists. I get the feeling that the Repair action may not
be determining the TARGETDIR correctly, the folder where the MSI is
expanded. Any thoughts on how I can test this? All registry entries seem to
be OK as far as I can tell.
Regards,
Neville Lang
"Neville Lang" <neville@MAPS_ONnjlsoftware.com> wrote in message
news:OPzIT6P...@TK2MSFTNGP11.phx.gbl...
Neville Lang
Further to my previous post on this topic, when running a Repair, I have
created a log file to see where it failed.
Here is an extract of the log file early in the list:
...
...
MSI (s) (FC:DC): Resolving source.
MSI (s) (FC:DC): Using cached product context: User non-assigned for
product: 2D05DC7E400CD6A4BB03E44515A75697
MSI (s) (FC:DC): Using cached product context: User non-assigned for
product: 2D05DC7E400CD6A4BB03E44515A75697
MSI (s) (FC:DC): User policy value 'SearchOrder' is 'nmu'
MSI (s) (FC:DC): User policy value 'DisableMedia' is 0
MSI (s) (FC:DC): Machine policy value 'AllowLockdownMedia' is 0
MSI (s) (FC:DC): SOURCEMGMT: Media enabled only if package is safe.
MSI (s) (FC:DC): SOURCEMGMT: Looking for sourcelist for product
{E7CD50D2-C004-4A6D-BB30-4E54517A6579}
MSI (s) (FC:DC): Using cached product context: User non-assigned for
product: 2D05DC7E400CD6A4BB03E44515A75697
MSI (s) (FC:DC): SOURCEMGMT: Adding {E7CD50D2-C004-4A6D-BB30-4E54517A6579};
to potential sourcelist list (pcode;disk;relpath).
MSI (s) (FC:DC): Using cached product context: User non-assigned for
product: 2D05DC7E400CD6A4BB03E44515A75697
MSI (s) (FC:DC): SOURCEMGMT: Now checking product
{E7CD50D2-C004-4A6D-BB30-4E54517A6579}
MSI (s) (FC:DC): SOURCEMGMT: Media is enabled for product.
MSI (s) (FC:DC): SOURCEMGMT: Attempting to use LastUsedSource from source
list.
MSI (s) (FC:DC): SOURCEMGMT: Trying source C:\Develop_WIN\MySetup\Release\.
MSI (s) (FC:DC): Using cached product context: User non-assigned for
product: 2D05DC7E400CD6A4BB03E44515A75697
MSI (s) (FC:DC): SOURCEMGMT: Resolved source to:
'C:\Develop_WIN\MySetup\Release\'
MSI (s) (FC:DC): SOURCEDIR ==> C:\Develop_WIN\MySetup\Release\
MSI (s) (FC:DC): SOURCEDIR product ==>
{E7CD50D2-C004-4A6D-BB30-4E54517A6579}
...
...
And here's where the error occurs:
...
...
MSI (s) (FC:DC): Note: 1: 2360
MSI (s) (FC:DC): Note: 1: 2360
MSI (s) (FC:DC): Note: 1: 2360
MSI (s) (FC:DC): Note: 1: 2360
MSI (s) (FC:DC): Executing op: InstallProtectedFiles(AllowUI=1)
MSI (s) (FC:DC): Executing op:
ActionStart(Name=_B1A5BABB_E9E4_432F_95FA_9C5CABDA1456.install,,)
Action 13:13:08: _B1A5BABB_E9E4_432F_95FA_9C5CABDA1456.install.
MSI (s) (FC:DC): Executing op:
CustomActionSchedule(Action=_B1A5BABB_E9E4_432F_95FA_9C5CABDA1456.install,Ac
tionType=1025,Source=BinaryData,Target=ManagedInstall,CustomActionData=/inst
alltype=notransaction /action=install /LogFile= /MsiSource="\" /MsiTarge
t="C:\Program Files\NJLang\MyApp\\" "C:\Program
Files\NJLang\MyApp\CustomInstaller.dll"
"C:\DOCUME~1\NEVILL~1\LOCALS~1\Temp\CFG11B.tmp")
MSI (s) (FC:DC): Creating MSIHANDLE (26) of type 790536 for thread 476
DEBUG: Error 2835: The control ErrorIcon was not found on dialog
ErrorDialog
The installer has encountered an unexpected error installing this package.
This may indicate a problem with this package. The error code is 2835. The
arguments are: ErrorIcon, ErrorDialog,
Error 1001. Exception occurred while initializing the installation:
System.ArgumentException: Invalid directory on URL..
DEBUG: Error 2769: Custom Action
_B1A5BABB_E9E4_432F_95FA_9C5CABDA1456.install did not close 1 MSIHANDLEs.
The installer has encountered an unexpected error installing this package.
This may indicate a problem with this package. The error code is 2769. The
arguments are: _B1A5BABB_E9E4_432F_95FA_9C5CABDA1456.install, 1,
Action ended 13:13:35: InstallFinalize. Return value 3.
...
...
From what I can see from the above, the SourceDir was determined as
C:\Develop_WIN\MySetup\Release\. However, the line -
(Action=_B1A5BABB_E9E4_432F_95FA_9C5CABDA1456.install,ActionType=1025,Source
=BinaryData,Target=ManagedInstall,CustomActionData=/installtype=notransactio
n /action=install /LogFile= /MsiSource="\" /MsiTarge
t="C:\Program Files\NJLang\MyApp\\" "C:\Program
Files\NJLang\MyApp\CustomInstaller.dll"
"C:\DOCUME~1\NEVILL~1\LOCALS~1\Temp\CFG11B.tmp")
shows the the /MsiSource="\" which I thought was strange. The original
installation log had the /MsiSource="C:\Develop_WIN\MySetup\Release\\" at
this point.
In my search on the net using Google, I discovered that the error:
"DEBUG: Error 2835: The control ErrorIcon was not found on dialog
ErrorDialog"
seems to occur when any error is detected. After this error, I also get
"...Invalid directory on URL.". Once again a Google search did not reveal
too much either.
From the above, I am guessing that it is the /MsiSource that is triggering
the ErrorIcon error. My question is how can I control or set the MsiSource
so that it is passed to the CA correctly via CustomActionData? It seems
earlier in the process, the SourceDir is known but then gets set to "\" when
the /MsiSource is required.
Regards,
Neville Lang
Neville Lang
After going through your book ("The Definitive Guide to Windows Installer")
a second time, I discovered a lead to my problem you gave on pages 196 and
197 concerning CustomActionData.
Following this lead, I was able to now prove that my parameter
/MsiSource="[SourceDir]\" is the culprit. I simply removed it from the
Target column of the Type 51 CA entry in the CustomAction table using ORCA.
While this parameter works without a problem for a first time Install, it
fails when doing a Repair, leading to the problems I have experienced to
date.
Given that I am still inexperienced in this area (but learning a heck of a
lot), can you or anyone else give me an idea on how I can safely pass my
MsiSource parameter in CustomActionData under both the first Install and the
Repair process? I know it is likely to be a Condition but does that mean I
need two CAs, one conditioned on Installed="" and one on Installed<>""?
Again, I am using VS .NET 2003 and my CA has InstallerClass=True, since I
have CAs in a .NET DLL.
Regards,
Neville Lang
"Neville Lang" <neville@MAPS_ONnjlsoftware.com> wrote in message
news:umMm7NZk...@tk2msftngp13.phx.gbl...
Neville Lang
Finally, I have solved my problem with the Repair process failing each time.
My scenario:
------------------
I have a need to pass SourceDir to my deferred .NET CA. This is accomplished
by using a string /MsiSource="[SourceDir]\" in the CustomActionData property
in a Setup project associated with my solution in VS .NET 2003 where VS .NET
2003 also generates the MSI file.
Results of tests along the way:
--------------------------------------------
While the CustomActionData string works fine for the first installation of
myapp, it fails on a Repair. The first error box on this failure contained
the following error:
"Exception occurred while initializing the installation:
System.IO.FileNotFoundException: File or assembly name xxx, or one of its
dependencies, was not found." where "xxx" is a string showing part of a
folder name used for TARGETDIR based on the [Manufacturer]\[ProductName]
properties.
After researching this issue, I found something where names in a path
(between backslashes) could not be longer than 12 characters for a Repair
(though longer strings work fine for first installations). After fixing the
folder name so that it only contained max. 12 characters between backslashes
in a folder path (by changing the [Manufacturer[]\[ProductName], I then
received another error message when running the Repair:
"Exception occurred while initializing the installation:
System.ArgumentException: Invalid directory on URL."
It was here that I began using the log file though on reflection, I guess I
should have used it earlier. Just before the above error in the log file,
there was another error message:
"DEBUG: Error 2835: The control ErrorIcon was not found on dialog
ErrorDialog.". After further investigation into this issue, I have now
determined that this error message is misleading as it is one that seems to
be triggered if any type of error is encountered. Maybe this is restricted
to calls of CAs, I do not know. Further inspection of my log file also
showed that my CustomActionData parameter value was /MsiSource="\", in other
words, the [SourceDir] is blank, or more correctly, is not resolved.
After doing further searching and experimenting, I found the workaround to
this problem was to simply insert a new action into the
InstallExecuteSequence table of the MSI file using Orca, as follows:
Action = ResolveSource
Condition = Installed NOTE: conditioned only for Repairs, after first
installation
Sequence = 1450
This action comes after InstallValidate and before InstallInitialize. The
result of this action is to resolve the SourceDir for the reinstallation
(the Repair) process. Apparently, from what I can gather from the log file,
the SourceDir is resolved in the first installation but not from subsequent
installations, like Repair, at least at the point of calling the CA. The log
file did show the SourceDir was resolved early in the log file for a Repair
but not at the point the CA is called. I can only surmise that it got reset
somewhere along the sequence.
Conclusion:
-----------------
I can now only conclude that if you require to pass SourceDir to a CA using
the CustomActionData property, you also need to insert the above additional
action in the InstallExecuteSequence AFTER VS .NET 2003 generates a new MSI
file.
To add the extra action easily, one method that I found easy was to use a
VBScript. I have not used VBScript before so I clue from Phil Wilson's book
"The Definitive Guide to Windows Installer" enabled me to create such a
script file to easily perform this task after VS .NET 2003 generates the MSI
file.
Hmm, now if only I can get that script to run automatically from within VS
.NET 2003 after the MSI is created, it would be perfect...
By the way, I found that once the ResolveSource action was added to the MSI
file, the earlier issue of restricting the TARGETDIR path to 12 characters
between backslashes, disappeared. I can now use the full
[Manufacturer]\[ProductName] without triggering an error once the
ResolveSource action has been inserted. I do not know why these two issues
are connected but it now all seems to work fine.
Hopefully, this post will assist others who may have a similar scenario to
me. I probably would not have been able to solve these issues without Phil
Wilson's book. Prior to my reading of his book, I had virtually no knowledge
of how Windows Installer worked in detail. I had just enough information to
get my app to deploy but when I got in problems, it was at this point I
decided I needed to know more. Phil's book certainly gave me the design
principles of the Windows Installer and his examples worked for me.
Regards,
Neville Lang
Phil Wilson
System.IO.FileNotFoundException because of the way that the assemblies are
loaded to call the Installer classes. Internally I believe that
Assembly.LoadFrom is used, and it doesn't load dependent assemblies in all
circumstances:
http://support.microsoft.com/default.aspx?scid=kb;en-us;327435
So if there are dependent assemblies, perhaps they aren't loaded.
--
Phil Wilson
[MVP Windows Installer]
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760
"Neville Lang" <neville@MAPS_ONnjlsoftware.com> wrote in message
news:e7icMj7k...@TK2MSFTNGP15.phx.gbl...
Neville Lang
Where I used "xxx" in reporting the error message, it was in fact the word
"Neville". The TARGETDIR is made up of the [Manufacturer]\[ProductName]. In
my case, the Manufacturer property is "Neville J. Lang & Assoc. Pty. Ltd.".
The product name also has a space in it. My guess was that handling spaces
in a path might have been a problem, at least for the error message itself.
When I searched for other similar errors in Google, I came across the idea
that folder names might need to be restricted to 12 characters for Repairs,
at least in one instance where I read it. Reducing my folder names to 12
characters and taking out the spaces seem to overcome those initial error
messages until I got the error message "System.ArgumentException: Invalid
directory on URL", which I am sure was more related to the SourceDir
problem.
Reading the link you supplied to the article suggested the use of similar
names. In my case, there were no similar names so maybe this might not have
been the problem.
However, the addition of the ResolveSource action in the MSI, seemed to have
fixed everything, including the folder name length issue, for my scenario.
Thanks again for your response.
Regards,
Neville Lang
"Phil Wilson" <pdjw...@nospam.cox.net> wrote in message
news:uR7Y1rUl...@TK2MSFTNGP11.phx.gbl...