Nutshell: Automation using # imports with Exchange Server environment is good or bad?

Automation using # imports ?

As you know, Automation (OLE Automation), the technology that allows you to take advantage of an existing program's functionality and incorporate it into your own applications. This technology can greatly simplify and speed up your development.

# imports:

In C/C++ preprocessor, we have a directive called "#imports" is available. Using this #import directive allows you to automatically "import" the type information contained in the component type library to your project.

As you know we can use the #import to do the automation(OLE Automation). The #import, a new directive that became available with Visual C++; it creates VC++ "smart pointers" from a specified type library. It is very powerful, but often not recommended because of reference- counting problems that typically occur when used with the Microsoft Office applications.

If you use Visual C++ (especially 5.0 or later), you can take advantage of its native Component Object Model (COM) support through the #import statement. The #import creates two header files that reconstruct the type library contents in C++ source code. The primary header file is similar to that produced by the Microsoft Interface Definition Language (MIDL) compiler, but with additional compiler-generated code and data.


  • Usually, the files generated have the same name as the component dynamic-link library (DLL) with the extensions .tlh and .tli.
  • Microsoft ActiveX Data Objects (ADO) type information is required, so you need to include it as well.
  • This directive is used to incorporate information from a type library.
  • The content of the type library is converted into C++ classes, mostly describing the COM interfaces.
  • Using this statement allows you to automatically add type information contained in a type library into your project.

Need to determine:

You must determine which of the dependency comments are not otherwise provided for by system headers and then provide an #import directive at some point before the #import directive of the dependent type library to resolve the errors.

Using in Exchange Server environment:

When we talk about how we can make use of # imports in our exchange environment, i found this wonderful article which gives reference(s) or code snippets how we can make use of Collaboration Data objects (CDO).

Note: When using the #import statement, make sure to import the ActiveX Data Objects type information before the Microsoft CDO for Windows 2000 type information.

Some important points to remember: 

  • The application that we're trying to automate stays in memory even after the program is finished. This may because if we have forgotten to release an acquired interface and we need to track it down.
  • If you are dedicated to using MFC's wrapper classes or Visual C++'s native COM support (#import), either you may still have to delve into the guts of IDispatch and COM Automation in order to work around common bugs and limitations with these frameworks.
  • If you're using #import, it is very likely you could be running into one of the reference-counting bugs associated with it.
  • Often times the bugs can be worked around, but usually it is preferred to use one of the other Automation methods.
  • #import doesn't work very well with the Office applications, because its type libraries and use are fairly complex.
  • Also, such reference counting problems are hard to track down because a lot of the interface-level COM calls are behind-the-scenes when using #import.

Some known issues to be aware of:

For more information, see the Knowledge Base article "#import Wrapper Methods May Cause Access Violation" (Q242527) or "Compiler Errors When You Use #import with XML" (Q269194). You can find Knowledge Base articles on the MSDN Library media or at

My take, yes, i do agree that even without making use of # imports we can do more. Take this simple example which doesn't uses the # imports directive, instead it just uses the C++ to build an automated console application straightly. So it's up to the programmer who wants to create their program or it depends on whether he wants to make use of # imports to take advantage of native Component object model or not.

Skip to main content