Is it advantageous to use .NET Framework DLL's in Access?

C

CDMAPoster

Most computers I support that have Access also have the latest .NET
Framework. Is there a downside to using functions from those DLL's
within Access?

James A. Fortune
(e-mail address removed)
 
N

Norman Yuan

If the .NET dll (developed by someone, not the DLL directly from .NET
framework, usually) exposed via COM Interop, yes, you can use it. Advantage
or not, it is really depends on your need: if you need some functionalities
that you can only find in that DLL as you know, then that is advantage; if
you can can do the functionalities in Access VBA easily, then the advantage
is gone, why add extra dependency to your application?.
 
D

David W. Fenton

(e-mail address removed) wrote in
:
Most computers I support that have Access also have the latest
.NET Framework. Is there a downside to using functions from those
DLL's within Access?

If it were even possible, what would the upside be?
 
J

John Mishefske

David said:
If it were even possible, what would the upside be?

Wrapping within a COM layer is easy. The advantage I've realized is the
ability to leverage .NET code in legacy Access apps as well as new
generation native .NET apps with minimal code changes. .NET makes things
like email and web access via proxy much easier and less error prone
than in the old days.

Updates are as easy as copying in new .DLLs (without a need to register
them) to client Access installs (provided COM compatibility is maintained).

Some resources for those interested:

A Beginner’s Guide to calling a .NET Library from Access
http://richnewman.wordpress.com/2007/08/25/a-beginner’s-guide-to-calling-a-net-library-from-access/
--- uses .NET library as a reference -- done by setting COM related
attributes of the .NET project

Exposing COM interfaces of a .NET class library for Late Binding
http://www.codeproject.com/KB/vb/MusaExposingCOM.aspx
--- uses .NET library via late-binding (CreateObject) - uses COM Class
template in .NET

Managed Add-Ins for Access 2007
http://msdn2.microsoft.com/en-us/library/aa902693.aspx

COM Interoperability in .NET Part 2 - Generating a Type Library (RegAsm.exe)
http://www.developerfusion.co.uk/show/2134/3/

The regasm.exe utility not only registers an assembly and it also
creates the
required type library file, as shown here:

regasm Server.dll /tlb:Netserver.tlb /codebase

and you can un-install with:

regasm /u Server.dll /tlb:Netserver.tlb /codebase


VB6 interoperability with .NET
-------------------------------

Interop Forms Toolkit 2.0
http://msdn2.microsoft.com/en-us/vbasic/aa701259.aspx


..NET to COM interoperability
-----------------------------

Microsoft .NET/COM Migration and Interoperability - Patterns and Practices
http://msdn2.microsoft.com/en-us/library/ms978506.aspx


--
John Mishefske, Microsoft MVP 2007 - 2009
UtterAccess Editor
Tigeronomy Software
web: http://www.tigeronomy.com
email: sales ~at~ tigeronomy.com
 
C

CDMAPoster

Most computers I support that have Access also have the latest .NET
Framework. Is there a downside to using functions from those DLL's
within Access?

James A. Fortune
(e-mail address removed)


Thanks for the answers. They were all helpful.

James A. Fortune
(e-mail address removed)
 
C

CDMAPoster

Wrapping within a COM layer is easy. The advantage I've realized is the
ability to leverage .NET code in legacy Access apps as well as new
generation native .NET apps with minimal code changes. .NET makes things
like email and web access via proxy much easier and less error prone
than in the old days.

Updates are as easy as copying in new .DLLs (without a need to register
them) to client Access installs (provided COM compatibility is maintained).

Some resources for those interested:

A Beginner’s Guide to calling a .NET Library from Accesshttp://richnewman.wordpress.com/2007/08/25/a-beginner%E2%80%99s-guide...
--- uses .NET library as a reference -- done by setting COM related
attributes of the .NET project

Exposing COM interfaces of a .NET class library for Late Bindinghttp://www.codeproject.com/KB/vb/MusaExposingCOM.aspx
--- uses .NET library via late-binding (CreateObject) - uses COM Class
template in .NET

Managed Add-Ins for Access 2007http://msdn2.microsoft.com/en-us/library/aa902693.aspx

COM Interoperability in .NET Part 2 - Generating a Type Library (RegAsm.exe)http://www.developerfusion.co.uk/show/2134/3/

The regasm.exe utility not only registers an assembly and it also
creates the
required type library file, as shown here:

regasm Server.dll /tlb:Netserver.tlb /codebase

and you can un-install with:

regasm /u Server.dll /tlb:Netserver.tlb /codebase

VB6 interoperability with .NET
-------------------------------

Interop Forms Toolkit 2.0http://msdn2.microsoft.com/en-us/vbasic/aa701259..aspx

.NET to COM interoperability
-----------------------------

Microsoft .NET/COM Migration and Interoperability - Patterns and Practiceshttp://msdn2.microsoft.com/en-us/library/ms978506.aspx

--
John Mishefske, Microsoft MVP 2007 - 2009
UtterAccess Editor
Tigeronomy Software
web:http://www.tigeronomy.com
email: sales ~at~ tigeronomy.com


Thanks again for the great links. That information will revolutionize
the way I code in Access eventually. I'll get the best of both worlds
both now (legacy app enhancement) and later (A2K7 AddIn's). I'm
excited about exploring the possibility of things like security, data
marshalling/marshaling, multithreading, multicore optimization and
maybe even n-tier using Access. Plus, if Access with .NET enhancement
is used to demonstrate a concept, the enhancements themselves will
likely need no conversion if the customer decides they want an
all .NET solution. The .NET Framework is looking a lot more useful to
me now than it did when I considered programming against it using
Visual Studio alone.

James A. Fortune
(e-mail address removed)
 
M

Mr.Frog.to.you

ADO.Net is really top notch IMO. Make yourself familiar with that and
you will find a lot of data push / pull / validation issues are easily
solved. Its really well thought out.

My 2 cents

The Frog
 
L

lyle fairfield

ADO.Net is really top notch IMO. Make yourself familiar with that and
you will find a lot of data push / pull / validation issues are easily
solved. Its really well thought out.

My 2 cents

The Frog

I think .Net, foisted upon us by the insidious marketing tactics of a
malevolent organization, is an inefficient, ineffective, controlling,
claptrap technology, inferior to its antecedents, slow and clumsy in
operation, and inordinately demanding of time and resources. .Net met one
and only one need, viz, the need of Microsoft to have something new to
sell.

My 2 cents
 
B

Builder

lyle said:
in


I think .Net, foisted upon us by the insidious marketing tactics of a
malevolent organization, is an inefficient, ineffective, controlling,
claptrap technology, inferior to its antecedents, slow and clumsy in
operation, and inordinately demanding of time and resources. .Net met
one and only one need, viz, the need of Microsoft to have something
new to sell.

My 2 cents

Funny how you don't mind making a living with the products of a "malevolent"
organization...
 
D

David W. Fenton

"(e-mail address removed)" <[email protected]>
wrote in
m:
ADO.Net is really top notch IMO. Make yourself familiar with that
and you will find a lot of data push / pull / validation issues
are easily solved. Its really well thought out.

Is that an Access-related comment?
 
D

David W. Fenton

I think .Net, foisted upon us by the insidious marketing tactics
of a malevolent organization, is an inefficient, ineffective,
controlling, claptrap technology, inferior to its antecedents,
slow and clumsy in operation, and inordinately demanding of time
and resources. .Net met one and only one need, viz, the need of
Microsoft to have something new to sell.

Wow! Lyle and I agree!

My problem with .Net, which I haven't touched nor will I ever, is
that when I look at the runtime that Windows Update keeps putting on
my machine and updating, it keeps breaking and littering my event
logs with its startup and configuration errors. If it can't be
completely transparent, then it's worthless.

Of course, on this particular PC, the JRE is broken, too, so it
seems to be endemic to this kind of runtime platform. And that's why
I just can't see it replacing real applications distributed in
OS-specific binary format.

For the web, sure, fine -- no problem.

But for desktop apps, forget it.
 
D

David W. Fenton

[Re: Lyle's criticism of .NET:]
Funny how you don't mind making a living with the products of a
"malevolent" organization...

Uh, back in the late 90s, with the release of VBA in Office, MS was
not "malevolent." It's only with the Enterprise push that came
around the time of the release of Office 2000 that MS has lost its
way, in my opinion. That's no reason for me to abandon what still
works for my clients.
 
C

CDMAPoster

I think .Net, foisted upon us by the insidious marketing tactics of a
malevolent organization, is an inefficient, ineffective, controlling,
claptrap technology, inferior to its antecedents, slow and clumsy in
operation, and inordinately demanding of time and resources. .Net met one
and only one need, viz, the need of Microsoft to have something new to
sell.

My 2 cents

--
lyle fairfield

- The man who told us that Canada wouldn't go there has now told us that
Canada will be the first to come back. How reassuring!

I can't even say that I disagree with your points Lyle. In a previous
post somewhere, I suggested that .NET was simply a means for Microsoft
bugs to escape into the wild :), so I'm not going into this with my
eyes closed. Yet a means to retrofit earlier versions of Access with
new capabilities is simply too compelling for me to ignore. I'm not
ruling out trying other technologies if .NET code turns out not to be
viable. Plus, I don't think that Microsoft is going to address
several of Access' weaker points, ever. The possibility of having a
RAD environment that uses Access enhanced by .NET needs to be tried
out though, IMO.

James A. Fortune
(e-mail address removed)
 
D

David W. Fenton

David W. Fenton wrote:
[re: .NET:]
For the web, sure, fine -- no problem.

But for desktop apps, forget it.

On the west coast it almost appears the desktop app is dead. The
web rules completely.

*yawn*

Yes, and thin clients will replace full-fledged computers sometime
in 1990 or so.

Or so they all said back then.

The web simply cannot beat the experience of a well-designed desktop
app precisely because of its statelessness.
 
L

lyle fairfield

The web simply cannot beat the experience of a well-designed desktop
app precisely because of its statelessness.

I agree, David and that's the beauty of an ADP. When connected to an
Internet enabled SQL-Server DB ADPs provide the best of both worlds.
Because ADPs are so tiny (without images) they can be downloaded quickly
and, provided the user has the required version of Access installed, they
fire-up instantly. In addition, this downloading procedure ensures the
application is always up-to-date.

You REALLY should try this.
 
C

CDMAPoster

Well said, I couldn't agree more.

Plus, I just hate OO programming anyway, for good reason...a from
everything I've seen, .NET and Java both force its use.

The best way I've heard it put is that OOP is basically a backwards
methodology:

http://www.stlport.org/resources/StepanovUSA.html

That's an interesting article. So your recommendation for a better
way to enhance existing and prior versions of Access is ...?

James A. Fortune
(e-mail address removed)

STAR HOTEL, SLEEP IN THE - To sleep in the open. -- Dictionary of
Australian Slang, Second Edition, Sidney J. Baker, 1943 (Price: Three
shillings & sixpence)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top