Assembly.Load() exception

S

Steve

I'm playing with late binding and trying a very simple test to load an
assembly

In my "Host" application I have this code:
<code>
string modulePath =
@"C:\PMDRepository\Tools\ManfBusProcMgr\Modules\TestModule\bin\Debug\TestModule";
Assembly a = Assembly.Load(modulePath);
</code>

This is throwing the following exception:
Could not load file or assembly
'C:\\PMDRepository\\Tools\\ManfBusProcMgr\\Modules\\TestModule\\bin\\Debug\\TestModule'
or one of its dependencies. The given assembly name or codebase was invalid.
(Exception from HRESULT: 0x80131047)


The assembly that I'm trying to load is just a simple class library with one
member and one property. Both were created in VS2005.
I've done some initial googling, but nothing is popping up. Any ideas?

Thanks for reading!
Steve Klett
 
M

Mattias Sjögren

string modulePath =
@"C:\PMDRepository\Tools\ManfBusProcMgr\Modules\TestModule\bin\Debug\TestModule";
Assembly a = Assembly.Load(modulePath);
</code>

Assembly.Load takes a assembly name, not a file path. You can try
Assebmly.LoadFrom instead (though it has its own set of problems).


Mattias
 
S

Steve

I tried just the name and I get the same exception.
Does the assembly need to be in the same location as the loading assembly?
 
C

C.C. \(aka Me\)

You did not specify the filename or you forgot to put the extention on the
filename.

TestModule needs to have an extention (.DLL or .EXE).
 
S

Steve

That's the confusing part. LoadFrom() works when I specify the full path to
the module including extension. But Load() just wants the modul name, which
in my case is TestModule, but it failes.

Either way, LoadFrom() is working and that's fine for me, at least for
testing at this point.

Thanks for the post!
 
C

C.C. \(aka Me\)

But the two methods are not the same.. See below from the MSDN
documentation:

Assembly SampleAssembly;
// You must supply a valid fully qualified assembly name here.
SampleAssembly = Assembly.Load("Assembly text name, Version,
Culture, PublicKeyToken");
Type[] Types = SampleAssembly.GetTypes();
// Display all the types contained in the specified assembly.
foreach (Type oType in Types)
{
Console.WriteLine(oType.Name.ToString());
}


Load takes a fully qualified assembly name, not the name of a file.

Hope this helps.
 
D

David Levine

Assembly.Load requires the full name, also known as the display name, of the
assembly, which is either its simple name (e.g. MyAssembly) without an
extension, or the fully qualified name, which consists of its simple name, a
version, a public key token, and its culture. For example,
Assembly.Load( "MyAsm, Version=1.0.1.220, Culture=Neutral,
PublicKeyToken=83b26e4166b7e1b8");

This also requires that the assembly be located either in the appdomain's
base directory, in a directory below there and which is one of the
components of the appdomain's PrivateBinPath, (so that the runtime knows how
to locate it), or specified in an app.config with a binding redirect and a
codebase hint. There are other places it can be located and mechanisms used
to tell the runtime how to find it, but these ought to get you started.
There are lots of options.

If you use Assembly.LoadFrom the the argument specified if the fully
specified path, either on the file system or to a url. This does not require
that the assembly be located in your appdomain's base directory, but it has
other limitations that can cause problems. Another major difference is that
the runtime internally stores loaded assemblies into multiple lists; the
Load context and the LoadFrom context (and others).

I've found it is usually better to use Load rather then LoadFrom because of
the way that the runtime locates and loads dependencies. If you use LoadFrom
you'll usually find it necessary to also subscribe to the
AppDomain.AssemblyResolve event to manually load dependencies of that
assembly.

I prefer to use a combination approach. I use:

AssemblyName an = AssemblyName.GetAssemblyName(filePath);
Assembly.Load(an);

This loads the filepath into the AssemlyName's codebase field and also
extracts all the other information from the assembly's manifest (version,
token, and culture). When you call Assembly.Load(an) the runtime tries to
load the assembly using the display name information, and if it can resolve
it it loads it into the Load context. If that fails it falls back to doing a
LoadFrom on the file path, loading it into the LoadFrom context.

Dave
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top