VBA code into DLL: Alternatives to using VB6

[intell1]

Dear all:

Following up on a previous post, I now know that to convert VBA source
to a dll I need to have either Office 2000 Developer OR VB 6.0.

Given that VB 6 is considered discontinued, I am reluctant to obtain a
copy (legally of cource) and commit to its use. So the question I pose
now is:

Given that I need to convert my code to a DLL (mainly for security
reasons), what is the preferred tool to use? Can this be accomplished
with the new .NET tools? What do all these high quality Office-based
applications use?

TIA,
Nikolas

 

[Cindy M -WordMVP-]

Hi Intell1,

Following up on a previous post, I now know that to convert VBA source
to a dll I need to have either Office 2000 Developer OR VB 6.0.

Given that VB 6 is considered discontinued, I am reluctant to obtain a
copy (legally of cource) and commit to its use. So the question I pose
now is:

Given that I need to convert my code to a DLL (mainly for security
reasons), what is the preferred tool to use? Can this be accomplished
with the new .NET tools? What do all these high quality Office-based
applications use?

You can use any development software than can create COM, ActiveX DLLs.
Delphi, Pascal, C++, whatever you prefer. You can also use .NET, but
- the user must have the .NET Framework installed
- you'd need to use all kinds of nasty little workarounds to get the
..NET thing to work in the COM environment (Shims, for example). It will
also be slower, having to go over the managed/unmanaged interface for
each COM call.

The prevailing opinion of many is, if you don't need to use .NET, don't.
COM is COM, so it makes more sense to create a COM Addin in a COM
environment. In this case VB6 is still perfectly legitimate. And as long
as COM apps and a COM environment exists (quite a few years, yet,
probably), you might as well continue to use VB6 to create COM Addins.

The day Windows and Office are no longer COM-based is the day VB6 will
become obsolete as a tool for developing Addins for the *new* versions.
But considering how long it takes for people and companies to migrate,
any COM tools you do create for "the general public" will probably still
be used for years to come.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or
reply in the newsgroup and not by e-mail

 

[Howard Kaikow]

VB .NET DLLs are not as secure as VB 6 DLLS in the sense that VB 6 DLLs
protect your code from prying eyes and VB .NET DLLs do not.

Not to mention, but I will anyway, VB .NET DLLS require the .NET Framework
to be installed, whilst VB 6 DLL, require only the VB 6 runtimes, which
are automatically installed on the newer OS and version of Office.

 

[OfficeHacker]

Hi,

I also prefer using VB6 to create ActiveX DLL for both performance and code
security. You can try your luck to get a used version from ebay or equivilent.

If this proves too difficult here's another alternative I have used in the
past when VB6 was not permissable:

Place the code you want to secure into an Access database and compile it
into an MDE. Then to a reference to the MDE file in the VBE of your Office
project. the reference, variable declarations and so forth work just like a
VB6 DLL code library. The VBA code is compiled and the source code is
removed. Go one step further and encapsulate your code into class modules to
make you code usage more 'object orientated'.

 

[intell1]

Hi,

...

Place the code you want to secure into an Access database and compile it
into an MDE. Then to a reference to the MDE file in the VBE of your Office
project. the reference, variable declarations and so forth work just like a
VB6 DLL code library. The VBA code is compiled and the source code is
removed. Go one step further and encapsulate your code into class modules to
make you code usage more 'object orientated'.

This is very interesting. Would you be kind enough to outline the
procedure for referencing the MDE file into Excel/VBA? I created a
sample MDB, a sample VBA Sub in it, saved it as MDE, went back to
my Excel/VBA project, and got stuck there, because I could not find
the way to reference the sample macro from within my Excel/VBA setup.

Any pointers sincerely appreciated.

Nikolas

 

[OfficeHacker]

Hi Nikolas,

Here's a simple example he can try.


Created an Access database and called it something meaningful. This will be
your function
library. I called mine lib.mdb.

Add a standard module (as opposed to a class module) and called it
basFunctions. Add the following
function to the module. Really you can add any functionality you require -
remember this is just
a simple example.


Public Function MilesToKm(ByVal km As Single) As Single
KmToMiles = km * 1.609
End Function

Save the module and close the VBE. Now we're going to compile the database.

1) Display the main Access window with the libary database open,
2) from the Tools menu choose 'Database Utilities' and then 'Make MDE file...'
3) The standard 'Save As' dialog will appear. Select where you want to save
the MDE file and click save.

Okay - you've now got two databases. The original which contains VBA code
and the MDE which is fully compiled and contains no VBA code.

Now open the database which needs to to reference the code libary.

1) Open the VBE
2) From the Tools menu select References
3) From the References dialog click Browse.
4) In the Add Reference (file open) dialog
a) From the Files of Type drop down select MDE Files
b) navigate to and select the MDE file you just saved.
c) Click Open
5) The reference to the mde will appear in the References list with a tick
6) Click OK to close the References dialog.

Add the following function to a standard module to test the Library

Sub TestLib()
MsgBox MilesToKm(20)
End Sub

Click in the function and press F5 to run it. A msgbox will apears stating
that 32.18 km to 20 miles.

Notes:
1) Always keep the original mdb code libary. The MDE cannot be decompiled to
reveal the original VBA source code.
2) The MDE can also include forms (a handy one is a progress bar). You
cannot call a form directly. Use a VBA function to load the form.
3) Provided you keep the MDE file in the same folder as the MDB that
references it, the reference wont be broken. Access has a set sequence of
paths it checks for the referenced file including the same folder as the mdb.
4) You can extrapolate this to have some complex or commonly used code
including class modules to make your projects more OOPS.
5) Check out Access Developer Handbook series by Ken Getz et al - they're an
excellent resource.

Good Luck

 

[Tabasco Ed]

Hi,

I also prefer using VB6 to create ActiveX DLL for both performance and code
security. You can try your luck to get a used version from ebay or equivilent.

VB5 will work just as well as VB6. You can get that on eBay
considerably cheaper than VB6. If you're willing to spend the money,
though, I'd go with VB6.