Problem with assembly loaded at runtime

[Luis Arvayo]

When I load an assembly at runtime, that is to say, a plugin DLL through
Assembly.Load, an old version of the assembly is loaded.
If I recompile the DLL and then copy the result to where the assembly is
loaded by the main app, anyway, the old assembly is used. From where ?, I
don't know. I don't have an error here. Checked several times, because if I
delete the assembly, at runtime it is not detected by the
Directory.GetFiles() method. It is as if the updated assembly is not taken
into account and an old version is always reloaded.

How to solve that ? It is the same problem if I shutdown and restart VS2003
or the computer.


Thanks in Advance
Luis Arvayo

 

[Frans Bouma [C# MVP]]

When I load an assembly at runtime, that is to say, a plugin DLL
through Assembly.Load, an old version of the assembly is loaded.
If I recompile the DLL and then copy the result to where the assembly
is loaded by the main app, anyway, the old assembly is used. From
where ?, I don't know. I don't have an error here. Checked several
times, because if I delete the assembly, at runtime it is not
detected by the Directory.GetFiles() method. It is as if the updated
assembly is not taken into account and an old version is always
reloaded.

How to solve that ? It is the same problem if I shutdown and restart
VS2003 or the computer.

Check if the old assembly is in the GAC:
vsvars32.bat
gacutil /l

you should also check the download cache:
gacutil /ldl

and if it's there, clear it:
gacutil /cdl

If you know the filename, it's often better to use LoadFrom.

Frans

--

 

[Andreas Mueller]

Luis Arvayo wrote:




Check if the old assembly is in the GAC:
vsvars32.bat
gacutil /l

you should also check the download cache:
gacutil /ldl

and if it's there, clear it:
gacutil /cdl

If you know the filename, it's often better to use LoadFrom.

Frans

I once had a problem when a plugin got into the download cache. I found
it by opening a cmd shell and typing:

dir "%USERPROFILE%\..\PlugIn.dll" /B /S


Is you DLL listed at a place where it shouln't be?

HTH,
ANdy

 

[John Murray]

The loader uses the following logic to find your assembly (by default,
you can change this somewhat)

GAC (If the assembly has a strong name)
CODEBASE
Probing (searching the APPBASE directory (where the configuration file
resides) and any subdirectories that are specified in apps configuration
assemblyBinding element) ... basically, it first looks for a library
with the appropriate name in the APPBASE directory, if it cannot find
it, it looks for a directory with the name of the assembly, and looks in
that directory for the assembly (library.) If that fails, it goes back
and uses the .exe extension vs. the .dll extension for the previous two
steps. If still not found it starts looking down the paths specified in
the assemblyBinding element.

An exception to the steps above is that if your load request contains a
cultural identifier, the loader will try to include that in the path as
well.


After all that ... are you running a copy of this from an ASP.NET
session and just compiling the library? In that case, you library could
be in the shadow directory?

 

[Luis Arvayo]

Is you DLL listed at a place where it shouln't be?


Yes, thank you this tip solved the problem.

 

[Luis Arvayo]

Thanks for the clear explain. It take me directly to the fact that the DLL
was located in a wrong place.