Deploy Excel-DNA

[Lothy]

Hi Govert,

I just released the first project with your great tool and it works
like a charm, thanks a lot!

Unfortunately there are some bits and bobs I have to deal with.
In my company I'm banned from using external libaries, everything has
to be compiled in our deployment environment.I still have the option
to put external libaries to my project via external link from my
workspace but then I can only deploy a so called test-project, wich is
not conform with our company restrictions (I have done that for this
project, but on further projects I'd like to avoid this). With the
ExcelDna.Integration.dll, there is no problem I compiled and signed
it, this works fine. My question is, how do I compile the xll-file and
give it another name during compilation (sorry, my CPP-skills are so
poor...)? If this is not possible, I compile it as it is and rename it
during installation-process.

Furthermore it's a bit ichy, that I have to copy the xll-file in the
same folder where my .dll is at home. This is in scenarios bad, where
the user don't have access to the programm-folder because of non
admin permissions on his machine, or the windows terminal server where
the software is installed and hosted. The dll has references to other
dll's of the project, so it's not possible to move it to the user-
directory e. g.
Is it possible to save a full path to the dll in the .dna-file?

<DnaLibrary>
<ExternalLibrary Path=”C:\testfolder\MyAddIn.dll” />
</DnaLibrary>

Thanks a lot and have a good time.

Cheers
Gerhard

[Govert van Drimmelen]

Hi Gerhard,

You should not be redistributing ExcelDna.Integration.dll with your
add-in. A copy is embedded in the .xll when compiling, and if both the
embedded version and the loose file are present you will run into
problems. You should rather be signing the compiled .xll file - that
would allow you to properly use Excel's security to check protect you
from bad add-ins.

You should be able to add a post-build step to the compilation of
ExcelDna.xll that renames it. Or you can rename when you deploy.

I suggest you also look into the packing options (ExcelDnaPack.exe) -
that should give you some ways to simplify deployment. The idea might
be to pack some or all of your libraries into the .xll file and then
sign it. That should ensure good security from the Excel perspective.

The ExternalLibrary path can be an absolute path or a path relative to
the .xll file. Have you had any problems with the absolute paths?
However, I don't think other dependencies would be automatically
resolved from that path - you might have to add some <Reference ... />
entries with full paths in your .dna file too, if your ExternalLibrary
depends on other assemblies.
All of this becomes a bit tricky because .NET is not so enthusiastic
to have you load assemblies from various different locations.

Regards,
Govert

[Lothy]

Hi Govert,

that was a quick reply, thanks!
I need the ExcelDna.Integration.dll as reference to my libary to get
the calling Excel-object for further statements.
The problem is, the project is not only an add-in project, it has WPF
& database access as well. The static method in my libary selects a
single value from a collection. This collection is preselected from a
database at the first time the method is called, then the value is
fetched via LINQ-query and returned. The collection will be alive
until Excel gets closed and the dll will be unloaded. But all these
database handling comes from another dll with Entity Framework to
handle all the database funcionality. That's why I can't move the dna-
dll (referenced in the DNA-file) to another place.
If I can set up an absolute path in the dna-file would be good enough.
All the referenced DLL's are on the same place as the target dna-dll.
I'll check this all out, when I come up to send an update to our
customer (hopefully not tomorrow :-)). For now everything is done.

Thanks for your help.

Cheers
Gerhard

[Govert van Drimmelen]

Hi Gerhard,

You should reference ExcelDna.Integration.dll from your project, but
not redistribute it with your add-in.
It will work fine at runtime without the file there, and will cause
trouble later on if you do keep the separate file too. The easiest is
to mark the reference to ExcelDna.Integration as "Copy Local: False"
in your project properties.

If you have problems with the paths, you can also experiment with the
deprecated AppDomain.AppendPrivatePath, or handling the
AppDomain.AssemblyResolve events yourself.

Regards,
Govert

[Lothy]

Hi Govert,

> You should reference ExcelDna.Integration.dll from your project, but
> not redistribute it with your add-in.
> It will work fine at runtime without the file there, and will cause
> trouble later on if you do keep the separate file too. The easiest is
> to mark the reference to ExcelDna.Integration as "Copy Local: False"
> in your project properties.

I need the ExcelDna.Integration.dll within my program-folder because
in my dll I'm
I use a statement

var m_excel = ExcelDnaUtil.Application;

I need the calling Excel-Instance for further statements in my static
function.

That's why I have to redistribute it. Or is there an other way to do
this?

But it works fine, no problems with having the xll and the
ExcelDna.Integration.dll
in the same folder.

Cheers
Gerhard

[Govert van Drimmelen]

Hi Gerhard,

We need to distinguish the situation when compiling your .dll and when
running the add-in.

1. To call ExcelDnaUtil.Application in your code, you need to
reference ExcelDna.Integration.dll when compiling. This is correct,
but does _not_ mean that you have to redistribute it.

2. You don't need the ExcelDna.Integration.dll file when running your
add-in in Excel. A copy is embedded inside the .xll file, and will be
found at runtime. By setting "Copy Loca: False" in the reference to
ExcelDna.Integration you prevent it from being copied to the output
directory. This is what you want.

3. It might work now, but may cause trouble later when you use more of
the Excel-DNA features. If you have another copy of
ExcelDna.Integration.dll present when running (in the output directory
or in your add-in distribution) that copy will be loaded _in addition_
to the embedded copy. The presence of two loaded copies of the
assembly means that the Excel-DNA runtime can get confused about the
types. I don't yet know how to either prevent .NET from loading the
external one or to only load the external one. I hope to remove this
confusion in future.

So the 'other way' to do this is to reference the assembly when you
are compiling, but not redistribute the .dll. Everything should work
well if you do this.

Regards,
Govert

[Govert van Drimmelen]

Hi Gerhard,

You should never deploy ExcelDna.Integration.dll under any name. The
reference to it in your project cannot be under another name (the .xll
loads it from resources by name), so you should never rename the file
that you reference. You should mark the reference to it as "Copy
Local=false" in your project to prevent it being copied to your output
directory.

If you have not run the ExcelDnaPack packing tool, then you can rename
the ExcelDna.xll to any other name, and need to rename the .dna file
to match. The .xll will load the .dna file by name.

If you have run the packing tool, you can rename the packed .xll file
to any other name.

If you have problems running your add-in without the
ExcelDna.Integration.dll file, you most likely have mismatched
versions of the ExcelDna.Integration.dll and the ExcelDna.xll file.
Make very sure that the version you reference is matched by the .xll
version you are using, and the ExcelDnaPack.exe version.

After you've checked this, if your add-in is still problematic, please
write back and I can suggest a more systematic investigation.

Regards,
Govert

On Mar 3, 7:24 pm, Lothy <lo...@gmx.de> wrote:
> Hi Govert,
>

> it seems there is a problem sometime because of the deployed
> Integration.dll.
> I just deleted it, but than it the add-in doesn't work anymore.
> I think the problem is, that I've renamed the XLL file to something more
> convenient for our company.
> My imagination now is, that I have to rename the integration.dll as well,
> before I put a reference on it.
> Is that the piece of cake?
> If yes, please put it in your documentation. I think lots of the newbies
> will be thankful.
>
> Cheers
> Gerhard

[Naju Mancheril]

Hi Lothy,

(1) What is the name of your C# addin project? It should be of the form NNN.csproj.

(2) Let's suppose it is MyDna.csproj. The project references for NNN.csproj should include ExcelDna.Integration and ExcelDna.Loader. Here are the properties for these references. You can access these by clicking the reference and checking the Properties window.

Copy Local=False

Embed Interop Types=False

Your code should still compile since you still have the reference. However, your bin\Debug\ directory will no longer contain ExcelDna.Integration.dll and ExcelDna.Loader.dll. [This is OK! You don't need these .dll files in your bin\Debug\ directory. They are, in fact, "packed" into the MyDna.xll file. They will be unpacked and loaded at runtime, when the addin is run.]

When you deploy your addin, please deploy

MyDna.xll

MyDna.dna

MyDna.dll (this is the compiled from your C# project)

Thanks,
Naju

[Govert van Drimmelen]

Hi,

The ExcelDna.Integration.dll file must never be renamed (even if you
rename the .xll and .dna files).
Then it will be loaded correctly from inside .xll file at runtime.

You should never reference or include or know about the existence of
ExcelDna.Loader.dll.

-Govert

On Mar 4, 8:15 pm, Naju Mancheril <naju.manche...@gmail.com> wrote:
> Hi Lothy,
>
> (1) What is the name of your C# addin project? It should be of the form
> NNN.csproj.
>
> (2) Let's suppose it is MyDna.csproj. The project references for NNN.csproj
> should include ExcelDna.Integration and ExcelDna.Loader. Here are the
> properties for these references. You can access these by clicking the
> reference and checking the Properties window.
>
> Copy Local=False
> Embed Interop Types=False
>
> Your code should still compile since you still have the reference. However,
> your bin\Debug\ directory will no longer contain ExcelDna.Integration.dll

> and ExcelDna.Loader.dll. [*This is OK! You don't need these .dll files in

> your bin\Debug\ directory. They are, in fact, "packed" into the MyDna.xll

> file. They will be unpacked and loaded at runtime, when the addin is run.*]

[Stanislav]

Hi, Govert.

I would like to know is it possible to sign XLL addin to prevent security issues on client side?

понедельник, 4 марта 2013 г., 21:33:06 UTC+3 пользователь Govert van Drimmelen написал:

[Govert van Drimmelen]

Yes - you would use the SignTool utility to do this: https://msdn.microsoft.com/en-us/library/8s9b9yaz(v=vs.110).aspx

-Govert