Outlook, .Net and Outlook Versions

[TC]

Hello,

I have been handed the task of porting a COM addin for Outlook written in
VB6 that is compatible with Outlook 2000 and later to .Net.

Consequently, I was wondering the following:

When building a COM addin for Outlook via .Net, is the .Net Interop
required?

I ask because I know that the .Net Interop is only functional with Office XP
and later.

The above said, is there a way to build a .Net COM compatible assembly that
will work with Outlook 2000 and later?

Regards,

TC

 

[Dave]

I ask because I know that the .Net Interop is only functional with Office XP and later.

Maybe for built-in support, but that is not nessecarily the case for all .NET components. You can write your library in .NET and
register it for COM interop so it will be visible via VBA, etc. This should work fine for all office application versions since
they are abstracted from the platform the component was written on (i.e. .NET, C++, etc.).

The above said, is there a way to build a .Net COM compatible assembly that will work with Outlook 2000 and later?

Use the GuidAttribute on your class to create a unique class id for your component. If your using VS.NET, you can use the "Create
GUID" option in the Tools menu, copy it, and paste it into your attribute constructor. If you do not specify a Guid, one will be
created for you (I think it will be different on every build, so I would hard-code it using the tool mentioned above).

In the properties dialog for your project go to Configuration Properties > Build and set Register for COM Interop to True. When the
project is built, VS.NET will register your COM object.

Note: In order to register the object you must sign your assembly using a key file generated from the sn.exe utility.

There are many resources on MSDN and other sites that will guide you if you need further assistance. Just search for COM Interop
and Strong Name Utility (SN).

 

[TC]

Hey Dave,

Cool.

To provide further granularity, I currently have a VB6 COM object with ALL
of the code in VB6. It uses the IDTExtensibility2 interface and I also trap
Outlook events within the VB6 COM object.

I have seen documentation that says the only way to trap certain events from
certain apps from within a .Net environment is via the Interop assembly
which is for XP and later. However, the documentation I've seen generally
refers to Word, Excel and PowerPoint.

That said, I'm concerned that I build a VS.Net assembly, etc. and then it
won't run properly with Outlook 2000.

Any thoughts or specific comments regarding Outlook?

Regards,

TC

 

[Helmut Obertanner]

Hello Dave,

when you want to develop with managed code wich is compatible for
Outlook2000, you have to build your own PIA's or use latebinding.

--
Freundliche Grüße / with regards

Helmut Obertanner
Technical Consultant

Softwaredevelopment
DATALOG Software AG | Zschokkestr. 36 | D-80687 Munich
web: www.datalog.de


.... and IT works!

 

[TC]

Hey Guys,

I'm particulary interested in the IDTExtensibility2 Interface.

Can this be implemented in C# or VB.Net when using Office 2000?

Regards,

TC

 

[Helmut Obertanner]

Hello TC,

yes it's fully supported and the VS Wizard creates the implementation for
you automatically.
The problems are the PIA' sto access the Outloko COM Object Modell.

--
Freundliche Grüße / with regards

Helmut Obertanner
Technical Consultant

Softwaredevelopment
DATALOG Software AG | Zschokkestr. 36 | D-80687 Munich
web: www.datalog.de


.... and IT works!

 

[Dave]

Interop never requires PIA's. It is suggested that you use them whenever available since your assemblies cannot be signed unless
the Interop assemblies your referencing are signed too. Also, PIA's are sometimes fine-tuned to either perform better or port-over
functions in a fashion which better suits programming on the .NET platform.

If your not signing your assembly (and you don't required it to be in the GAC), then you can make your own wrapper.

There is a command line utility you can use to make the Interop wrapper:

[VS.NET install directory]\SDK\v*\Bin\TlbImp.exe (Type Library Importer)

....or you can let VS.NET handle it for you:

Project > Add Reference > COM > [Select the library]

VS.NET will create a wrapper, unsigned, for your project to reference. It uses the utility mentioned above behind the scenes to
create it.

I've had much success automating Excel 2000 and 2003 using this method.

The extensibility interface that you need should be wrapped for you if you chose the appropriate type library (the library that
contains that interface) from the COM list when adding a reference to your project. You will not have to create it manually,
although that would be possible to.

Create a class, implement the said interface, and register it for COM as I've stated in a previous post on this thread and you
should be good to go.

 

[Helmut Obertanner]

Hello Dave,

yes, you're right the Visual Studio creates the unsigned PIA's automatically
for you behind the scenes, if you import an COM object where no PIA's in the
GAC.
However I prefere to create my PIA's for thos COM Objects by myself with the
TLBIMP tool and sign this PIA's, because if i want to expose my AddIn as COM
Object it needs a strong name.
And i can't create a strong named assembly if i have unsigned PIA's - right
?.
o.k. i can let VS sign the assemblies automatically.
But why create a PIA on every build ?

There are always more ways to success...

--
Freundliche Grüße / with regards

Helmut Obertanner
Technical Consultant

Softwaredevelopment
DATALOG Software AG | Zschokkestr. 36 | D-80687 Munich
web: www.datalog.de


.... and IT works!

Interop never requires PIA's. It is suggested that you use them whenever
available since your assemblies cannot be signed unless the Interop
assemblies your referencing are signed too. Also, PIA's are sometimes
fine-tuned to either perform better or port-over functions in a fashion
which better suits programming on the .NET platform.

If your not signing your assembly (and you don't required it to be in the
GAC), then you can make your own wrapper.

There is a command line utility you can use to make the Interop wrapper:

[VS.NET install directory]\SDK\v*\Bin\TlbImp.exe (Type Library
Importer)

...or you can let VS.NET handle it for you:

Project > Add Reference > COM > [Select the library]

VS.NET will create a wrapper, unsigned, for your project to reference. It
uses the utility mentioned above behind the scenes to create it.

I've had much success automating Excel 2000 and 2003 using this method.

The extensibility interface that you need should be wrapped for you if you
chose the appropriate type library (the library that contains that
interface) from the COM list when adding a reference to your project. You
will not have to create it manually, although that would be possible to.

Create a class, implement the said interface, and register it for COM as
I've stated in a previous post on this thread and you should be good to
go.

--
Dave Sexton
[email protected]
-----------------------------------------------------------------------

Hello TC,

yes it's fully supported and the VS Wizard creates the implementation for
you automatically.
The problems are the PIA' sto access the Outloko COM Object Modell.

--
Freundliche Grüße / with regards

Helmut Obertanner
Technical Consultant

Softwaredevelopment
DATALOG Software AG | Zschokkestr. 36 | D-80687 Munich
web: www.datalog.de


... and IT works!

 

[Dave]

You are corret, however, creating a PIA for someone elses software is impossible. PIA is just symantics meaning that the software
vendor has created, and signed, a .NET wrapper for their legacy software.

Your just wrapping it like I suggested, and signing it manually.

Whatever works

--
Dave Sexton
[email protected]
-----------------------------------------------------------------------

Hello Dave,

yes, you're right the Visual Studio creates the unsigned PIA's automatically for you behind the scenes, if you import an COM
object where no PIA's in the GAC.
However I prefere to create my PIA's for thos COM Objects by myself with the TLBIMP tool and sign this PIA's, because if i want to
expose my AddIn as COM Object it needs a strong name.
And i can't create a strong named assembly if i have unsigned PIA's - right ?.
o.k. i can let VS sign the assemblies automatically.
But why create a PIA on every build ?

There are always more ways to success...

--
Freundliche Grüße / with regards

Helmut Obertanner
Technical Consultant

Softwaredevelopment
DATALOG Software AG | Zschokkestr. 36 | D-80687 Munich
web: www.datalog.de


... and IT works!

Interop never requires PIA's. It is suggested that you use them whenever available since your assemblies cannot be signed unless
the Interop assemblies your referencing are signed too. Also, PIA's are sometimes fine-tuned to either perform better or
port-over functions in a fashion which better suits programming on the .NET platform.

If your not signing your assembly (and you don't required it to be in the GAC), then you can make your own wrapper.

There is a command line utility you can use to make the Interop wrapper:

[VS.NET install directory]\SDK\v*\Bin\TlbImp.exe (Type Library Importer)

...or you can let VS.NET handle it for you:

Project > Add Reference > COM > [Select the library]

VS.NET will create a wrapper, unsigned, for your project to reference. It uses the utility mentioned above behind the scenes to
create it.

I've had much success automating Excel 2000 and 2003 using this method.

The extensibility interface that you need should be wrapped for you if you chose the appropriate type library (the library that
contains that interface) from the COM list when adding a reference to your project. You will not have to create it manually,
although that would be possible to.

Create a class, implement the said interface, and register it for COM as I've stated in a previous post on this thread and you
should be good to go.

--
Dave Sexton
[email protected]
-----------------------------------------------------------------------

Hello TC,

yes it's fully supported and the VS Wizard creates the implementation for you automatically.
The problems are the PIA' sto access the Outloko COM Object Modell.

--
Freundliche Grüße / with regards

Helmut Obertanner
Technical Consultant

Softwaredevelopment
DATALOG Software AG | Zschokkestr. 36 | D-80687 Munich
web: www.datalog.de


... and IT works!

Hey Guys,

I'm particulary interested in the IDTExtensibility2 Interface.

Can this be implemented in C# or VB.Net when using Office 2000?

Regards,

TC


Hello Dave,

when you want to develop with managed code wich is compatible for Outlook2000, you have to build your own PIA's or use
latebinding.

--
Freundliche Grüße / with regards

Helmut Obertanner
Technical Consultant

Softwaredevelopment
DATALOG Software AG | Zschokkestr. 36 | D-80687 Munich
web: www.datalog.de


... and IT works!

Hello,

I have been handed the task of porting a COM addin for Outlook written in VB6 that is compatible with Outlook 2000 and later
to .Net.

Consequently, I was wondering the following:

When building a COM addin for Outlook via .Net, is the .Net Interop required?

I ask because I know that the .Net Interop is only functional with Office XP and later.

The above said, is there a way to build a .Net COM compatible assembly that will work with Outlook 2000 and later?

Regards,

TC

 

[TC]

Hey Guys,

I guess my biggest concern is trapping application events from within the
..Net environment for Outlook 2000.

I know that some apps, such as PowerPoint for example, require the .Net
Interop assembly from MS, which is only compatible with Office XP and later,
to trap application events from within the .Net environment.

Therefore, I was wondering if I can get done what I need to get done using
..Net with Outlook 2000.

Regards,

TC

You are corret, however, creating a PIA for someone elses software is
impossible. PIA is just symantics meaning that the software vendor has
created, and signed, a .NET wrapper for their legacy software.

Your just wrapping it like I suggested, and signing it manually.

Whatever works

--
Dave Sexton
[email protected]
-----------------------------------------------------------------------

Hello Dave,

yes, you're right the Visual Studio creates the unsigned PIA's
automatically for you behind the scenes, if you import an COM object
where no PIA's in the GAC.
However I prefere to create my PIA's for thos COM Objects by myself with
the TLBIMP tool and sign this PIA's, because if i want to expose my AddIn
as COM Object it needs a strong name.
And i can't create a strong named assembly if i have unsigned PIA's -
right ?.
o.k. i can let VS sign the assemblies automatically.
But why create a PIA on every build ?

There are always more ways to success...

--
Freundliche Grüße / with regards

Helmut Obertanner
Technical Consultant

Softwaredevelopment
DATALOG Software AG | Zschokkestr. 36 | D-80687 Munich
web: www.datalog.de


... and IT works!

Interop never requires PIA's. It is suggested that you use them
whenever available since your assemblies cannot be signed unless the
Interop assemblies your referencing are signed too. Also, PIA's are
sometimes fine-tuned to either perform better or port-over functions in
a fashion which better suits programming on the .NET platform.

If your not signing your assembly (and you don't required it to be in
the GAC), then you can make your own wrapper.

There is a command line utility you can use to make the Interop wrapper:

[VS.NET install directory]\SDK\v*\Bin\TlbImp.exe (Type Library
Importer)

...or you can let VS.NET handle it for you:

Project > Add Reference > COM > [Select the library]

VS.NET will create a wrapper, unsigned, for your project to reference.
It uses the utility mentioned above behind the scenes to create it.

I've had much success automating Excel 2000 and 2003 using this method.

The extensibility interface that you need should be wrapped for you if
you chose the appropriate type library (the library that contains that
interface) from the COM list when adding a reference to your project.
You will not have to create it manually, although that would be possible
to.

Create a class, implement the said interface, and register it for COM as
I've stated in a previous post on this thread and you should be good to
go.

--
Dave Sexton
[email protected]
-----------------------------------------------------------------------
Hello TC,

yes it's fully supported and the VS Wizard creates the implementation
for you automatically.
The problems are the PIA' sto access the Outloko COM Object Modell.

--
Freundliche Grüße / with regards

Helmut Obertanner
Technical Consultant

Softwaredevelopment
DATALOG Software AG | Zschokkestr. 36 | D-80687 Munich
web: www.datalog.de


... and IT works!

Hey Guys,

I'm particulary interested in the IDTExtensibility2 Interface.

Can this be implemented in C# or VB.Net when using Office 2000?

Regards,

TC


Hello Dave,

when you want to develop with managed code wich is compatible for
Outlook2000, you have to build your own PIA's or use latebinding.

--
Freundliche Grüße / with regards

Helmut Obertanner
Technical Consultant

Softwaredevelopment
DATALOG Software AG | Zschokkestr. 36 | D-80687 Munich
web: www.datalog.de


... and IT works!

Hello,

I have been handed the task of porting a COM addin for Outlook
written in VB6 that is compatible with Outlook 2000 and later to
.Net.

Consequently, I was wondering the following:

When building a COM addin for Outlook via .Net, is the .Net Interop
required?

I ask because I know that the .Net Interop is only functional with
Office XP and later.

The above said, is there a way to build a .Net COM compatible
assembly that will work with Outlook 2000 and later?

Regards,

TC

 

[steve s]

Hi all,
I am trying to export my emails to a comma deliniated field, excel
spreadhseet or Access database - but when I use standard MS outlook export
function - there is no option to export any time or date fields - any one
know how to access these fields once exprted, or perhaps access the email
message header file that includes various time stamps I can extract as
necessary?

please reply to my email address if possible - (e-mail address removed)

 

[Dave]

You have posted into a DotNet Interop group. If you are looking for help on using Outlook, please post to an Office group or
Outlook group.