[AccessD] C# automation of office

Hi Mark --

As I noted previously optional parameters were supported in VB.Net since
first version of .NET Framework. There was no that much need in optional
parameters in C# as C# allows to have methods with the same name but with
different sets of parameters. I, e.g., do not feel as I need optional
parameters in C# - and that's only to support Automation when one may urge
for optional parameters to not type in C# all that long lists of
Type.Missing placeholders for optional parameters' lists.

A dot-net office add-in can be packed as one *.NET* DLL or as as many *.NET*
DLLs as you wish. In the latter case there will one entry COM callable
*.NET* DLL.
There could be several kinds of dot-net office add-ins (please see MSDN for
details) - I mentioned main add-in type - so called COM Add-in - and that
add-in is a usual .NET assembly but having additionally so called CCW (COM
Callable Wrapper)  for IDTExtensibility/IDTExtensibility2 + COM typelib
describing that CCW - all that stuff is registered on setup usual for COM
way - there exists a .NET utility regasm.exe, which registers *.NET* DLLs
COM interfaces and creates COM type library. And this is COM type library
created by RegAsm (and registered by regtlb - another utility), which is
referenced from COM (VBA) enabled office applications:
Excel/Word/Powerpoint....

Within our dba-VB's http://northwind.codeplex.com sample project there is
such a .NET COM callable DLL sample with sources. (Not COM Add-in just a COM
callable sample .NET class library).

I have been always using custom setups to install COM Add-ins (VB6 ones or
VB.NET/C# ones) - and I used to use my custom INNO-Setup scripts. 

You can see some info on calling supplied with CCW .NET DLLs from Excel here
http://richnewman.wordpress.com/2007/04/15/a-beginner%E2%80%99s-guide-to-cal
ling-a-net-library-from-excel/ 

All in all if you have a good experience with COM Add-ins and COM ActixeX
Dlls developed using VB6 then it shouldn't be an issue for you to develop
.NET COM Add-ins and classlibs exposed to COM and callable from COM
applications/VBA.

If you do not have such experience then this commercial tool could help:

Add-In Express 2009
http://www.add-in-express.com/add-in-net/index.php

Sorry, I can't write in more details on (.NET) COM Add-ins development as
this is a large topic - there are whole books dedicated to it...

There exists also VSTO (Visual Studio Tools for Office), which I didn't even
mention - and I have never used it in real life add-ins' development - there
was no need in its usage for me and for my customers...

Thank you.

--
Shamil


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark Simms
Sent: Sunday, January 31, 2010 6:13 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] C# automation of office

Very interesting and thanks much for the lesson.
(Wow, it took MSFT over 5 years to finally handle optional parameters
properly !?)

Final questions: deployment, referencing
When you deploy a dot-net Office add-in, is it a single COM DLL then ?
In other words, all the users need is the dot-net 3.0 framework installed.

Referencing to the DLL from the Excel/Word/Powerpoint instance: how is that
done ?
The regular add-in menu or a custom-install is required ?

> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
> Shamil Salakhetdinov
> Sent: Saturday, January 30, 2010 3:10 PM
> To: 'Access Developers discussion and problem solving'
> Subject: Re: [AccessD] C# automation of office
>
> Hi Mark,
>
> As JC noted you can use using statement - I usually use it this way:
>
> using xl = Microsoft.Office.Interop.Excel;
>
> or for MS Word
>
> using wd = Microsoft.Office.Interop.Word;
>
> and then
>
> xl.Application xlApp = new xl.Application(); xl.Workbook xlWB
> = xlApp.Workbooks.Add(XlWBATemplate.xlWBATWorksheet);
>
> etc.
>
> But even without using statement VS2008 intellisense does
> allow you to type code much quicker than VBA/VB6 IDE does.
>
> As for overheads of using Automation from within .NET
> applications - that could be neglected - I didn't test but it
> could be even running
> (considerably) quicker than VBA, which is interpreted p-code
> on runtime, and .NET assemblies are JIT compiled into native
> system machine commands, and .NET <-> COM communication was
> very well tuned in .NET framework...
>
> I'd also note that some of core Microsoft.Office.Interop
> classes can be inherited as base of your custom classes and
> you can build your own custom Automation model(s), and that
> could be practical as within most of the Automation tasks
> just a few Automation objects and methods are often used
> (Max, don't "kill" me if you read this - I'm not proposing to
> build one's own Automation models on top of
> Microsoft.Office.Interop I'm just noting that such an
> opportunity is natively supported by .NET)...
>
> Additionally in the coming VS2010 and .Net Framework/C# 4.0
> you will not need to write
>
> xlWS.SaveAs(strFileName,
>  Type.Missing, Type.Missing, Type.Missing, Type.Missing,
> Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing);
>
> you will just have to write
>
> xlWS.SaveAs(strFileName)
>
> as it's usually done in VB6/VBA, and in VB.NET this way of
> coding was available since the first versions of .NET Framework - 1.0.
>
> All in all Office Automation development in .NET is a way
> more quicker and comfortable, and smooth - I, e.g., have an
> experience when quite large set of MS Excel Automation
> standard and class modules, which screwed MX Excel
> 2003 VBA (stopped to run under it without any way to make it
> working - even export into text files and import back didn't
> work - GPF...) - that large set was converted into .NET COM
> add-in within a few days, and worked flawlessly sonce then...
>
> Thank you.
>
> --
> Shamil

<<< snip >>>
 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4822 (20100131) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru