Cosmin's Hooking testify

The fact that MAPI is not supported with .Net. Turns out, while was mentioned  several times, I’ve never devoted a topic to it. So here goes.

Here are the articles which outlines the official support policies for MAPI and .Net, from both the Exchange and Outlook perspectives:

Support policy for Microsoft Exchange APIs with the .NET Framework applications

Support policy for Outlook APIs that are used in the .NET Framework environment

A bit of history of this policy: When .Net was first announced, Developers were very excited, try every API supported and started figuring out how to invoke them from managed code.Were a series of KBs (never published) showing how to do pretty much everything with Simple MAPI, and had begun work developing a shim for Extended MAPI. But then the bugs started coming in. Are early adopters using MAPI and CDO 1.21 from .Net who were seeing strange error codes, memory leaks, and crashes. Investigating these, and eventually asked Microsoft development support for their opinion.

Asking the Exchange team first, about their implementation of MAPI and CDO, and whether could provide support for using either in managed code. The senior developer who not only owns, but who wrote a large portion of MAPI led the investigation. His conclusion: MAPI was not designed or tested to run in a managed environment, and cannot provide support for doing so. A short (incomplete) list of problems he uncovered in his investigation:

• Threading: MAPI is quite sensitive to which thread it’s running on and the token of that thread. These are used to index “instance data” shared among all threads/processes using MAPI. MAPI also creates its own threads for handling, among other things, notifications. None of this works well with the CLR thread pool, finalize, and other quirks of threading in the CLR.
• x64: .Net code can be compiled as “Any CPU”, where the process will run as a 32 bit process on a 32 bit processor, and 64 bit process on a 64 bit processor. Since MAPI is 32 bit only, any .Net application which uses MAPI and is compiled as “Any CPU” will fail when run on a 64 bit machine. We actually saw this on an internal .Net based tool where the developer had ignored our warnings against using MAPI.
• Object lifetimes: Creation and destruction of objects in MAPI must be done in a rigid and controlled manner. The sequence of object creation and destruction is critical. Is it quite difficult to exert this level of control, especially over object destruction, from managed code.
• Memory Management: MAPI has it’s own memory management scheme that isn’t really compatible with the CLR.

Same question to Outlook, and given the shared development history of the Outlook and Exchange implementations of MAPI, the Outlook development team also concluded they would be unable to support MAPI or CDO with .Net.

Now – what does it mean to say it’s not supported? It doesn’t necessarily mean you can’t make it work, given that you’re willing to put in an inordinate amount of time, effort, and development skill into it (a level at which, in my opinion, it would be simpler to just use C++). But it does mean that Microsoft, and specifically, the Developer Support Messaging team cannot help a customer develop an application that mixes MAPI/CDO in the same process as .Net. And it means if you’re running into a problem with your .Net application which uses MAPI/CDO, the first step in our investigation will be to see if you can demonstrate the problem occurs when .Net is removed from the picture.

so better Native support for Mapi/CDO or now even better – CLI to push it up to Managed interop.

right is that person that you suppose  and have a blog

http://torvalds-family.blogspot.com/ and opinions about one Microsoft product http://torvalds-family.blogspot.com/2009/01/fantastic.html

:)

i just read the post of Nikola Dudar that first version of Windows Web Service api is available, great news, for native interoperability in enterprise applications. I was in his session @PDC in LA regarding this and was amazing.

what’s is this about , you can create native webservices and webervice clients:

 // Create a channel
    hr = WsCreateChannel(
        WS_CHANNEL_TYPE_REQUEST, 
        WS_HTTP_CHANNEL_BINDING, 
        NULL, 
        0, 
        NULL, 
        &channel, 
        error);
    if (FAILED(hr))
    {
        goto Exit;
    }
    
    hr = WsCreateMessageForChannel(
        channel,
        NULL, 
        0, 
        &requestMessage, 
        error);
    if (FAILED(hr))
    {
        goto Exit;
    }
    
    hr = WsCreateMessageForChannel(
        channel,
        NULL, 
        0, 
        &replyMessage, 
        error);
    if (FAILED(hr))
    {
        goto Exit;
    }

For reference documentation for the API, check out MSDN site http://msdn.microsoft.com/en-us/library/dd430435(VS.85).aspx.
To get answers to all questions about the API and this installer, please use http://social.msdn.microsoft.com/Forums/en-us/wwsapi/threads/ forum

here are the downloads

x86 – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16646
X64 –  http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16648
Itanium – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16650

Windows XP SP2 and SP3

X86 English – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16651
X86 German – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16652

X64 English – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16662
X64 German –

Windows Server 2003 SP2 and R2 SP2

X86 English – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16656
X86 German – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16658

At work, i had to find a way to create new TCP/IP printer ports on a remote print server from the .NET code of my application. I couldn’t use WMI, so i had to find something else. Luckily, the XcvData Windows function does just that. Unfortunately, it is a royal pain in the ass to use and there’s not a lot of documentation available on how to use it. And i certainly didn’t find anything on how to call it from .NET code.

here is the Native way :

               HANDLE hXcv=NULL;
    DWORD dwFuncResult;
    PRINTER_DEFAULTSW Default ;//= {NULL,  NULL,SERVER_ACCESS_ADMINISTER };
    Default.pDatatype = NULL; Default.pDevMode = NULL; 

Default.DesiredAccess = SERVER_ACCESS_ADMINISTER;
                
            if (pServerName = ConstructXcvName(NULL, 

L"Local Port", L"XcvMonitor"))
            {
                dwFuncResult = OpenPrinterW((PWSTR) pServerName,

 &hXcv, &Default);
                if (dwFuncResult && hXcv!=NULL)
                {
                    DWORD dwStatus, cbInputData  =100,

cbOutputNeeded = 0;
                    PBYTE  pOutputData = new BYTE [ cbInputData];
    
                    if(XcvData(hXcv, L"AddPort", (PBYTE) m_strPortName, 
                        sizeof(WCHAR) * (wcslen(m_strPortName) + 1), // 
                        pOutputData, cbInputData , 

& cbOutputNeeded, &dwStatus))
                    {
                        if(dwStatus == ERROR_SUCCESS) 
                            {

                            } 
                else if (dwStatus == ERROR_ALREADY_EXISTS)
                    {
                        m_strErr.Format("Add Port Failed %d.

"(::GetLastError()));
                        OutputDebugString(m_strErr);
                    }
                    else
                    {
                    m_strErr.Format("Add Port Failed %d."

(::GetLastError()));
                    OutputDebugString(m_strErr);
                    }
                }
                else
                {
                    m_strErr.Format("XcvData Add Port Failed %d."

,::GetLastError()));
                       OutputDebugString(m_strErr);
                m_bReturn=FALSE;
                }

                    delete pOutputData;
                    ClosePrinter(hXcv);
                    }
                else
                    {
                        m_strErr.Format("Open printer Failed %d."

,(::GetLastError()));
                        OutputDebugString(m_strErr);
                        m_bReturn=FALSE;
                    }
            }
            else
                {
                m_strErr.Format("Open port Failed %(::GetLastError()));
                OutputDebugString(m_strErr);
                m_bReturn=FALSE;
                }
        }

Just looking at that makes me feel bad for everyone who’s ever had to code against Windows API’s. Anyway, according to the documentation, the first parameter (hXcv) should be a handle to the print server (which you can retrieve with a call to OpenPrinter), the second parameter (pszDataName) has to be “AddPort” if you want the function to create a new port. And then comes the fun part… the third parameter (pInputData) should be a pointer to a PORT_DATA_1 structure and the fourth parameter has to contain the size in bytes of the PORT_DATA_1 structure you passed as the third argument. The other parameters can be ignored (nice API design btw) except for the last one, which is an out parameter that will return a numeric code which will indicate either success or the cause of the failure.

I had a lot of problems trying to pass a pointer to a valid PORT_DATA_1 structure. The structure looks like this:

typedef struct _PORT_DATA_1 {
    WCHAR  sztPortName[MAX_PORTNAME_LEN];
    DWORD  dwVersion;
    DWORD  dwProtocol;
    DWORD  cbSize;
    DWORD  dwReserved;
    WCHAR  sztHostAddress[MAX_NETWORKNAME_LEN];
    WCHAR  sztSNMPCommunity[MAX_SNMP_COMMUNITY_STR_LEN];
    DWORD  dwDoubleSpool;
    WCHAR  sztQueue[MAX_QUEUENAME_LEN];
    WCHAR  sztIPAddress[MAX_IPADDR_STR_LEN];
    BYTE   Reserved[540];
    DWORD  dwPortNumber;
    DWORD  dwSNMPEnabled;
    DWORD  dwSNMPDevIndex;
} PORT_DATA_1, *PPORT_DATA_1;

As you can see, the struct contains a couple of Unicode character arrays and even a byte array. Defining a struct in C# that could be marshalled to this turned out to be the tricky part in getting this stuff to work.

But first of all, we needed to be able to call the OpenPrinter function to retrieve a handle to the print server where we need to create the new printer port:

First of all, the struct has to have Sequential as its LayoutKind, and each string must be marshalled as a unicode string (.NET strings are unicode by default, but when marshalled to native code they are converted to ANSI strings, so the CharSet setting is definitely required). Then, for each array in the original struct, you need to make sure our string is converted to an array of the expected size. Marshalling those strings as ByValTStr and setting the SizeConst parameter did the trick there. Then there’s the byte array in the original struct. The function expects there to be a byte array of 540 elements. Marshalling it as ByValArray and setting the SizeConst makes that work as well.

Right, now we have the structure, so we still need a way to call the XcvData function:

  [DllImport("winspool.drv", SetLastError = true, 

CharSet = CharSet.Unicode)]

public static extern int XcvDataW
(IntPtr hXcv, string pszDataName, IntPtr pInputData, UInt32 cbInputData,

 out IntPtr pOutputData, 
UInt32 cbOutputData,out UInt32 pcbOutputNeeded, out UInt32 pdwStatus);

      Notice how the DllImport attribute has its CharSet parameter set to unicode as well. If you don’t do this, the function call will crash your app (can’t even catch an exception) because it expects pszDataName to be a unicode string and as mentioned earlier, without specifying CharSet.Unicode it would’ve been marshalled to an ANSI string. Happy times.

Anyways, creating a TCP/IP printer port on a remote server is now as simple as this:

IntPtr printerHandle;

InteropStuff.PrinterDefaults defaults = 
new InteropStuff.PrinterDefaults { DesiredAccess = 

InteropStuff.PrinterAccess.ServerAdmin };
InteropStuff.OpenPrinter(@”\myPrintServer,XcvMonitor 

Standard TCP/IP Port”, out printerHandle, ref defaults);
InteropStuff.PortData portData = new InteropStuff.PortData
            {
                dwVersion = 1, // has to be 1 for some unknown reason
                dwprotocol = 1, // 1 = RAW, 2 = LPR
                dwPortNumber = 9100, // 9100 = default port for RAW, 515 for LPR
                dwReserved = 0, // has to be 0 for some unknown reason
                sztPortName = “IP_198.23.124.15″,
                sztIPAddress = “198.23.124.15″,
                sztSNMPCommunity = “public”,
                dwSNMPEnabled = 1,
                dwSNMPDevIndex = 1

            };

               uint size = (uint)Marshal.SizeOf(portData);
             portData.cbSize = size;
              IntPtr pointer = Marshal.AllocHGlobal((int)size);
               Marshal.StructureToPtr(portData, pointer, true);

try
          {
            IntPtr outputData;UInt32 outputNeeded;UInt32 status;
         InteropStuff.XcvDataW(printerHandle, “AddPort”, pointer,

size,  out outputData, 0, out outputNeeded, out status);
            }
finally
            {
InteropStuff.ClosePrinter(printerHandle);
Marshal.FreeHGlobal(pointer);

            }

Microsoft is working on official version of .NET and PowerShell for Server Core R2 installations, the instructions you can use at your own risk, etc., etc.

The problem is that it only ships with traditional cmd.exe and not PowerShell. To make things worse neither PowerShell nor .NET as they are today can be installed on such systems.

Alex Kibkalo and a great post by Artem Pronichkin on installing .NET on Server Core that makes this task easier.

Basically the whole procedure consists of just four main steps:

1. Installing Visual C++ Redistributable Packages (required for .NET).
2. Installing .NET 2.0 SP1
3. Installing PowerShell.
4. There it is :” :c:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe”

1. Microsoft Visual C++ 2005 SP1 Redistributable Packages

After that, copy these files to your Server Core computer and simply run them there.

If your Server Core is 32-bit - just run vcredist_x86.exe.
If it is 64-bit, you need to install both x86 and x64 versions (vcredist_x86.exe and vcredist_x64.exe).

2. .NET Framework

This is the most tricky part. PowerShell needs .NET 2.0 and .NET 2.0 is supposed to be a component of Windows Server 2008 so we will have to get a package of the framework which can get installed on such a system. To accomplish that we will:

1. Download .NET Framework 3.5.
2. Unpack the setup to get access to the .NET 2.0 Service Pack 1 installation files.
3. Download and install the Orca MSI editor.
4. Use Orca to remove the Windows version check.
5. Run the updated MSI.

2.1. Download .NET: Go to Microsoft’s web site and download full redistributable package of .NET 3.5.

2.2. Unpack the file:
a. Create a folder c:\deploy
b. Save the downloaded .NET framework package to this folder.
c. Download the wonderful deploy.cmd script which Artem has posted and put it into the same folder.
d. Run the script.

After the script executes, the C:\Deploy\AIP folder will have both NetFx20_x64 and NetFx20_x86 folders with .NET 2.0 framework files you need.

2.3. Install Orca:

This is great but unfortunately you cannot just install the files because the MSIs are specifically checking for Windows version. So now we need to disable this check. To do this we will use Microsoft’s Orca MSI editor.

Note: This all needs to be done on a regular, not Server Core, machine. We will copy the results of our Orca operations to the Core box later on.

If you don’t have Orca, follow these steps to download it:
a. Download the Windows SDK for Windows Server 2008 and .NET Framework 3.5 installer.
b. Run the installer and deselect everything except Win32 Developer Tools (this will make sure that you only download the few megs you need.)

c. After the installation completes, go to C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin and install Orca.msi.

2.4. Tweak the setup:

Now its time to do some patching.
a. Start Orca and open the MSI you need (C:\Deploy\AIP\NetFx20_x86\NetFx20a_x86.msi for 32-bit version or C:\Deploy\AIP\NetFx20_x64\NetFx20a_x64.msi for x64).
b. Click Component.
c. In x86 locate: Regtlib.exe_Tool_____X86.3643236F_FC70_11D3_A536_0090278A1BB8
In x64 locate that one and Regtlib.exe_Tool_____A64.3643236F_FC70_11D3_A536_0090278A1BB8
d. Change the Condition from (VersionNT < 600) or Version9X to just VersionNT or Version9X.

e. Save changes (either to that same MSI or a transform file.)

2.5. Install .NET

Copy the files (the whole folder) to your core machine and start the MSI via this command line (note that you need to use msiexec in order to pass the vsextui=1 parameter):

If you saved a transformed file and are running 64-bit version you will probably run:
%SystemRoot%\system32\msiexec.exe /package "NetFx20_x64\NetFx20a_x64.msi" vsextui=1 transforms="ServerCore.mst"

On x86 without a transform that would be:

%SystemRoot%\system32\msiexec.exe /package "NetFx20_x86\NetFx20a_x86.msi" vsextui=1

That’s it. Now we have .NET installed and can go to the final step - PowerShell installation!

3. Windows PowerShell

There is no PowerShell v1 setup for Windows 2008 (again, because it is supposed to be a component) but you can actually download and install the CTP (note: this is a pre-beta code - not for production use). PowerShell v2 CTP2 is available from Microsoft’s downloads page.

Download the version you need, copy the msi over to the Server Core box and simply run the msi.

4. Now you can start PowerShell!

Just run:
c:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

And you will see the prompt change to: PS C:>

That’s it. Now you are among the first geeks in the Universe to have PowerShell on Server Core!