Re: LoadFromBytes="true" & XLL Loading

[Govert van Drimmelen]

Setting LoadFromBytes="true" might interfere with how managed types
are resolved, since the assembly is not loaded into any .NET 'Load
Context'. This probably means that packing it into the .xll file using
ExcelDnaPack also won't work for you.

-Govert

On Jun 28, 11:31 pm, Jon49 <nyman...@gmail.com> wrote:
> FYI when I do the above command in my file the xll stops loading properly.
> I'm opening the XLL file directly which loads the special workbook that my
> add-in works with. Not sure if that has anything to do with it. I'm using
> NetOffice and framework 4.0. Works fine when I remove the LoadFromBytes
> command. Not a huge issue for me but thought you might like to know.

[Govert van Drimmelen]

Hi Jon,

If you either:
1. set LoadFromBytes="true", or
2. set Pack="true", run ExcelDnaPack and run the packed add-in,
then your assembly will be loaded using Assembly.LoadFromBytes, and
hence into the "No Context" case mentioned in the link you point to.

For many add-ins that is not a problem, including add-ins that
reference and pack NetOffice. But maybe you are running into some of
the potential problems described in that link.

Some add-in configurations, for example when you have assemblies that
are both
- exported to Excel as 'ExternalLibraries', and
- referenced by other assemblies,
might be problematic, since an instance of the assembly might be
loaded into the "No Context" case, and another instance into some
other Load Context.

The .NET assembly resolution and loading is indeed a complicated
topic.

You say "the xll stops loading properly", but that doesn't really
explain the problem.
Perhaps you could make a really simple case that exhibits the issues
you want to ask about, and post that for a closer look.

Regards,
Govert


On Jul 3, 11:26 pm, Jon49 <nyman...@gmail.com> wrote:
> I've been trying to wrap my head around this one. I've read what Microsoft
> says on the topic <http://msdn.microsoft.com/en-us/library/dd153782.aspx>.
> But am a bit confused still. Should I be able to use one of the methods and
> get packing to work? Is this caused by me coding incorrectly or is this a
> .NET issue?
>
> Thanks,
>
> Jon

[Govert van Drimmelen]

Hi Jon,

That looks like a cool add-in!

I think I understand your question and what is going on.
If your .dna file and its matching .xll file are in a directory ...
\Test and you have your add-in .dll and all the NetOffice .dlls in a
subdirectory ...\Test\Libraries, then with this .dna file it will
work:

<DnaLibrary Name="Budget Time Card Add-in" RuntimeVersion="v4.0">
<ExternalLibrary Path="Libraries\BudgetTimeCardCombinedProjects.dll"/
>
</DnaLibrary>

But with this .dna file it will not work:
<DnaLibrary Name="Budget Time Card Add-in" RuntimeVersion="v4.0">
<ExternalLibrary Path="Libraries\BudgetTimeCardCombinedProjects.dll"
LoadFromBytes="true"/>
</DnaLibrary>

This is because the NetOffice libraries fail to load in the second
case.

In the first case the .NET loader is loading the .dll from the ...\Test
\Libraries directory into the "LoadFrom" load context. Since .NET
knows where the .dll file was, it will also probe that same directory
when looking for the NetOffice dependencies.

In the second case your add-in .dll is loaded from bytes in memory,
and the .NET loader never knows which directory it came from, so fails
to resolve those NetOffice dependencies.

The most pragmatic way around this is to put all the files in the same
directory (the .dna file, the .xll file and all the .dll files). Then
your LoadFromBytes="true" setting will not be a problem, since .NET
will still look for the dependencies in the same directory as the .xll
file. (The reason for using the LoadFromBytes option in this case
would be to allow you to rebuild the add-in and reload without
restarting Excel.)

When making a packed add-in - with everything in a single .xll file -
you will also have to deal with these dependency .dlls. In this case,
however, you can tell Excel-DNA to also pack those NetOffice .dll
files into your packed add-in by putting some <Reference> attributes
into you .dna file.

I ran through this process just to check that it all works. Here's
what I did (from downloading and extracting your add-in code):

1. Fix the references to NetOffice 1.4.1 and Excel-DNA to my
locations, and rebuild.

2. Place the .dna file in the output directory, and edit it to read as
follows:

<DnaLibrary Name="Budget Time Card Add-in" RuntimeVersion="v4.0">
<Reference Path="LateBindingApi.Core.dll" Pack="true"/>
<Reference Path="ExcelApi.dll" Pack="true"/>
<Reference Path="OfficeApi.dll" Pack="true"/>
<Reference Path="VBIDEApi.dll" Pack="true"/>
<ExternalLibrary Path="BudgetTimeCardCombinedProjects.dll"
Pack="true"/>
</DnaLibrary>

3. So in the output directory I have the following (and a few .xml
and .pdb files):
- BTCAI-CombineTest.dna
- BTCAI-CombineTest.xll (just a copy of ExcelDna.xll)
- BudgetTimeCardCombinedProjects.dll
- ExcelApi.dll
- LateBinding.Core.dll
- OfficeApi.dll
- VBIDEApi.dll

4. Now I open a command prompt in that directory and run:
.....(path to).....\ExcelDnaPack.exe BTCAI-CombineTest.dna

5. I see no errors and the resulting file created is called
BTCAI-CombineTest-packed.xll (838 KB).

6. I copy this file to a directory on its own, and open it (you could
rename it first to Whatever.xll).

7. It loads and all seems fine (though I'm not really sure what to
check for). You now have a single .xll file to deploy.


I hope this makes things more clear.
Please write back if I need to explain any of it in more detail.

Regards,
Govert



On Jul 4, 9:08 pm, Jon49 <nyman...@gmail.com> wrote:
> And here is the DNA file.

>  BTCAI-CombineTest.7z
> < 1KViewDownload