PDA

View Full Version : COM interop -6210 error: "can't load dependency"



davidsoncorry
03-14-2007, 05:29 PM
dum-da-DUM-dum...
[The story you are about to read is true. The names of the assemblies have been changed to protect the proprietary.]
dum-da-DUM-dum-DUMMM!

In Installshield 12 (Basic MSI project), I am trying to build a merge module containing a component that is a .NET assembly, COM interoperable, which depends on another assembly built elsewhere. The component is marked

.NET COM Interop=Yes
.NET Scan at Build=Properties Only
COM Extract at Build=No

I get the following error when I build the merge module:


Building COM .NET Interop information for components
RegAsm : error RA0000 : Could not load file or assembly 'MyCo.Library.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=eeeeeeeeeeeeeeee' or one of its dependencies. The system cannot find the file specified.
ISDEV : error -6210: An error occurred building COM .NET Interop information for Component MyCo.Asm_Using_MyCo.Library.Core.EEEEEEEE_EEEE_EEEE_EEEE_EEEEEEEEEEEE.

The dependent assembly MyCo.Library.Core assembly is not installed on the build machine, nor on its PATH. Its binary and .TLB are, however, accessible from the build machine.

I do not wish to run REGASM on this component at install time; I want Installshield to extract the .REG information and embed it in the .MSI package.

I would prefer not to install and register MyCo.Library.Core on my build machine, but if that is the simplest workaround, I'll buy it.

Is there a way to tell Installshield (or REGASM) where to look for the dependent library when extracting the .REG file? Can I, for instance, add an /asmpath switch to the REGASM command line (Options | .NET | REGASM path)? Is there some way to embed the MyCo.Library.Core .TLB file where REGASM or Installshield can get at it, for this component? Anybody got any better ideas?

Inquiring minds want to know. (My manager, for one... <grin/>)

Thanks, all.

-- Davidson

Ryan Phay
04-05-2007, 03:13 PM
Strangly, I am running into a similar issue. I have taken the regasm.exe wrapper and using the command line version of IS12 I've replaced the parameter -t "%DOTNET_DIR%" w/ -t "S:\9_5_0\Install\Binaries" where the latter location is where the wrapper executable is stored. This does not work, though, as the command line builder is still looking for regasm.exe, but now in the new location. If I change the name of the wrapper to regasm.exe it runs through fine however I'm guessing this will cause other issues when applications are looking for the "real" regasm.exe.

:eek:

Ryan:

davidsoncorry
06-04-2007, 12:30 PM
Hi, folks. In the end, I developed a workaround for this:

When a COM-interoperable .NET assembly has dependencies on other assemblies that are not either on the %PATH% nor in the same directory as the assembly being scanned, IS 12 can't extract registry info because regasm fails to load the dependent assemblies.

regasm can find these assemblies if you pass their directories in a semicolon-separated list via the /asmpath:dir1;dir2;... option. The problem is that regasm wants its arguments in the order


regasm AssemblyName [options]

not


regasm [options] AssemblyName

and IS 12 simply appends the AssemblyName to the end of the regasm path specified in Tools | Options | .NET | Regasm.exe location. I could find no way to tell IS to append the /asmpath option after the AssemblyName.

My workaround was to write a small "wrapper" program. This program

1) Looks up the location of the real regasm.exe (usually %WinDir%\Microsoft.NET\Framework\v2.0.50727\regasm.exe)
2) Looks up an environment variable named %REGASM_ASMPATH%. If that value is non-empty,
3) appends /asmpath:value-of-%REGASM_ASMPATH% to the command-line arguments passed in from IS
4) spawns the real regasm.exe with the enhanced command line, waits for it to end, collects its exit code, and
5) exits with that same code

Then I point the .NET | Regasm.exe location to my new wrapper program, and run IS builds normally. IS doesn't know that it's running my wrapper, which acts just like the real regasm.exe but is smart enough to find off-site assemblies, and all is happy.

I would post the code, but I don't own it, my company does, so... However, it's only 60 lines or so of code, which any competent C hacker can whack out in an hour or two from the above description. Or any competent VB, JScript or what-have-you hacker, for that matter.

We could skip all this if, say, Installshield 14 let us enter a full regasm command-line like


"c:\Windows\Microsoft.NET\Framework\v2.0.50727\regasm.exe" %A /asmpath:local1;local2;local3

in the .NET option tab, where IS would substitute the assembly name into %A before invoking the command-line, or something like that.

That's a hint, Macrodudes.

Ta. -- Davidson