I'm receiving the "unable to get installer types in <assembly>" error
message now that I've added another custom action to my setup project.
The funny thing is the assembly that it's pooping itself on has fewer
dependencies than my other custom actions, and all of which are
dependencies to at least one other custom action.
After looking at the fusion log after a failed install attempt I see
this:
*** Assembly Binder Log Entry (12/08/2004 @ 3:04:27 PM) ***
The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file
specified.
Assembly manager loaded from:
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\fusion.dll
Running under executable C:\WINDOWS\System32\MsiExec.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: DisplayName = NetMAARS, Version=1.0.1685.28463, Culture=neutral,
PublicKeyToken=null
(Fully-specified)
LOG: Appbase = C:\WINDOWS\System32\
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : (Unknown).
===
LOG: Processing DEVPATH.
LOG: DEVPATH is not set. Falling through to regular bind.
LOG: Policy not being applied to reference at this time (private,
custom, partial, or location-based assembly bind).
LOG: Post-policy reference: NetMAARS, Version=1.0.1685.28463,
Culture=neutral, PublicKeyToken=null
LOG: Attempting download of new URL
file:///C:/WINDOWS/System32/NetMAARS.DLL.
LOG: Attempting download of new URL
file:///C:/WINDOWS/System32/NetMAARS/NetMAARS.DLL.
LOG: Attempting download of new URL
file:///C:/WINDOWS/System32/NetMAARS.EXE.
LOG: Attempting download of new URL
file:///C:/WINDOWS/System32/NetMAARS/NetMAARS.EXE.
LOG: All probing URLs attempted and failed.
Why the hell is it looking in the sys32 folder and not in [TARGETDIR]?
This one is particualrly baffling as all other custom actions reside
in [TARGETDIR] and they all work!
Side node: I would have thought the task of application installation
would be simple. Why the hell has MS gone to the trouble of making
this a painful, painful experience?
Aaron.
Phil Wilson - 15 Aug 2004 22:17 GMT
It will look in TARGETDIR only if that is the AppBase for what you're
running. When you call DLL code out of msiexec.exe, it makes sense that this
is the System folder. When you say "other cutom actions reside in TARGETDIR"
are they executables or DLLs?
BTW, I recommend that you set an actual version in your assemblyinfo file -
it looks like you've got 1.0.*, meaning that every time you build it will be
different, and your clients that have references to a particular version
won't find it if you do another build. --
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760
> I'm receiving the "unable to get installer types in <assembly>" error
> message now that I've added another custom action to my setup project.
[quoted text clipped - 54 lines]
>
> Aaron.
Aaron Thomas - 16 Aug 2004 02:44 GMT
Hi Phil,
Thanks for taking the time to look at my problem.
I don't understand why the installer would look in the Sys32 folder for
a dll that it has just placed in TARGETDIR. This is made more confusing
by the fact that another dll, which is also placed in the TARGETDIR, is
called without issue. I don't believe it to be a dependecy issue as the
assembly it cannot locate is the custom action assembly itself! Wierd.
Ideas??
Aaron.