Most people using Address Object in Windows use the COM Object version of Address Object, named AddrObj.dll. But did you know that we also distribute a standard Windows dll version of Address Object? Look in your Address Object folder (C:\Program Files\Melissa DATA\COM Objects\AddrObj) and you will see mdAddr.dll. Visual Studio has built in support for COM Objects that makes them easy to use, but if you want to bypass the COM interface and are prepared for some extra work, keep reading.

Invoking the standard dll version of Address Object is fairly straight-forward in C++ with mdAddr.h and mdAddr.lic provided for you. In C# and VB.NET, this process is slightly more complicated. The following code samples are written in C#.

We will use the DllImport Attribute in System.Runtime.InteropServices to gain direct access to mdAddr.dll. We must specify every method in Address Object that we want to use with a variable in the following format:

[DllImport("mdAddr.dll", CharSet = CharSet.Ansi)]
static private extern IntPtr mdAddrCreate();
[DllImport("mdAddr.dll", CharSet = CharSet.Ansi)]
static private extern int mdAddrInitializeDataFiles(IntPtr mdAddrObj);
[DllImport("mdAddr.dll", CharSet = CharSet.Ansi)]
static private extern void mdAddrSetAddress(IntPtr mdAddrObj, string Address);
[DllImport("mdAddr.dll", CharSet = CharSet.Ansi)]
static private extern IntPtr mdAddrGetAddress(IntPtr mdAddrObj);

These methods are only a few methods that must be implemented. You can see every method contained in mdAddr.dll by looking at mdAddr.h in the “C version of interface” section. After we have mapped all the methods avaliable in Address Object, we can go ahead and invoke them.

First, we start by creating a new instance of Address Object and store the pointer to that instance.

private IntPtr m_addrObj = mdAddrCreate();

Then, we can use that pointer to call Address Object methods on that instance.

int result = mdAddrInitializeDataFiles(m_addrObj);
mdAddrSetAddress(m_addrObj, “22382 Avendia Empresa”);
string Address = Marshal.PtrToStringAnsi(mdAddrGetAddress(m_addrObj));

Mixing managed (.NET) and unmanaged (mdAddr.dll) code is always a tricky topic. Here are some tips about areas we have to pay attention to:

Address Object uses the Ansi character set, while many versions of Windows (Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista) use Unicode. So, we must specify that strings passed to mdAddr.dll are in ANSI format with “CharSet = CharSet.Ansi” inside the DllImport attribute.

Notice that we use a int return type for mdAddrInitializeDataFiles, but an IntPtr return type for mdAddrGetAddress, even though we expect a string. This is because unlike int, string in .NET is a class and the CLI will try to free the memory allocated for a class after it is done being used. However, since this string was created by mdAddr.dll and in unmanaged memory, trying to free this block of memory will cause memory corruption. Instead, we return a pointer (IntPtr) to that string so .NET will not try and free its memory. When we want to retrieve it, we use Marshal.PtrToStringAnsi to convert the unmanaged Ansi string into the default encoding (Unicode for Windows) and copy the data into managed memory. This way, we leave the unmanaged memory to mdAdd.dll as we should.

Absolutely there is a marked speed improvement when using Pinvokes over COM+ with .NET applications. The process would still use Interop but once .NET has created an Managed Assembly around a Standard DLL it's nearly as fast as a native .NET assembly. Actually because Address Object is over a million lines of optimized and compiled C++ code, the internal operations are faster than if Address Object was a native .NET assembly written in C#.

One tweak to make this faster is to prevent the stack walk by setting the [SuppressUnmanagedCodeSecurityAttribute()] within the C# Pinvoke marshalling Code.

It is really a matter of preference. For the non-novice .net user, it is likely the best way to utilize Address Object from managed code. It gives you more flexibility, a little more speed, you can strong name the dll, multiple versions can exist, there is no COM interop involved. However, with the COM, it is very easy to reference the object and there are no dll searching issues.