Outlook 2002 COM Add-ins in VS.Net RTM
"Adam Cogan"
RTM ?
Are Microsoft going to come out with an template add-in in VS.Net ?
- I know that Outlook is attempting to load a COM component.
- So I guess the answer is you could create a shim in VB6 that hooks
into a .NET assembly, and use THAT from Outlook.
Do you think we should just stick to VB6 for them?
Adam
-----------------------------------------------------------------------
Check out these hot utilities for .NET, VB, SQL Server and Access
developers.... www.ssw.com.au
* SSW Contactor - An Outlook COM add in
* SSW Data Renovator - Compare the differences between two data.mdb's
* SSW Upsize PRO! - Don't UPSIZE to SQL Server without it
* SSW SQL Script Wizard - A utility to run .sql files
* SSW Performance PRO! - Find out what is slow in your Access App
--------------------------------------------------------
Mike Timms
>Anyone heard anything about developing Outlook 2002 COM Add-ins in VS.Net
>RTM ?
You can do it, but it's not for the faint of heart :)
First there are several Microsoft references you might want to check out:
HOW TO: Build an Office COM Add-in With Visual Basic .NET (Q302896)
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q302896
HOW TO: Build an Office COM Add-in With Visual C# .NET (Q302901)
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q302901
Microsoft Office and .NET Interoperability
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnofftalk/h
tml/Office11012001.asp?frame=true
You'll notice that the sample Add-ins are only manipulating Office command
bars. The problem areas are mainly with trying to handle Outlook events:
1. The COM wrapper generated for the Outlook library has bugs related to
sinking Outlook events.
Currently, the wrapper needs to be rebuilt to fix them. I believe this
applies to all the Office object libraries. The generated wrapper classes
are also difficult to use. Microsoft really needs to come out with custom
wrappers for these libraries. Hopefully this will be very soon!!
2. COM objects allocated by the wrapper have to be specifically cleaned up
by the COM Add-in on disconnect, otherwise Outlook remains in memory or
crashes. I've isolated a number of these situations, but I still have
instances where Outlook remains in memory after shutdown.
The following threads have more detail on the issues:
Rebuilding Outlook COM wrapper to enable Outlook Events and Releasing COM
objects
http://groups.google.com/groups?threadm=O4llBWAlBHA.2432%40tkmsftngp02&prev=
/groups%3Fgroup%3Dmicrosoft.public.outlook.program_addins
http://groups.google.com/groups?threadm=e2vE0iAlBHA.1976%40tkmsftngp05&prev=
/groups%3Fgroup%3Dmicrosoft.public.dotnet.framework.interop
http://groups.google.com/groups?threadm=e1d085c2.0201021935.9ee4611%40postin
g.google.com&prev=/groups%3Fgroup%3Dmicrosoft.public.dotnet.framework.intero
p
Fixing ambiguous references to Outlook or Office methods under .Net
http://groups.google.com/groups?threadm=%232RmvaJlBHA.2084%40tkmsftngp04&pre
v=/groups%3Fgroup%3Dmicrosoft.public.dotnet.framework.interop
Accessing common properties of Outlook Items in .NET
http://groups.google.com/groups?threadm=uVh6AI7kBHA.2424%40tkmsftngp05&prev=
/groups%3Fnum%3D25%26group%3Dmicrosoft.public.dotnet.framework.interop%26sta
rt%3D25%26group%3Dmicrosoft.public.dotnet.framework.interop
.NET access to Extended MAPI and Redemption
http://groups.google.com/groups?threadm=e1d085c2.0201051834.c2371a4%40postin
g.google.com&prev=/groups%3Fgroup%3Dmicrosoft.public.dotnet.framework.intero
p
>Are Microsoft going to come out with an template add-in in VS.Net ?
There's a Shared Add-in project template under Other Projects\Extensibility
Projects\ in the new project wizard.
> - I know that Outlook is attempting to load a COM component.
Yes. The .NET assembly created by the template is exposed as a COM
component.
> - So I guess the answer is you could create a shim in VB6 that hooks
>into a .NET assembly, and use THAT from Outlook.
Yes, this is possible. However, if the .NET assembly has to access the
Outlook library then this doesn't buy you much.
>Do you think we should just stick to VB6 for them?
I wouldn't convert existing Add-ins or build new ones just yet unless there
is some .NET functionality that you really need to exploit. If the .NET
function is independent of Outlook, then expose the .NET code as COM and
call it from VB6, otherwise I'd wait for Microsoft to provide a proper .NET
Outlook library wrapper. The other consideration is that you will need to
distribute the .NET runtime (~8mb) along with your Add-in.
- Mike
""Adam Cogan"" <adam...@DONTsswSPAM.com.au> wrote in message
news:#3eny98qBHA.2072@tkmsftngp07...
"Adam Cogan"
Adam
* Keep up-to-date by attending the monthly meetings at the .Net User Group,
Sydney www.ssw.com.au/NETUG
""Adam Cogan"" <adam...@DONTsswSPAM.com.au> wrote in message
news:#3eny98qBHA.2072@tkmsftngp07...
Randy Byrne [MVP - Outlook]
Like Mike said in his post, I would stick with VB6 for the near term.
There are several issues that relate to Outlook 2000/2002 remaining in
memory, as well as garbage collection relating to Outlook objects Dim'ed
WithEvents.
Once those issues are solved, look for some sample code to be posted.
--
Randy Byrne, MVP - Outlook
http://www.microeye.com
Building Applications with Microsoft Outlook 2002 (MSPress - July 2001)
Building Applications with Microsoft Outlook 2000 (MSPress)
http://www.microeye.com/books
Micro Eye ZipOut 2002
http://www.microeye.com/zipout
""Adam Cogan"" <adam...@DONTsswSPAM.com.au> wrote in message
news:#DG5cuAtBHA.2492@tkmsftngp07...