Working example how to create a DLL using Visual C# 2008

[Eagl...@discussions.microsoft.com]

2003, 2007

I have a VBA Procedure that I would like to compile into a DLL which can be called from an Excel
macro so that I can protect the original source VBA code.

A working example would be great as that is the way I learn best.

Any thoughts, examples, plan of attack, links greatly appreciated.

TIA EagleOne

[Gord Dibben]

Try Chip Pearson's site.

http://www.cpearson.com/excel/CreatingCOMAddIn.aspx

Or

http://www.cpearson.com/excel/automationaddins.aspx

Gord Dibben MS Excel MVP

On Sat, 16 May 2009 19:47:11 -0400, Eagl...@discussions.microsoft.com
wrote:

[Eagl...@discussions.microsoft.com]

Thanks Gord.

The examples on Chip's site use VB 6. When I became interested in compiling VBA, I was told that VB
6 was/is on the way out. Therefore I got Visual Studio C+.

Do you have any thoughts on where I can get similar information (Chip's info) for C+? I have no
experience with any code other than VBA.

TIA EagleOne

[Dougaj4]

A couple of links you might find useful:

http://newtonexcelbach.wordpress.com/2008/09/02/linking-excel-to-c/

http://newtonexcelbach.wordpress.com/2008/09/03/linking-excel-to-c-2/

[Patrick Molloy]

you're incorrect, Chip also does a DLL in VB.NET which works perfectly
well - I just ran the code - and the DLL runs fine in Excel 2003 and in
Excel 2007

www.cpearson.com/Excel/creatingnetfunctionlib.aspx

<Eagl...@discussions.microsoft.com> wrote in message
news:f8nu051rk109f001q...@4ax.com...

[Eagl...@discussions.microsoft.com]

[Eagl...@discussions.microsoft.com]

Hello Pat,

I did see the reference to VB.NET but I do not have that? (Maybe VB.NET is a subset of C or
vice-versa)

[Eagl...@discussions.microsoft.com]

Thanks Doug

[Eagl...@discussions.microsoft.com]

What a great name-concept for your site!

[Patrick Molloy]

VB.NET is the NET language that VB6 will be replaced by.
You need to install MS Visual Studio 2005 or 2008

VB.Net, C# and C++ are supplied with this, but .NET allows many more
languages

<Eagl...@discussions.microsoft.com> wrote in message
news:en8015573n57j6j27...@4ax.com...

> Hello Pat,
>
> I did see the reference to VB.NET but I do not have that? (Maybe VB.NET
> is a subset of C or
> vice-versa)
>
>
> "Patrick Molloy" <patrick...@hotmail.com> wrote:
>
>>you're incorrect, Chip also does a DLL in VB.NET which works perfectly
>>well - I just ran the code - and the DLL runs fine in Excel 2003 and in
>>Excel 2007
>>
>>www.cpearson.com/Excel/creatingnetfunctionlib.aspx
>>
>>
>>
>>
>>
>>
>><Eagl...@discussions.microsoft.com> wrote in message

>>news:f8nu051rk109f001qp4c32u13v0fopa
s...@4ax.com...

[Chip Pearson]

>The examples on Chip's site use VB 6. When I became interested in compiling VBA, I was told that VB
>6 was/is on the way out. Therefore I got Visual Studio C+.

As noted, I also have VB.NET examples of an automation add-in (NET
ClassLib project). Even though VB6 is on its way out (or already is
out, depending on who you ask), it still provides more and better
functionality than VBA ever will. (VBA, too, is on the way out. The
language hasn't been updated in nearly a decade. In the future, some
incarnation of NET is going to supplant everything.) If you don't
already have VB6 or don't have an MSDN subscription, obtaining VS6 may
be a challenge.

The nice thing about using the NET framework is that it doesn't really
matter what language you code in and that the functional requirements
of an application don't generally dictate much about which language to
use. If you're good in VBA and/or VB6, VB.NET is reasonably easy to
learn. If you're a C/C++ person, you could use C++ or C#. You can
even use COBOL if you're really nuts for it.

If you're going to be writing automation libraries, you can do that
with straight NET code, whichever language you prefer. For add-ins,
though, you'll probably want to use Visual Studio Tools For Office.
This is a separate product for Visual Studio 2003 and VS2005, but it
included integrated into VS2008 as part of the package. The real
problem when writing what are called "code behind" workbooks is that
if you have Excel 2007 installed on your system, you can create only
2007 code-behind applications. Even if you have both XL 2003 and 2007
installed, you can still create only 2007 projects due to the way
interoperability is handled. (I use a VM running Windows XP with
Office 2003 only if I need it.) Various press reports say, though,
that this limitation will be remedied in VS2010 or whatever comes
after VS2008.

If you are aiming to write commercial quality code-behind or add-ins
for Office using NET, I would strongly recommend Add-In Express For
NET 2008 and Add-In Express For VSTO 2008
(http://www.add-in-express.com). These project prototypes and their
attendant assemblies make writing NET for Office much simpler, and
extend what is possible using NET/Office alone. It also overcomes the
2003/2007 interoperability problems. AIX can also automatically create
a setup/deployment package that is much better than Microsoft's. AIX
also supports creating XLL add-ins on the new Office 12 standard.

Cordially,
Chip Pearson
Microsoft Most Valuable Professional
Excel Product Group, 1998 - 2009
Pearson Software Consulting, LLC
www.cpearson.com
(email on web site)

On Sat, 16 May 2009 20:44:25 -0400, Eagl...@discussions.microsoft.com
wrote:

[Eagl...@discussions.microsoft.com]

Chip,

With others guidance, including you, and a ton of time, I have been able to accomplish many
meaningful VBA projects.

That said, I have paid the time-price of not having any formal coding training. My point, I do not
know the relationship(s) of of C++ to VB.NET.

Bottom line, it appears to me that I should learn VB.NET. At this point, my only interest in C, C+
C++ is that it is a means to an end of creating DLL files to be called from VBA.

Frankly, I do not know the "+'s" or "-'s" of creating Code-behind vs Com Addins. Also, I do not
have the perspective to appreciate if I need to use C++ or just VB.NET.

Therefore, my "only" goal is to create relatively-secure-original-source-code DLL's which will
work/function on both Excel 2003 and 2007. Also, my lack of code-perspective, inhibits me to
understand if all of the information that you have made available is enough to hande my goal.

My plans were to begin today utilizing the information you have provided to create my DLLs.

Do I need both: Add-In Express For NET 2008 and Add-In Express For VSTO 2008?

You have no idea how appreciative I am for you and other MVP's to take time and transfer knowledge.

EagleOne

[Patrick Molloy]

IMHO if you want to create a library of functions just for Excel, then use
VB.NET
These are all programming languages, and they all have their merits.
As Chip says, its easier to get to grips with if you're already somewhat
familiar with VB/VBA and once a DLL is compiled, its machine code, so the
application used isn't really relevant anymore.
I used Chip's VB.NET for creating my first COM ...thanks Chip ! -- and I
simply typed his code, and followed his example exactly, using Visual Studio
2008. The DLL i compiled worked for Excel 2003 and Excel 2007 as well, so
that suited my needs perfectly

regards
Patrick

<Eagl...@discussions.microsoft.com> wrote in message
news:grh215l101047pf2m...@4ax.com...

[Eagl...@discussions.microsoft.com]

Pat,

There is a part of this loop I cannot grasp.

I now have C++ and have successfully compiled some Math-example program written in C++ into a DLL
which can be called by VBA in Excel. So far so good!

What is missing is what I want to accomplish which is protect my current VBA code.

What steps do I have to take to be able to drop my VBA (Excel) code into a C++ via Win32 Console
Application Project and then ending up with an Com Addin of a DLL?

As I see it:
Plan A Plan B
1) have VBA code (Excel) 1) VBA code
2) Possible save that code as a .xla file 2) Drop into VB.NET and/or C++
3) Compile into DLL (With what? and how?) 3) Compile into a DLL
4) Call DLL from Excel VBA 4) Call DLL from Excel VBA

EagleOne

[ezt]

Hey Patrick-
I tried using Chip's example (MathForExcel) in VS 2008 EXPRESS. Apparently
some of the code is no longer support in the format given (e.g. Public
Property Get Sums() As mathForExcel.Sums....... get is supposed to now be a
seperate instruction. I have tried other example DLL code from other
sources, an I cannot get anything to generate something that will show up in
Tolls References or Tools Add-ins so that I can use it from within the Excel
VBE.

I want to put together a really simple call from Excel VBE (a .xla) to a
simple (for now) DLL.... even something as simple as just a msgbox would be
enough to get me started.

I have spent days pouring thru old material that references VS 2005 and 2005
express etc, which seems to have changed drastically with the 2008 release
and now those "instructions/examples" appear to have steps that I cannot
figure out how to achieve (e.g. VS 2008 Express, you can create a Class
Library but you cannot Publish it (just Build it). Help would be much
appreciated. PS this forum has been much more helpful than any of the Visual
Studio help docs or forums.

thanks,
ezt

[Patrick Molloy]

I used Chip's code ... here's working code that I used initially in a module
named
Multiplication.vb

As you'll see, i don't need most of the references. for mire functionality
you may have to,

This compiled fine and runs OK in both Excel 2007 and 2003

Option Explicit On
Option Compare Text
Option Strict Off
Imports XL = Excel
Imports OFC = Microsoft.Office
Imports System
Imports System.Runtime.InteropServices
Imports Microsoft.Win32
<ClassInterface(ClassInterfaceType.AutoDual), ComVisible(True)> _
Public Class Multiplication
Public Function MultiplyBy2(ByVal D As Double) As Double
Return D * 2
End Function

Public Function MultiplyBy4(ByVal D As Double) As Double
Return D * 4
End Function

Public Function MultiplyBy3(ByVal D As Double) As Double
Return D * 3
End Function
<ComRegisterFunctionAttribute()> _
Public Shared Sub RegisterFunction(ByVal type As Type)
Registry.ClassesRoot.CreateSubKey(GetSubkeyName(type))
End Sub
<ComUnregisterFunctionAttribute()> _
Public Shared Sub UnRegisterFunction(ByVal type As Type)
Registry.ClassesRoot.DeleteSubKey(GetSubkeyName(type))
End Sub
Private Shared Function GetSubkeyName(ByVal type As Type)
Dim S As New System.Text.StringBuilder()
S.Append("CLSID\{")
S.Append(type.GUID.ToString().ToUpper())
S.Append("}\Programmable")
Return S.ToString()
End Function

End Class

"ezt" <e...@discussions.microsoft.com> wrote in message
news:59837D71-0507-4125...@microsoft.com...