RegisterXLL from VSTO

Govert van Drimmelen

unread,

Jan 27, 2010, 6:33:03 AM1/27/10

to ExcelDna

I'm cross-posting from the CodePlex discussions:

Hi

Has anyone managed to use Application.RegisterXLL on an ExcelDna add-
in from within a VSTO add-in?

I've signed and code-signed everything that could possibly be signed
(incl. manifests)...next step is getting a Papal Bulla for the
DLLs! :-)

And yet, the first time the unmanaged ExcelDna C++ crosses into the
managed ExcelDna.Loader with

hr = pXlAddInType->InvokeMember_3(CComBSTR("Initialize"),...

I get the dreaded

That assembly does not allow partially trusted callers. (HRESULT
0x8013150A)

The singing certificate shows up in Excel's Distrust Center (as
trusted).

I granted FullTrust to the publisher certificate with the following

caspol.exe -q -machine -addgroup 1 -pub -cert "my.cer" FullTrust

But if I check, then I get the following

c:\>CasPol.exe -rsg ExcelDna.xll
...
WARNING: The assembly at VTB.QR.xll cannot be loaded. Caspol can make
a partial determination of what evidence would be
associated with this assembly. The results of the following
operation are not necessarily accurate or complete.
...the rest of the output says FullTrust...

Incidentally, after adding the following (signed) manifest to
ExcelDna, the XLL does not load into Excel stand-alone anymore (so
without VSTO). I guess this is the first problem I should solve,
right?

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

I appeal to the VSTO/manifest/religious experts out there, as I'm
running out of options, hope and faith altogether...desperate,
really :-)

Thanks very much in advance!

Masariello

unread,

Jan 27, 2010, 9:15:29 AM1/27/10

to ExcelDna

New finding...

Loading ExcelDna in the default appdomain created by VSTO solves
0x8013150A (partially trusted callers not allowed)
BUT
That also causes ExcelDna.xll.config to be ignored and I do need
what's in it to be added to the appdomain config.

Maybe there's a way to tell the VSTO loader to include it...?

This would seem to indicate that the problem is in the way the
ExcelDna appDomain is set up (koz the VSTO one is fine)

Masariello

unread,

Feb 1, 2010, 5:43:06 AM2/1/10

to ExcelDna

*** WARNING: PREVIOUS MESSAGE IS WRONG ***

Doing a RegisterXLL(someExcelDnaXLL) from the CurrentDomain of a VSTO
add-in somehow breaks the ExcelDna parameter marshalling for all the
ExcelDna XLL UDFs. I naively tested that finding only with a few
parameter-less UDFs

I wish I knew why that happens!

jds

unread,

Feb 1, 2010, 11:15:17 AM2/1/10

to ExcelDna

We do this, but I'm not sure our solution will work for you. We also
own the VSTO application so the loading of the config is unnecessary.
We just put our config sections in the one for the VSTO app domain.

Keys to loading this in our VSTO application:
1. The order of loading is backwards. Normally, you would see the XLL
load first and then the VSTO application. We changed the Initialize
to look for the app domain to load into. If it exists, it loads, if
not, it just returns.
2. Removed the XlLibraryUnload. We don't want to unload the
appdomain. We let the VSTO application do that.
3. The VSTO application references all of the assemblies we need. It
is responsible for doing what the loader would normally
4. We then call Application.RegisterXLL from within our vsto
addin_startup

For what it is worth, we have a very large number of excel functions
and excel commands with and without parameters that work great. If
you aren't able to manipulate the vsto project, you definitely will
have a harder time and will have trust issues.

Masariello

unread,

Feb 1, 2010, 11:14:26 AM2/1/10

to ExcelDna

I've changed ExcelDna to add the dynamic delegate types to the types
that implement the target methods and that has fixed the parameter
marshalling problem I was having when running ExcelDna in the VSTO
appDomain

So it works now. I can finally RegisterXll(excelDna) from a VSTO add-
in.

KevinT

unread,

Mar 31, 2010, 9:35:34 AM3/31/10

to ExcelDna

Hi Masariello

Could you elaborate on what you did to make this work - we are having
the same problem of not being able to pinvoke from ExcelDna
functions.

Govert - Is there any chance this could be pulled into the next v of
ExcelDna?

Thanks in advance...

Govert van Drimmelen

unread,

Mar 31, 2010, 10:02:47 AM3/31/10

to ExcelDna

Hi Kevin,

The dynamic types story that he talks of above was a red herring. The
issue has to do with CAS policy, the evidence attached to the
AppDomain as creation time and the evidence of the assembly.

By manipulating the Assembly and AppDomain evidence he found a way to
get the right evidence set for the new AppDomain. But I don't
understand the problem well enough to put a proper fix into ExcelDna.
This discussion explores the story in some depth:
http://social.msdn.microsoft.com/Forums/en-GB/vsto/thread/d4be121d-c83c-4e20-ab08-dc0a1d57e5ea?lc=1033&prof=required

Are you in the situation that when you load the add-in normally,
everything works fine, but if you load from VSTO you have this
problem? Do you have to use VSTO?

Anyway, if we can understand the discussion linked above, I can try to
get into it again, but it's not much fun.

Cheers,
Govert

Alessio Massaro

unread,

Apr 4, 2010, 4:07:50 PM4/4/10

to exce...@googlegroups.com

all quite correct

thanks for answering, Govert

I've brought the topic to a new CLR thread

--
You received this message because you are subscribed to the Google Groups "ExcelDna" group.
To post to this group, send email to exce...@googlegroups.com.
To unsubscribe from this group, send email to exceldna+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/exceldna?hl=en.

Reply all

Reply to author

Forward