Of Kings and Cabbage - .Net technology

Accessing Windows Live Services from Compact .NET Framework applications - Part II, Contacts

Wed, 29 Oct 2008 17:41:37 GMT

Now that we know how to acquire authentication ticket from Windows Live, we can put it to work accessing the user's contact list. In general a number of requests to the Live Services follow a common pattern. It is an HTTP(s) request to https://cumulus.services.live.com/{user identity}/{Service}/

Depending on the operation the request could be GET, PUT, DELETE, POST or other. User identity is the email address that is the Windows Live ID. Service can be one of the supported services. E.g. for contacts it is LiveContacts.

In order to provide the authentication ticket to the server the caller needs to include a custom HTTP header - "Authorization" and set its value to WLID1.0 t="{base64 auth ticket}" where {base64 auth ticket} is the ticket retrieved from the authentication server.

string url = "https://cumulus.services.live.com/{0}/LiveContacts/";
url = string.Format(url, userID);
string result = SendHttpRequest(ref url, string.Format("WLID1.0 t=\"{0}\"",ticket), "GET", System.Net.HttpStatusCode.OK, "", "", "");
XmlDocument docContacts = new XmlDocument();
docContacts.LoadXml(result);

The code above will retrieve the entire contact list as described here.

In order to create a contact, a POST to https://cumulus.services.live.com/{user identity}/LiveContacts/Contacts is required. The post contents should be an xml message formatted in accordance with Live contacts schema and having appropriate fields filled in. It is wort mentioning that WindowsLiveID field is not just an email address. It has to be a valid Live ID. Another thing to keep in mind is that almost any content-related error will cause HTTP code 403 (supposedly, for security reasons).

To delete a contact a DELETE verb is used. In order to indetify the contact being deleted or updated the application should use contact GUID provided in the ID tag:

< Contact>
   <ID>ead5572c-9c61-43a2-b71f-f2412e283598</ID>
   <AutoUpdateEnabled>false</AutoUpdateEnabled>
   <LastChanged>2007-11-19T20:26:57.2230000Z</LastChanged>
   <Profiles>
      <Personal>
         <FirstName>Alex</FirstName>
         <LastName>Feinman</LastName>
         <Gender>Male</Gender>
      </Personal>
   </Profiles>
</Contact>>

The post url will look like this:

https://cumulus.services.live.com/someone@example.com/LiveContacts/contacts/Contact(ead5572c-9c61-43a2-b71f-f2412e283598 >)>

Same url format is using for updates. Keep in mind that to update data you need to use PUT verb.
> >>>

Accessing Windows Live Services from Compact .NET Framework applications - Part I, Authentication

Wed, 29 Oct 2008 16:13:32 GMT

Windows Live Services is an infrastructure (I am trying to avoid words like 'ecosystem') that provides multiple services (contacts, photo albums, blogs, web storage, mail etc) available via federated authentication mechanism. While the majority of these services are exposed to the user as web pages, they are also available to regular applications. Microsoft own such as LIve Mail, Live Writer, Live Gallery as well as 3rd party via Live Services SDK. I am going to provide a short introduction on accessing some of the Live Services programmatically from Compact .NET Framework applications.

The starting point of any Live Services interaction being authenticating the user, it is only natural that Microsoft has provided a .NET component that handles the authentication for applications. This component however is offered only for desktop applications. Nevertheless behind every Live Service interaction there is a web request of a sort, which suggests that it can be emulated using NETCF code. While there are several authentication options available in Windows Live, there is just one that is really suitable for smart clients - RPS (Relying Party Suites). Underneath it is simply an HTTP POST of some XML data over secure channel. Upon successful request the application receives an encoded authentication ticket valid typically for 24 hours (the exact expiration time is provided with the ticket). To request the ticket an application sends XML message to https://dev.login.live.com/wstlogin.srf. The message uses content type "application/soap+xml" and looks like this:

<s:Envelope
   xmlns:s = "http://www.w3.org/2003/05/soap-envelope"
   xmlns:wsse = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
   xmlns:saml = "urn:oasis:names:tc:SAML:1.0:assertion"
   xmlns:wsp = "http://schemas.xmlsoap.org/ws/2004/09/policy"
   xmlns:wsu = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
   xmlns:wsa = "http://www.w3.org/2005/08/addressing"
   xmlns:wssc = "http://schemas.xmlsoap.org/ws/2005/02/sc"
   xmlns:wst = "http://schemas.xmlsoap.org/ws/2005/02/trust">

<s:Header>
   <wlid:ClientInfo xmlns:wlid = "http://schemas.microsoft.com/wlid">
      <wlid:ApplicationID>10</wlid:ApplicationID>
   </wlid:ClientInfo>
   <wsa:Action s:mustUnderstand = "1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</wsa:Action>
   <wsa:To s:mustUnderstand = "1">https://dev.login.live.com/wstlogin.srf</wsa:To>
   <wsse:Security>
      <wsse:UsernameToken wsu:Id = "user">
         <wsse:Username>example@live.com</wsse:Username>
         <wsse:Password>S3cr3t</wsse:Password>
      </wsse:UsernameToken>
   </wsse:Security>
</s:Header>

<s:Body>
   <wst:RequestSecurityToken Id = "RST0">
      <wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType>
      <wsp:AppliesTo>
         <wsa:EndpointReference>
            <wsa:Address>http://live.com</wsa:Address>
         </wsa:EndpointReference>
      </wsp:AppliesTo>
      <wsp:PolicyReference URI = "MBI"></wsp:PolicyReference>
   </wst:RequestSecurityToken>
</s:Body>

</s:Envelope>

Naturally, in the above XML the wsse:Username and wsse:Password will have to be substituted with actual user-provided credentials. In response we expect a standard SOAP message that has action set to http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/Issue. In the body of this message of particular interest are the following parts:

<wst:Lifetime>
   <wsu:Created>2008-10-29T14:38:23Z</wsu:Created>
   <wsu:Expires>2008-10-29T22:38:23Z</wsu:Expires>
</wst:Lifetime>

and

<wst:RequestedSecurityToken>
   <wsse:BinarySecurityToken Id="Compact0">t=[very long Base64-encoded string here]</wsse:BinarySecurityToken>
</wst:RequestedSecurityToken>

The former tells us the ticket validity time range. There is no need to reacquire a ticket until Expires date. The latter contains the actual ticket. Notice that while it has a format t=IKnvriu73nf..., the actual requests sent later to the Live servers will require the Base64 part to be quoted like this: t="IKnvriu73nf..."

Of course the application should be prepared to deal with authentication failures. A logon failure (bad password) will result in a message that looks like this:

<S:Body>
    <S:Fault>
      <S:Code>
        <S:Value>S:Sender</S:Value>
        <S:Subcode>
          <S:Value>wst:FailedAuthentication</S:Value>
        </S:Subcode>
      </S:Code>
      <S:Reason>
        <S:Text xml:lang="en-US">Authentication Failure</S:Text>
      </S:Reason>
      <S:Detail>
        <psf:error>
          <psf:value>0x80048821</psf:value>
          <psf:internalerror>
            <psf:code>0x80041012</psf:code>
            <psf:text>The entered and stored passwords do not match.</psf:text>
          </psf:internalerror>
        </psf:error>
      </S:Detail>
    </S:Fault>
</S:Body>
</S:Envelope>

Notice that it conveniently includes human-readable failure reason as well as a hex error code.

The code to request the ticket would look like this (sans error handling):

public static string AcquireTicket(string userName, string password)
{
   const string url = @"https://dev.login.live.com/wstlogin.srf";
   HttpWebRequest request = WebRequest.Create(url)as HttpWebRequest ;
   request.Method = "POST";
   request.ContentType = "application/soap+xml; charset=UTF-8";
   request.Timeout = 10 * 1000; // Wait for at most 10 seconds
   byte[] bytes = System.Text.Encoding.UTF8.GetBytes(string.Format( soapEnvelope, userName, password));
   request.ContentLength = bytes.Length;
   Stream reqStream = request.GetRequestStream();
   reqStream.Write(bytes, 0, bytes.Length);
   reqStream.Close();
   WebResponse response;
   response = request.GetResponse();
   string xml;
   using (System.IO.StreamReader reader = new System.IO.StreamReader(response.GetResponseStream()))
      xml = reader.ReadToEnd();
   response.Close();
   XmlDocument document = new XmlDocument();
   document.LoadXml(xml);
   XmlNamespaceManager nsManager = new XmlNamespaceManager(document.NameTable);
   nsManager.AddNamespace("wsse", "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd");
   XmlNode node = document.SelectSingleNode(@"//wsse:BinarySecurityToken/text()", nsManager);
   if (node == null)
      return null; // The wsse:BinarySecurityToken element is missing. Examine the xml for error information
   else
      return node.Value;
}

>

To be continued:

WISPLite on Windows Mobile 6

Fri, 01 Jun 2007 21:20:22 GMT

I was quite surprised to learn that apparently I have missed an important new feature of Windows Mobile 6 (Professional)- inking and ink serialization support. Gone are the days when a developer had to tinker with oh-so-temperamental InkX control. Now everyone and his brother can take advantage not only of high-quality precision ink support with smoothing and serialization, but also of handwriting recognition built into Windows Mobile 6 Professional. To quote the documentation - "It provides a rich inking experience, through high quality curve–fitted ink with anti-aliasing, transparent ink, and highlighter ink. It provides an API for Ink collection, data management, rendering, and recognition. It also provides Ink controls to support the note–taking scenario."

Another important feature is interoperability and serialized data format compatibility with ink support on Tablet PC.

While all of this is nice, there is slight bit of bad news - using this rich set of goodies requires C++. There are 2 ways to use ink in Windows Mobile 6 - InkCanvas control and an COM automation library. InkCanvas control offers the ability to use a regular Win32 control (similar to InkX) to write, highlight, collect ink etc via a set of Windows messages. COM automation library on the other hand allows accessing the entire set of features offered by WISP. And there is no managed wrapper for the time being.

As a public service, we at OpenNETCF.com are proud to offer WISPLite managed wrapper. The wrapper offers the entire WISPLite functionality (although not every method of every interface has been tested). There is InkControl class, which wraps InkCanvas, and a OpenNETCF.WindowsMobile.Ink namespace that contains imported COM interfaces. Some of the interfaces do not wrap cleanly, so a bit of coding is needed.

Here is what the demo app looks like (warning, before running it, change line 132 in Form1.cs to be

inkControl1.SetPenStyle(( float)trackBar1.Value, penColor, penType); )>

Saving ink data to a file:

using (SaveFileDialog fd = new SaveFileDialog())
{
fd.Filter = "Ink files (*.isf)|*.isf|All files (*.*)|*.*";
if (fd.ShowDialog() == DialogResult.OK)
{
    byte[] data = (byte[])inkControl1.GetInkData(IC_INKENCODING.BINARY);
    FileStream stm = File.OpenWrite(fd.FileName);
    stm.Write(data, 0, data.Length);
    stm.Close();
}
}>
Getting ink as bitmap and retrieving recongnition result:

pbPreview.Image = inkControl1.GetInkDataAsBitmap();
lblReco.Text = inkControl1.RecognizedText;

In conclusion I'd like to ask to report problems with this wrapper to this blog's comments.
>

Enabling CoreCon logging in NETCFv2

Tue, 17 Apr 2007 19:12:44 GMT

Sometimes when trying to connect Visual Studio t a device, especially to a custom CE platform, it is helpful to see if there are any problems reported by the CoreCon components on the device side. CoreCon components (ConmanClient, trasnport DLLs, edbgtl.dll and edm.exe) all have an integrated logging facility, which can be used by a developer for troubleshooting.

To enable Corecon debug log you can set the following under HKLM\Software\Microsoft\VSD\Logging

VSD_LogEnabled: DWORD:1,0

VSD_LogToDebugger: DWORD:1,0

VSD_LogToConsole: DWORD: 1,0

VSD_LogToFile: DWORD:1,0

VSD_LogLevel: DWORD - set to at least 4, up to 9

VSD_LogFile: REG_SZ (default VSDLogFile.txt)

Keep in mind that the ConMan log can be quite chatty, so enable it sparingly and only when needed

Running RTF Host (Compact Framework 3.5 Power Toys) on emulator

Sun, 25 Feb 2007 14:45:36 GMT

Raffaele Rialdi pointed out that attempting to run RTF Host from Compact Framework 3.5 Power Toys on an emulator produces the following error:

This is caused by RTF getting confused because the default CoreCon transport on the emulator is DMA (DeviceDMA.dll). Here are the steps to add emulator as a manual Tcp connection. Not that many will need it, but it is useful for a demo

1. Start Emulator using Device Emulator Manager.
2. Configure Network and Storage card folder
3. Copy to storage card folder the following file: "C:\Program Files\Common
Files\microsoft shared\CoreCon\1.0\Target\wce400\armv4i\TCPConnectionA.dll"
4. In File ExplorerNavigate to \Windows\Corecon1.1. If you don't see it
there, connect to the emulator from Studio
5. Launch ClientShutdown (you should see a guid-named folder to appear)
6. Copy \Storage Card\TcpConnectionA.dll to \Windows
7. Go to \Windows and delete DeviceDMA.dll (if you can't, you forgot to
launch ClientShutdown)
8. Go back to \Windows\Corecon1.1 and launch ConmanClient.exe
9. Launch RTF Host. Enjoy

Running RTF Host (Compact Framework 3.5 Power Toys) on emulator

Sun, 25 Feb 2007 12:55:18 GMT

Raffaele Rialdi has pointed out that trying to run RTF Host from CF 3.5 Power Toys (required for manual connectivity) on a Windows Mobile emulator produces an error :

This is caused by RTF getting confused and trying to use DMA transport instead of TCP. Here are the steps to establish a manual RTF connection to an emulator (you don't really need it unless you are doing a demo)

1. Start Emulator using Device Emulator Manager.

2. Configure Network and Storage card folder

3. Copy to storage card folder the following file: "C:\Program Files\Common
Files\microsoft shared\CoreCon\1.0\Target\wce400\armv4i\TCPConnectionA.dll"

4. In File ExplorerNavigate to \Windows\Corecon1.1. If you don't see it
there, connect to the emulator from Studio

5. Launch ClientShutdown (you should see a guid-named folder to appear)

6. Copy \Storage Card\TcpConnectionA.dll to \Windows

7. Go to \Windows and delete DeviceDMA.dll (if you can't, you forgot to
launch ClientShutdown)

8. Go back to \Windows\Corecon1.1 and launch ConmanClient.exe

9. Launch RTF Host. Enjoy

What were they thinking?

Mon, 02 Oct 2006 20:23:53 GMT
Some MSDN articles are very good. Some are useful. Some are bizzare. This one is, well - it makes you ask, what were they thinking

Installing Visual Studio 2005 SP1 Beta 1

Thu, 28 Sep 2006 21:08:37 GMT

Several people have hit a problem while installing the service pack on Windows Server 2003 machines. The installation (that takes obscenely long time) eventually fails with a message:

Error 1718: The file xxxxxxxx.msp was rejected by digital signature policy.

Two things with repsect to that:

1) I had this problem and was eventually able to complete installation (on the second try). What has changed is that I moved the SP file from a network location to a local drive.

2) Take a look at the setup log. It can be found under %temp%\VS80sp1-KB918525-X86-Beta-ENU (this path can be pasted into Run box to open the folder)

Upcoming MSDN webcast on IMAPI2 and CD/DVD burning

Tue, 04 Apr 2006 22:07:24 GMT
MSDN webcast on IMAPI2 and CD/DVD burning

New in OpenNETCF SDF 2.0 - Imaging API wrapper - part II

Sat, 04 Feb 2006 01:13:30 GMT
Details on the new features in the Imaging API wrapper - part of SDF 2.0

New in OpenNETCF SDF 2.0 - Imaging API wrapper - part I

Sat, 28 Jan 2006 21:53:31 GMT
Just released beta 1 of OpenNETCF SDF 2.0 introduces an Imaging API wrapper

They are coming

Tue, 01 Nov 2005 21:55:33 GMT
Visual Studio Launch Tour

Installing VS2005 August CTP on Windows Vista 64

Fri, 09 Sep 2005 07:33:53 GMT
Installing VS2005 August CTP on Windows Vista 64

Marvels of COM .NET interop

Sun, 28 Aug 2005 08:21:02 GMT
Using .NET stock objects from VB Script

MSDN Webcast on hosting ActiveX controls

Thu, 25 Aug 2005 23:40:44 GMT

I've just done a webcast, which was effectively a repeat of my MEDC'05 presentation on hosting ActiveX controls in CF 2.0. It can be seen here

Update (09/03/2005). It is apparently not entirely clear from the webcast, where the source code is. It can be found here

Update 2 (09/03/2005). The source code will not compile on beta 2 of Visual Studio because of Marshal.AllocHGlobal/FreeHGlobal that were not introduced until July CTP. Simply replace them with AllocCoTaskMem/FreeCoTaskMem

Update 3 (09/03/2005). TO be able to host WMP in Pocket PC application you must have WMP10. WMP9 did not have an ActiveX interface. Some (but not all) of the 2003SE device have WMP10. All WM5 devices will have WMP10

InTheHand.com releases Windows Mobile API for .NetCF Suite

Tue, 02 Aug 2005 16:07:56 GMT
InTheHand.com releases Windows Mobile API for .NetCF Suite

Batman returns

Tue, 24 May 2005 18:42:31 GMT

... or is it Superman?

The kind folks, who administer MSDN webcasts, sent me as one of the year 2005 presenters a shirt and a ... cape. Yes, a red cape.

WCELoad dirty little secrets

Thu, 21 Apr 2005 00:52:05 GMT
How to install your cab to a particular location (Main Memory/Storage Card). Imitating CeAppMgr

The end of the world as we know it

Thu, 10 Mar 2005 07:14:57 GMT
Microsoft announces the end of support cycle for VB6

Adding tooltips to Compact Framework Toolbar control

Fri, 25 Feb 2005 03:14:38 GMT
Adding tooltips to Compact Framework Toolbar control

Obtaining hWnd from TextBox controls on Smartphone

Wed, 09 Feb 2005 20:24:05 GMT
Obtaining hWnd from TextBox controls on Smartphone is slightly different from the Pockect PC platform. Here is why.

Keeping referenced DLLs in subfolders

Wed, 09 Feb 2005 20:15:44 GMT
Can a Compact Framework application keeps its class libraries in a directory other than the application directory (or \Windows or GAC)? Yes, it can.

Scrolling a text box

Mon, 20 Dec 2004 06:12:42 GMT
Avoiding flickering when adding data to a multiline textbox in Compact Framework

Data binding and XML

Mon, 22 Nov 2004 04:41:11 GMT
So you have a complex xml document and want to bind your screen controls to its nodes/attributes. Here is how.

Manipulating event handlers in NETCF

Sun, 07 Nov 2004 09:19:43 GMT

I've posted an article discussing the event handler internals, tips and tricks

Creating irregularly-shaped windows in Windows CE - article is up on www.opennetcf.org

Thu, 21 Oct 2004 17:27:51 GMT

I've posted an article that discusses how to create non-rectangular windows in Windows CE using Compact Framework. See it here

Implementing BeginUpdate/EndUpdate on a Listbox and Combobox

Mon, 04 Oct 2004 01:28:01 GMT
Compact Framework versions of listbox and combobox control do not have BeginUpdtate/EndUpdate methods. This post explains how to implement these methods to help avoid excessive screen updates

A mysterious case of disappearing CRs

Mon, 20 Sep 2004 17:01:44 GMT
Why does my web service eat my CRLFs and spit LFs only

How .NET CF application checks for the previous instance

Wed, 17 Mar 2004 20:37:08 GMT
A short guided trip into the bowels of your .NET CF application