Home > Archive > Visual Basic > October 2004 > VBA.NET
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| Is there such an animal as VBA.NET. I am looking at
writing an Excel application and planning on using
some .NET components. My worries are, in Excel I will be
using VBA to access .NET components and don't want to
deal with Interop Services. I want to stick with using
managed code and really don't know if there is a VBA.NET
animal
| |
|
|
<anonymous@discussions.microsoft.com> wrote in message
news:18c801c4bc4c$f2875bb0$a501280a@phx.gbl...
> Is there such an animal as VBA.NET. I am looking at
> writing an Excel application and planning on using
> some .NET components. My worries are, in Excel I will be
> using VBA to access .NET components and don't want to
> deal with Interop Services. I want to stick with using
> managed code and really don't know if there is a VBA.NET
> animal
No, not yet. And when 'managed automation' does happen, it will not be the
animal you are suspecting.
For now you will have to deal with Interop Services and there is no reason
not to. Excel in its present form is an ActiveX server. No matter what -
some conversion between managed and unmanaged code is going to take place.
Part of Microsoft's hype in selling .NET has been to stress the ability to
avoid "DLL Hell". It helps to sell .NET but it tends to cause some to
shy-away from proven technologies.
-ralph
| |
|
| I thought that wwas the whole point of office 2003??!
"anonymous@discussions.microsoft.com" wrote:
> Is there such an animal as VBA.NET. I am looking at
> writing an Excel application and planning on using
> some .NET components. My worries are, in Excel I will be
> using VBA to access .NET components and don't want to
> deal with Interop Services. I want to stick with using
> managed code and really don't know if there is a VBA.NET
> animal
>
|
|
|
|
|