xll locks with LoadFromBytes=True

[newbie]

Govert,

In the dna file, I specify LoadFromBytes=True for an external
library. Recently, I haven't been able to refresh the library like I
used to. The library is locked by Excel, and can't be replaced. I
don't know what had happened. Any idea?

Thanks,

Candy

[Govert van Drimmelen]

Hi Candy,

1. I think the xml is case sensitive, so bu sure that you have
LoadFromBytes="true"

2. I did make some small changes in a recent build that might affect
this. Are you using the released version 0.29 or a newer check-in?

3. Might the assembly be referenced by another library you are
loading?
For example, if you have A.dll and B.dll, with A.dll being referenced
by B.dll, and you have
<DnaLibrary>
<ExternalLibrary Path="A.dll" LoadFromBytes="true" />
<ExternalLibrary Path="B.dll" LoadFromBytes="true" />
</DnaLibrary>
then I'd expect A.dll to be locked by Excel, since the .NET runtime is
loading from the file when it resolved the reference it finds in
B.dll.

You can deal with this case by putting A.dll in another directory. So
put A.dll in Libraries\A.dll, and try:
<DnaLibrary>
<ExternalLibrary Path="Libraries\A.dll" LoadFromBytes="true" />
<ExternalLibrary Path="B.dll" LoadFromBytes="true" />
</DnaLibrary>
where I suspect the reference resolution will work, and resolve to the
LoadFromBytes loaded assembly.

------

If that's still not it, I can try to figure out how to look more
closely.

Regards,
Govert

[newbie]

1. I have "true" not "True" in the dna file.
2. I am using the precompiled release version.
3. The assembly references other assemblies in the same directory.
All the assemblies are locked up. Using your example, both A.dll and
B.dll are locked up.

Candy

> > Candy- Hide quoted text -
>
> - Show quoted text -

[Govert van Drimmelen]

Hi Candy,

So we do expect those assemblies referenced by other to be locked.

Do you have an assembly B.dll that is not referenced by any other
assembly, and is only loaded via the ExternalLibrary with
LoadFromBytes="true", yet it is locked?
That would be surprising.

I suggest you make a small solution that reproduces the unexpected
case.

One could explore further by checking the Debug trace in Visual
Studio, or switching on the .NET "Fusion logging" -
http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx.

-Govert

[newbie]

> So we do expect those assemblies referenced by other to be locked.

I agree. But the assembly that wasn't a reference was also locked.

[newbie]

> Do you have an assembly B.dll that is not referenced by any other
> assembly, and is only loaded via the ExternalLibrary with
> LoadFromBytes="true", yet it is locked?
> That would be surprising.

No I didn't have that. In a simpler sample project, everything works
as expected.

> One could explore further by checking the Debug trace in Visual
> Studio, or switching on the .NET "Fusion logging" -

> http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebug....

Would you let me know what should I look for in Debug trace or the
Fusion Log? For example, how to tell whether a dll is locked, and by
which file or process?

Thanks.

[Govert van Drimmelen]

Hi Candy,

I suggest you make your simple example which works as expected more
and more complicated until you see the point where the unexpected
behaviour occurs.

In the Debug trace and Fusion log, you'd by looking for cases where
the unreferenced assembly is loaded from its full path.
You can compare the load entries between the simple case where
everything works as we expect, and the full add-in where the
unexpected happens.

If the debug trace shows only the assembly name:
'excel.exe' (Managed (v2.0.50727)): Loaded 'DynamicDelegates'
then its loaded with no context (from bytes, not locking the file).

If the debug trace shows the full path:
'excel.exe': Loaded 'C:\Program Files (x86)\Common Files\microsoft
shared\VBA\VBA7\VBE7.DLL', Cannot find or open the PDB file
then you're probably in the Load or LoadFrom context (locking the
file).

The fusion log will be even more explicit - it will show the probing
in cases where the runtime loader is trying to load an assembly (which
we don't expect for the assemblies that are not referenced, to be
explicitly loaded by Excel-DNA instead of the loader).

-Govert

[newbie]

I encountered an exception after I moved reference to another
directory, and updated the dna file accordingly.

updated to this methodology:

<DnaLibrary>
<ExternalLibrary Path="Libraries\A.dll" LoadFromBytes="true" />
<ExternalLibrary Path="B.dll" LoadFromBytes="true" />
</DnaLibrary>

"A problem occurred while an add-in was being initialized
(Initialization failed). The add-in is built with ExcelDna and is
being loaded from My.dll."

In Debug trace, all libs (A.dll and B.dll) where loaded without the
absolute path. Looks promising except it didn't load.

> > Thanks.- Hide quoted text -

[newbie]

Govert,

I got the xll to load. The issue was that I turned Copy Local to
false on all references. The indirectives, as a result, are missing.

I also linked the dlls from another directory. Do you know why
linking to the one in the same directory didn't work? Mechanically
they seem to be identical.

Although the dlls don't lock anymore, they don't seem to load the
latest? I added a MessageBox in AutoOpen which didn't pop up when the
xll reloads.

Candy

> > Thanks.- Hide quoted text -

[newbie]

I have A.dll, B.dll, and C.ll. B references A. C references A and
B. In Debug trace, I saw

'EXCEL.EXE' (Managed (v4.0.30319)): Loaded 'A', Symbols loaded.
'EXCEL.EXE' (Managed (v4.0.30319)): Loaded 'B', Symbols loaded.
'EXCEL.EXE' (Managed (v4.0.30319)): Loaded 'C', Symbols loaded.
...
'EXCEL.EXE' (Managed (v4.0.30319)): Loaded 'C:\csharp\Dev\ExcelApp\bin
\Debug\A.dll', Symbols loaded.

Looks like A.dll was loaded twice - once from byte, another time at
the absolute path.

I tried adding a breakpoint in AutoOpen. The breakpoint wasn't
reached in Debug mode. I am not sure if AutoOpen was executed.

> > Thanks.- Hide quoted text -