[AccessD] Converting Customers to VB.Net (was: Pollon Access2 007)

Hi Jim,

Do you mean/expect MS Office Automation is/would be a PITA within .NET?

The fact/my experience is that MS Office Automation is more smooth when
doing it from within .NET - especially using VB.NET as it allows to use late
binding very similar to VBA/VB6.

I have had experience porting a set of advanced MS Excel 2003 Add-ins to
VB.NET 2005: those add-ins started to put MS Excel down because of usage of
a lot of custom classes in them - porting to VB.NET was relatively
straightforward by using VSTO. Everything got working well. And no MS Excel
go down whatever advanced your VB.NET coding is...

And BTW you do not need to use VSTO for Automation - the only thing, which
is needed, is a set of Primary Interop Assemblies, which are freely
available AFAIK.

--
Shamil

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence
Sent: Tuesday, June 30, 2009 12:16 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Converting Customers to VB.Net (was: Pollon Access2
007)

Hi Rusty:

Tough decision...build a stand-alone database in .Net and forget office
automation or stick with a dying product to be able to provide that
integration? 

If only MS would build .Net into Office and provide a temp fix, upgrade or
conversion process. Now it is one or other.

Jim 

<<< snip >>>
 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4197 (20090629) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru