Developing custom secure Excel add-ins

[Bliksem]

Hi all

I must develop custom Excel add-ins for clients. These need to be secure and
speed of execution is often a requirement. VBA is thus not always an option
to use. I want to create XLL files but I read somewhere this is not really
the way forward.

So, what development platform should I use to develop Excel add-ins?

Thanks

[Anne Troy]

Create COM add-ins using Visual Basic.

http://msdn.microsoft.com/library/de.../comaddins.asp
*******************
~Anne Troy

www.OfficeArticles.com
www.MyExpertsOnline.com


"Bliksem" <[email protected]> wrote in message
news:[email protected]...
> Hi all
>
> I must develop custom Excel add-ins for clients. These need to be secure
and
> speed of execution is often a requirement. VBA is thus not always an
option
> to use. I want to create XLL files but I read somewhere this is not really
> the way forward.
>
> So, what development platform should I use to develop Excel add-ins?
>
> Thanks
>

[Chip Pearson]

If you have the Developer's Edition of Excel, or Visual Basic 6,
you can write a COM Add-In, which is essentially a DLL file. If
you are using Excel 2003 and have Visual Studio 2003, you can
write a VSTO (Visual Studio For Office) project linked to your
workbook.



--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com


"Bliksem" <[email protected]> wrote in message
news:[email protected]...
> Hi all
>
> I must develop custom Excel add-ins for clients. These need to
> be secure and
> speed of execution is often a requirement. VBA is thus not
> always an option
> to use. I want to create XLL files but I read somewhere this is
> not really
> the way forward.
>
> So, what development platform should I use to develop Excel
> add-ins?
>
> Thanks
>

[Bliksem]

Thank you

"Chip Pearson" wrote:

> If you have the Developer's Edition of Excel, or Visual Basic 6,
> you can write a COM Add-In, which is essentially a DLL file. If
> you are using Excel 2003 and have Visual Studio 2003, you can
> write a VSTO (Visual Studio For Office) project linked to your
> workbook.
>
>
>
> --
> Cordially,
> Chip Pearson
> Microsoft MVP - Excel
> Pearson Software Consulting, LLC
> www.cpearson.com
>
>
> "Bliksem" <[email protected]> wrote in message
> news:[email protected]...
> > Hi all
> >
> > I must develop custom Excel add-ins for clients. These need to
> > be secure and
> > speed of execution is often a requirement. VBA is thus not
> > always an option
> > to use. I want to create XLL files but I read somewhere this is
> > not really
> > the way forward.
> >
> > So, what development platform should I use to develop Excel
> > add-ins?
> >
> > Thanks
> >
>
>
>

[DM Unseen]

COM addins are not always faster that VBA addins, especially resolving
references to excel object(like ranges) can actually be *slower*. Do
not expect to see much improvement there. internal processing could be
faster though

That said COM Addins are far more secure.

XLL addins are only useful for creating custom *worksheet* functions
that need to be compatible with Excel 2000 and earlier(2002 and later
can have COM Addin worksheet functions). XLL worksheet functions *are*
fast however. Creating XLL's is an art in itself since they are basicly
modified DLL libraries usually written in C/C++.

DM Unseen

[Bliksem]

Thanks for the answer. So, if I understand you correctly, if I want to
develop worksheet functions and speed is an issue, I should create XLLs, even
for Excel 2002/2003?

However, if speed is not an issue, COM add-ins are better?

"DM Unseen" wrote:

> COM addins are not always faster that VBA addins, especially resolving
> references to excel object(like ranges) can actually be *slower*. Do
> not expect to see much improvement there. internal processing could be
> faster though
>
> That said COM Addins are far more secure.
>
> XLL addins are only useful for creating custom *worksheet* functions
> that need to be compatible with Excel 2000 and earlier(2002 and later
> can have COM Addin worksheet functions). XLL worksheet functions *are*
> fast however. Creating XLL's is an art in itself since they are basicly
> modified DLL libraries usually written in C/C++.
>
> DM Unseen
>
>

[DM Unseen]

>Thanks for the answer. So, if I understand you correctly, if I want to
>develop worksheet functions and speed is an issue, I should create XLLs, even
>for Excel 2002/2003?

yes( although maybe asking someone to develop them for you would be a
better option, this knowledge is rapidly fading from the XL community


>However, if speed is not an issue, COM add-ins are better?

Yes

Dm unseen

[Bliksem]

OK. So, if developing XLLs are fading from the radar screen, and speed is an
issue, what development platform should one use to create worksheet function
add-ins?

Thanks


"DM Unseen" wrote:

> >Thanks for the answer. So, if I understand you correctly, if I want to
> >develop worksheet functions and speed is an issue, I should create XLLs, even
> >for Excel 2002/2003?
>
> yes( although maybe asking someone to develop them for you would be a
> better option, this knowledge is rapidly fading from the XL community
>
>
> >However, if speed is not an issue, COM add-ins are better?
>
> Yes
>
> Dm unseen
>
>

[DM Unseen]

If XLL is no option, COM will do, as will VBA for that matter.

I would suggest start prototyping with VBA and look how fast it is. COM
will not do a lot better unless some internal calculations can be
optimized. This depends on the type of calcuation. VBA can be protected
from endusers, just not from XL pro's.
To prevent code misuse you can scramble your VBA code, this will really
deter code stealers! Porting from VBA to VB COM addins is not that
difficult, so you can always do this when it is required.

DM Unseen

[Robert Kline]

On a slightly related topic, I'm new to .NET and want to expose some C++
classes for use within VBA in Excel. What is the best way to accomplish this
(COM, for example)?

"DM Unseen" wrote:

> If XLL is no option, COM will do, as will VBA for that matter.
>
> I would suggest start prototyping with VBA and look how fast it is. COM
> will not do a lot better unless some internal calculations can be
> optimized. This depends on the type of calcuation. VBA can be protected
> from endusers, just not from XL pro's.
> To prevent code misuse you can scramble your VBA code, this will really
> deter code stealers! Porting from VBA to VB COM addins is not that
> difficult, so you can always do this when it is required.
>
> DM Unseen
>
>

[DM Unseen]

if you have pure C++ classes you need to create a Type library that
exposes your C++ library as a COM/Automation library.

..NET classes can be used within VB(A) by generating a COM wrapper for
them. This can be generated withen VS.NET.

DM Unseen