ExcelDNA add-in deploy via ClickOnce (using VSTO add-in)
1,131 views
Skip to first unread message
Paul Sullivan
Jan 3, 2012, 12:30:41 PM1/3/12
to Excel-DNA
Anyone know how I do the above. I have a ExcelDna add-in that I want
to compile as part of a VSTO add-in to get the benefits of ClickOnce
Deployment.
I have tried to Application.RegisterXLL during the Add-in startup as
advised on another post, but this was unsuccessful.
Help much appreciated
Thanks
Paul
to compile as part of a VSTO add-in to get the benefits of ClickOnce
Deployment.
I have tried to Application.RegisterXLL during the Add-in startup as
advised on another post, but this was unsuccessful.
Help much appreciated
Thanks
Paul
Govert van Drimmelen
Jan 4, 2012, 2:58:56 AM1/4/12
to <exceldna@googlegroups.com>
Hi Paul,
If you using VSTO only for the clickonce, I suspect you life will be easier with a roll-your-own updater, possibly implemented as a 'master' add-in that controls downloading and updating your real add-ins.
Anyway, the Application.RegisterXLL should work - what .NET version (there are sometimes security issues, especially loading from network)? Do you see anything interesting when running under the debugger?
An alternative is to call Application.AddIns.Add(...).Installed = true. But security issues are likely to be similar.
Otherwise write back, and I can have a closer look next week.
Regards,
Govert
> --
> You received this message because you are subscribed to the Google Groups "Excel-DNA" 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.
>
>
>
>
Lamon
Jan 12, 2012, 8:36:08 PM1/12/12
to Excel-DNA
Govert, Paul,
I came about the same issue. In my case the problem was a sort of
protection scheme from either Windows or a network protection system.
Anyway, when user where right-clicking on the xll file, there was an
extra button in the property dialog: "unblock". I then advise each
user to click this button. After that the add-in had no problem
registering the xll.
Hope that help,
Guy
On 4 jan, 02:58, Govert van Drimmelen <gov...@icon.co.za> wrote:
> Hi Paul,
>
> If you using VSTO only for the clickonce, I suspect you life will be easier with a roll-your-own updater, possibly implemented as a 'master' add-in that controls downloading and updating your real add-ins.
>
> Anyway, the Application.RegisterXLL should work - what .NET version (there are sometimes security issues, especially loading from network)? Do you see anything interesting when running under the debugger?
>
> An alternative is to call Application.AddIns.Add(...).Installed = true. But security issues are likely to be similar.
>
> Otherwise write back, and I can have a closer look next week.
>
> Regards,
> Govert
>
I came about the same issue. In my case the problem was a sort of
protection scheme from either Windows or a network protection system.
Anyway, when user where right-clicking on the xll file, there was an
extra button in the property dialog: "unblock". I then advise each
user to click this button. After that the add-in had no problem
registering the xll.
Hope that help,
Guy
On 4 jan, 02:58, Govert van Drimmelen <gov...@icon.co.za> wrote:
> Hi Paul,
>
> If you using VSTO only for the clickonce, I suspect you life will be easier with a roll-your-own updater, possibly implemented as a 'master' add-in that controls downloading and updating your real add-ins.
>
> Anyway, the Application.RegisterXLL should work - what .NET version (there are sometimes security issues, especially loading from network)? Do you see anything interesting when running under the debugger?
>
> An alternative is to call Application.AddIns.Add(...).Installed = true. But security issues are likely to be similar.
>
> Otherwise write back, and I can have a closer look next week.
>
> Regards,
> Govert
>
Paul Sullivan
Jan 15, 2012, 6:30:18 PM1/15/12
to Excel-DNA
Hi Govert,
I have tried this repeatedly with the same result "the exceldna.loader
assembly could not be loaded from the resource". I have stripped the
add-in down to the minimum in that all it does is attempt to
RegisterXll the xll (from the VSTO add-in Startup event). There are no
referenced dlls other than those created by default and it makes no
difference if I a) set all to copy local and b) include all of them as
references in the .dna file.
Do you have an example project you could send me where this has been
successfully implemented?
Thanks
Paul
On Jan 4, 7:58 am, Govert van Drimmelen <gov...@icon.co.za> wrote:
> Hi Paul,
>
> If you using VSTO only for the clickonce, I suspect you life will be easier with a roll-your-own updater, possibly implemented as a 'master' add-in that controls downloading and updating your real add-ins.
>
> Anyway, the Application.RegisterXLL should work - what .NET version (there are sometimes security issues, especially loading from network)? Do you see anything interesting when running under the debugger?
>
> An alternative is to call Application.AddIns.Add(...).Installed = true. But security issues are likely to be similar.
>
> Otherwise write back, and I can have a closer look next week.
>
> Regards,
> Govert
>
I have tried this repeatedly with the same result "the exceldna.loader
assembly could not be loaded from the resource". I have stripped the
add-in down to the minimum in that all it does is attempt to
RegisterXll the xll (from the VSTO add-in Startup event). There are no
referenced dlls other than those created by default and it makes no
difference if I a) set all to copy local and b) include all of them as
references in the .dna file.
Do you have an example project you could send me where this has been
successfully implemented?
Thanks
Paul
On Jan 4, 7:58 am, Govert van Drimmelen <gov...@icon.co.za> wrote:
> Hi Paul,
>
> If you using VSTO only for the clickonce, I suspect you life will be easier with a roll-your-own updater, possibly implemented as a 'master' add-in that controls downloading and updating your real add-ins.
>
> Anyway, the Application.RegisterXLL should work - what .NET version (there are sometimes security issues, especially loading from network)? Do you see anything interesting when running under the debugger?
>
> An alternative is to call Application.AddIns.Add(...).Installed = true. But security issues are likely to be similar.
>
> Otherwise write back, and I can have a closer look next week.
>
> Regards,
> Govert
>
Govert van Drimmelen
Jan 16, 2012, 2:47:46 AM1/16/12
to Excel-DNA
Hi Paul,
I have no experience with VSTO or ClickOnce. Reports from other Excel-
DNA users suggest they have been very happy to move away from VSTO.
VSTO runs in a .NET policy environment that I don't really understand,
and I have not found anyone who really does. This which might be
causing some of the problems you see. But I'm happy to have a look at
why your RegisterXLL call is failing.
You can mail me your skeleton project directly.
Regards,
Govert
I have no experience with VSTO or ClickOnce. Reports from other Excel-
DNA users suggest they have been very happy to move away from VSTO.
VSTO runs in a .NET policy environment that I don't really understand,
and I have not found anyone who really does. This which might be
causing some of the problems you see. But I'm happy to have a look at
why your RegisterXLL call is failing.
You can mail me your skeleton project directly.
Regards,
Govert
Govert van Drimmelen
Jan 16, 2012, 5:40:30 AM1/16/12
to Excel-DNA
Hi Paul,
I have another suggestion you might try.
I suspect the VSTO startup is a context in which you can't load the
add-in - it's too early and Excel is still in some start-up state.
Perhaps you can defer loading to some later event, or schedule the
loading with a call to Application.OnTime(Now, "loaderMacro")
where loaderMacro is some code in your VSTO that defines a macro (not
sure how this can be done).
As a small experiment, you might try to add a button or something to
your VSTo add-in, and see whether the RegisterXLL succeeds on the
button handler. This would help distinguish security-related issues
from problems realtaed to _when_ the RegisterXLL is called.
-Govert
I have another suggestion you might try.
I suspect the VSTO startup is a context in which you can't load the
add-in - it's too early and Excel is still in some start-up state.
Perhaps you can defer loading to some later event, or schedule the
loading with a call to Application.OnTime(Now, "loaderMacro")
where loaderMacro is some code in your VSTO that defines a macro (not
sure how this can be done).
As a small experiment, you might try to add a button or something to
your VSTo add-in, and see whether the RegisterXLL succeeds on the
button handler. This would help distinguish security-related issues
from problems realtaed to _when_ the RegisterXLL is called.
-Govert
Govert van Drimmelen
Jan 16, 2012, 4:12:26 PM1/16/12
to Excel-DNA
Just an update -
I have looked at this problem again. The error message, with code
0x8013150A (COR_E_SECURITY) is due to the interaction between the
Excel-DNA runtime loader and how VSTO uses the .NET Code Access
Security.
The problem should only occur if both the VSTO add-in and the Excel-
DNA add-in targets the .NET 2.0 runtime (which is also used in .NET
3.0 and 3.5). In this configuration the VSTO add-in cannot load the
Excel-DNA add-in successfully, either at start-up or from a ribbon or
event handler.
If either or both of the VSTO add-in and the Excel-DNA add-in
target .NET 4, everything should work fine.
----------
I don't know enough about how the .NET Code Access Security works to
address this further.
This previous thread, and the Microsoft support discussions linked to,
represent the current unresolved status:
http://groups.google.com/group/exceldna/browse_frm/thread/16cf3907473161e0.
-Govert
I have looked at this problem again. The error message, with code
0x8013150A (COR_E_SECURITY) is due to the interaction between the
Excel-DNA runtime loader and how VSTO uses the .NET Code Access
Security.
The problem should only occur if both the VSTO add-in and the Excel-
DNA add-in targets the .NET 2.0 runtime (which is also used in .NET
3.0 and 3.5). In this configuration the VSTO add-in cannot load the
Excel-DNA add-in successfully, either at start-up or from a ribbon or
event handler.
If either or both of the VSTO add-in and the Excel-DNA add-in
target .NET 4, everything should work fine.
----------
I don't know enough about how the .NET Code Access Security works to
address this further.
This previous thread, and the Microsoft support discussions linked to,
represent the current unresolved status:
http://groups.google.com/group/exceldna/browse_frm/thread/16cf3907473161e0.
-Govert
> I have another suggestion you might try.
> I suspect theVSTOstartup is a context in which you can't load the
> add-in - it's too early and Excel is still in some start-up state.
>
> Perhaps you can defer loading to some later event, or schedule the
> loading with a call to Application.OnTime(Now, "loaderMacro")
> where loaderMacro is some code in yourVSTOthat defines a macro (not
>
> Perhaps you can defer loading to some later event, or schedule the
> loading with a call to Application.OnTime(Now, "loaderMacro")
> sure how this can be done).
>
> As a small experiment, you might try to add a button or something to
> yourVSToadd-in, and see whether the RegisterXLL succeeds on the
>
> As a small experiment, you might try to add a button or something to
> button handler. This would help distinguish security-related issues
> from problems realtaed to _when_ the RegisterXLL is called.
>
> -Govert
>
> On Jan 16, 9:47 am, Govert van Drimmelen <gov...@icon.co.za> wrote:
>
>
>
>
>
>
>
> > Hi Paul,
>
> > I have no experience withVSTOor ClickOnce. Reports from other Excel-
> from problems realtaed to _when_ the RegisterXLL is called.
>
> -Govert
>
> On Jan 16, 9:47 am, Govert van Drimmelen <gov...@icon.co.za> wrote:
>
>
>
>
>
>
>
> > Hi Paul,
>
> > DNA users suggest they have been very happy to move away fromVSTO.
>
> >VSTOruns in a .NET policy environment that I don't really understand,
>
> > and I have not found anyone who really does. This which might be
> > causing some of the problems you see. But I'm happy to have a look at
> > why your RegisterXLL call is failing.
>
> > You can mail me your skeleton project directly.
>
> > Regards,
> > Govert
>
> > On Jan 16, 1:30 am, Paul Sullivan <paulsku...@gmail.com> wrote:
>
> > > Hi Govert,
>
> > > I have tried this repeatedly with the same result "the exceldna.loader
> > > assembly could not be loaded from the resource". I have stripped the
> > > add-in down to the minimum in that all it does is attempt to
> > > RegisterXll the xll (from theVSTOadd-in Startup event). There are no
> > causing some of the problems you see. But I'm happy to have a look at
> > why your RegisterXLL call is failing.
>
> > You can mail me your skeleton project directly.
>
> > Regards,
> > Govert
>
> > On Jan 16, 1:30 am, Paul Sullivan <paulsku...@gmail.com> wrote:
>
> > > Hi Govert,
>
> > > I have tried this repeatedly with the same result "the exceldna.loader
> > > assembly could not be loaded from the resource". I have stripped the
> > > add-in down to the minimum in that all it does is attempt to
> > > referenced dlls other than those created by default and it makes no
> > > difference if I a) set all to copy local and b) include all of them as
> > > references in the .dna file.
>
> > > Do you have an example project you could send me where this has been
> > > successfully implemented?
>
> > > Thanks
>
> > > Paul
>
> > > On Jan 4, 7:58 am, Govert van Drimmelen <gov...@icon.co.za> wrote:
>
> > > > Hi Paul,
>
> > > > If you usingVSTOonly for the clickonce, I suspect you life will be easier with a roll-your-own updater, possibly implemented as a 'master' add-in that controls downloading and updating your real add-ins.
> > > difference if I a) set all to copy local and b) include all of them as
> > > references in the .dna file.
>
> > > Do you have an example project you could send me where this has been
> > > successfully implemented?
>
> > > Thanks
>
> > > Paul
>
> > > On Jan 4, 7:58 am, Govert van Drimmelen <gov...@icon.co.za> wrote:
>
> > > > Hi Paul,
>
>
> > > > Anyway, the Application.RegisterXLL should work - what .NET version (there are sometimes security issues, especially loading from network)? Do you see anything interesting when running under the debugger?
>
> > > > An alternative is to call Application.AddIns.Add(...).Installed = true. But security issues are likely to be similar.
>
> > > > Otherwise write back, and I can have a closer look next week.
>
> > > > Regards,
> > > > Govert
>
> > > > On 04 Jan 2012, at 2:44, "Paul Sullivan" <paulsku...@gmail.com> wrote:
>
> > > > > Anyone know how I do the above. I have a ExcelDna add-in that I want
> > > > > to compile as part of aVSTOadd-in to get the benefits of ClickOnce
> > > > Anyway, the Application.RegisterXLL should work - what .NET version (there are sometimes security issues, especially loading from network)? Do you see anything interesting when running under the debugger?
>
> > > > An alternative is to call Application.AddIns.Add(...).Installed = true. But security issues are likely to be similar.
>
> > > > Otherwise write back, and I can have a closer look next week.
>
> > > > Regards,
> > > > Govert
>
> > > > On 04 Jan 2012, at 2:44, "Paul Sullivan" <paulsku...@gmail.com> wrote:
>
> > > > > Anyone know how I do the above. I have a ExcelDna add-in that I want
Reply all
Reply to author
Forward
0 new messages