Step-by-Step : Accessing Exchange mailbox using Exchange MAPI/CDO and MFCMAPI

One of my customer updated that he downloaded the MFCMAPIat his Exchange Server 2010/2013, when he ran he noticed the following error – he wanted to access the exchange mailbox programmatically.

Then he noticed the following error as well:

To start with he needs Exchange MAPICDO, as Microsoft Exchange MAPI and CDO 1.2.1 provide access to these APIs. As you know starting with Exchange Server 2007-Exchange Server 2013 , neither the Messaging API (MAPI) client libraries nor CDO 1.2.1 are provided as a part of the base product (Exchange) installation. As a result, there is functionality missing that many applications depend on. He can downloaded the latest Exchange MAPICDO (March 2014) from here.

After installing it, he need to create MAPI profile programmatically using his custom MAPI application or make use of Dave’s blog posts for profile creation using MFCMAPI (added below):
– for Exchange 2010 mailbox
– for Exchange 2013 mailbox
– same profile to use Exchange 2013 & legacy Exchange versions 

On successful profile creation, he successfully logged to the mailboxes correctly, access the data without any problem.

Hope this helps.

C++/ATL Project throws error C2061: syntax error : identifier ‘_ATL_FUNC_INFO’

One of my customer reported that they created a ATL Project/MFC CDHtmlDialog based C++ application and they notice the following errors in afxdhtml.h (they created it using VS 2003).

afxdhtml.h(272) : error C2238: unexpected token(s) preceding ‘;’
afxdhtml.h(289) : error C2061: syntax error : identifier ‘_ATL_FUNC_INFO’
afxdhtml.h(290) : error C2061: syntax error : identifier ‘_ATL_FUNC_INFO’

I tried the code piece at my end locally and tested with latest visual studio – I failed to see the issue and it just works for me. Later I done further research on this and found the following:

The #include <afxdhtml.h> directive is placed in the stdafx.h pre-compiled header file before the "using namespace ATL;" directive, and the #define _ATL_NO_AUTOMATIC_NAMESPACE was given previously. Thus, the symbols in the header file which belong to the ATL namespace are not properly resolved. When adding a class from the MFC dialog class wizard, you are given the choice of several dialog base classes, most of which do not require the ATL namespace "using" directive. Thus, the wizard script in default.htm doesn’t make any attempt to ensure that the header file corresponding to the class name come after a using directive.

In Visual Studio 2005 and later versions, the problem doesn’t occur because all references to CComPtr are now prefixed with ::ATL::, alleviating the need to either direct “using namespace ATL;” or to define the macro to eliminate the automatic use of the ATL namespace. So I recommended them to try one of the following to move ahead:

• Remove the #define _ATL_NO_AUTOMATIC_NAMESPACE directive from the stdafx.h header, or
• Move the using namespace ATL; directive before the #include <afxdhtml.h>
• Upgrade to Visual Studio 2005 and above. Also make sure they’re fully patched with latest service pack/fixes.

MFC MAPI: How to view GAL entries

You can download the latest MFC MAPI utility to view GAL entries, which uses the Messaging API to provide access to MAPI stores through a graphical user interface.

Try the following steps:

1) Open MFC MAPI utility. Select Session menu and select “Logon and Display  Store table” ( I chosen for this session). It will ask you prompt the profile.

2) Select the profile. Once you select it, it will open the stores associated with it.

3) Select Address Book Menu and select "Open Default Directory” option

4) It will list out the GAL entries

5) If you select a GAL entry in the top pane, it will display its associated properties, tag, type, value etc in its below pane.

Visual Studio 2010 & New C++ and MFC features

I want to share some important new features of new Visual Studio 2010 for C++ development – Visual Studio 2010 presents huge benefits for C++ developers. From the ability to employ the new features offered by Windows 7 to the enhanced productivity features for working with large code bases, there is something new and improved for just about every C++ developer.

Specifically, Visual Studio 2010 enables a more modern programming model by adding core language features from the upcoming C++0x standard, and by overhauling the standard library to take advantage of the new language features. There are new parallel programming libraries and tools to simplify the creation of parallel programs. You’ll also find enhanced overall performance and developer productivity thanks to IntelliSense and code-understanding features that scale to large code bases. And you’ll benefit from the improved  performance of libraries and other features across design time, build time, compile time and link time.

Visual Studio 2010 migrates the build system to MSBuild to make it more customizable and to support native multi-targeting. And enhancements in the MFC library harness the power of new Windows 7 APIs, enabling you to write great Windows 7 applications.

You can read more related information from Sumit Kumar’s MSDN article. For more information regarding this, you can have a look at http://blogs.msdn.com/vcblog.

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.

Usage:

• 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 http://support.microsoft.com/support/.

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.