If your company has 500 or more employees, you can buy an iPhone “Enterprise” developer license.  It’s a bit more then the “Standard” individual and company licenses, but not much.  For more on developer licenses, go here.

Once you have the license, you can sign your LOB apps with your certificate and provision them to company devices.  “Enterprise” developer licensing allows what is called “Universal” application provisioning.  This is the same type of provisioning that is granted to applications deployed through the Apple Appstore and allows deployment of the application to any iPhone on the face of the Earth.

Wow, so with a developer license, you can deploy an app to any iPhone out there without going through the appstore….WRONG!  The “Enterprise” developer license EULA that you accepted dicatates that you are only allowed to deploy apps to iPhones operated by employees of your company.  Deployment to any other iPhones is illegal.  And, I’m absolutely sure that Apple is not going to stand by and let you break the law.

Well, you can deploy your LOB app to your company users and that’s the important thing, right?  At this point, you may be wondering how you go about deploying the application to the employee-operated iPhone.  There are currently two ways to do it.  Use the iPhone Configuration Utility (iPCU) or use Apple iTunes.  Both methods are described in the Apple iPhone Enterprise Deployment Guide.

The caveat here is that neither iPCU or iTunes app deployment can be performed directly between the iPhone and a server.  Both iPCU and iTunes are desktop applications that run on either a Mac or Windows machine.  But, they do support two different scenarios.  iPCU is best if you want to setup a bulk number of iPhones with your LOB before giving them to the user.  iTunes is better for deployment of the app or on-going updates when the iPhone is already in the user’s hands.

When deploying the LOB app, you have to get your Enterprise Developer License .mobileprovision file installed on the iPhone before you can install a .app file.  You can deploy the .mobileprovision file using desktop management that you may have deployed in your network to offload this task from the user.  When the iPhone is connected to the desktop running iTunes, the .mobileprovision file will be deployed.  Then the user must add the .app to their app library and select to install it on their iPhone.

.NET Compact Framework Logging

On Steve Hegenderfer and Reed Robinson’s excellent blog Reed posted a great article about how to enable .NET CF loader logs and what to look out for. Specifically referencing this MSDN information on how to enable the logging: http://msdn.microsoft.com/en-us/library/ms229650.aspx. It is all controlled in specific registry keys on the device to enable 6 different flavors of .NET CF logging: "Interop", "Error", "Loader", "Network", "Finalizer", or "Trace".

The Power Toys for .NET Compact Framework v3.5 download gives you additional tools to make this easier. One is the Remote Logging Configuration Tool:

So the most interesting for non-developers trying to troubleshoot .NET CF applications is probably the "Loader" logging. This is where you can see if the application even makes it off the ground and why. As Reed suggests in the article I mentioned it could be referencing a .NET assembly not present on the device for whatever reason..

Additional details on how to read the "Loader" logging can be found here: http://msdn.microsoft.com/en-us/library/ms229667.aspx.

File System Logging

This is a type of extreme logging that can really slow down a working operating system. But it can also show you exactly what is going on at the file I/O level. Specifically what files are being accessed or written to. This could be useful to trace back missing files or folders, or figuring out the last file access a specific application did before failing.

I only recently found a tool called MobileMon v0.5 by Brian Dunn. His website, http://www.mobilmon.com/, has more information and you can download the .CAB file there.

Basically you can install and run it in the background while it logs file activity.

Once you are done you can save it to a log file. Be aware however that the file name "mobilmon.log" may be hard to open on the device itself unless you install a tool (Like Voyager or Total Commander) to rename the file to mobilmon.txt. Then you can open it with the native Word Mobile.

Memory Management and Monitoring

Another important area of concern for current Windows Mobile troubleshooting is available memory on the device.  Memory leaks, multiple running applications, and garbage heaps can all attribute to doing frequent soft-reboots to get a device functional again. A little known fact that I wasn’t fully aware of is that only 32 applications (actually processes) can run at the same time and each can at a maximum access 32mb of virtual memory..

An excellent resource of a virtual memory management overview is William Blanke’s article: http://www.codeproject.com/KB/mobile/VirtualMemory.aspx

In it he also has a small (12Kb) Virtual Memory tool (must register to download, the compiled .exe in included with the source code) you can run and visually see available memory (in red) for each of the 32 process slots.

Issue #1: One key thing apart from seeing how many of the slots are being used and if they are full, is finding the “device.exe” process. This process is responsible for loading up all the device drivers and William points out the potential issues if memory is low for this slot. Specific device features may simply not work.

Issue #2: Another area of concern could be applications that load up .DLL files. These can be loaded up in *any* processing slot and can be accessed by any process. This can be bad if your process or application running in the slot needs the memory and doesn’t use the particular DLL.

However William doesn’t address that in Windows Mobile 6.1 specific changes were made to better accommodate DLL files over 64Kb. These will now be loaded into specific slots higher and away from the process slots. Thus freeing up application space and reducing this potential worry. Please see more information on this 6.1 feature from Doug Boling here.

How sure if anything has/will change in Windows Mobile 6.5 as of yet. What we can look forward to is Windows Mobile 7.0 (which is based upon Windows CE 6.0) and it’s larger scale advanced memory management, explained in more detail here or here. But basically a little like Windows XP, and a limit of 32K processes and 2GB per process, compared to 32 and 32Mb per process.

Issue #3: Careful on the usage of storage cards to install or run applications from. If the device goes into hibernation or sleep mode, it could power down the storage card and render any application housed there non-functional. See more tips here.

Some older reference links on Windows Mobile memory management: 
- RAM, ROM and Task Managers 
- How WM 5.0 Shell Handles Low Memory Situations 
- Memory Management on WM 6.x 
- MSDN Webcast: Memory Management for Windows Mobile
- DumpMem Utility

If you are using a Motorola/Symbol ruggedized device you also may want to ask your Motorola rep about their “Private SDK” and a tool called the “Remote Memory Viewer”. It may also be beneficial as Raffaele Limosani states here..

Hope this article further assists in troubleshooting Windows Mobile issues you might run into!

|\\arco..
http://marco.blogsite.org

At first glance, I assumed this would be a breeze. I have a powerful layout, key handling, and paint framework that I use in every project I work on, and thought that creating a home screen leveraging that would make it trivial. Sadly I was sorely mistaken.

Those of you familiar with WM Home Screen development know that there are actually two APIs: the Home Screen API (Smartphone) and the Today Screen API (Pocket PC). I was only interested in the prior. Smartphone Home Screen development is considerably more difficult: you don’t have nearly as much control. The developer must implement IHomePlugin which only receives paint events (the plug-in is supplied only an HDC) and some key events (left and right only). On Pocket PC, you get an HWND and all the good things that go along with it.

That didn’t phase me too much. My plan of action was to implement this IHomePlugin interface in managed code and then let the magic happen. Easy enough. I implement a dummy plug-in in C#, and try to register the COM object… and it doesn’t work. It refused to register, the error claiming it was an invalid DLL. I poked at it for a while before finally giving up and checking to see if Google would know why I could not register a C# COM object on Windows Mobile.

I searched for a while, and found plenty of examples of how to invoke unmanaged code from managed code. Then I noticed, not a single site showed how to invoke managed from unmanaged. I began searching explicitly for that, and found my answer:

The .Net Compact Framework does not support hosting the runtime from native code. This means that you will not be able to call CoCreateInstace to instantiate a managed object, or register managed objects as COM objects on the system. You will also not be able to call CorBindToRuntime or ClrCreateManagedInstance. In order to call managed functions from native code, you must first use the runtime to marshal a managed interface or a delegate down to native code. This means you must always start out in managed code (with a .net executable) in order to expose .net components to native code.

This was news to me. And pretty devastating; the thought of creating a fairly complex home screen from scratch in unmanaged code was daunting. If it is not obvious, I’m primarily a .NET developer. Don’t get me wrong, I have grass roots in C, but, the facts of life are that the lower level your programming language, the higher the development time and bug count.

So I quickly thought of a workaround though: create a managed service executable that hosts the UI framework. And using a combination of MessageWindows and sharing memory between processes, I could construct a bridge from unmanaged to managed code:

Implement IHomePlugin in unmanaged code and add that plug-in to the home screen. The unmanaged plug-in will do the following:

1. Create a pool of shared memory.
2. Create a back buffer HDC. This back buffer is what painted whenever the home screen requests a repaint. The managed code will write to this back buffer across process boundaries.
3. Whenever the PE_DATACHANGE event is received, invalidate the plug-in.
4. In the shared memory, write the HDC value, system colors, and plug-in dimensions.
5. Start my managed executable.

Once started, the managed executable does the following:

1. Gets the back buffer HDC and other relevant values from the shared memory pool.
2. Paint to the back buffer HDC.
3. Notifies the Home Screen API that a plug-in has had a data change event using SHOnPluginDataChange. This in turn causes the plug-in to invalidate and repaint from the back buffer.

That solves the painting issue, but the plug-in still needed to get key events from the Home Screen API and deliver them to managed code. Easy enough: the managed executable can create a MessageWindow and the unmanaged can deliver the key events provided by the Home Screen API. The managed code can then process the key event, repaint the back buffer, and invalidate the plug-in to refresh the screen.

This works great, but the catch with the API is that it delivers only left and right key presses. It won’t send up and down key events (because then the user can’t navigate to another plug-in on the home screen). However, since my plug-in was full screen, I did not matter. I needed a way to navigate vertically between elements laid out in my single full screen plug-in.

The solution to capturing all key events is a neat trick that native Win32 API developers are familiar with. Have the unmanaged plug-in subclass the home screen window (DesktopExplorerWindow as found in the VS Remote Spy++ tool) proc to steal the key presses and send them off to the managed code.

And there you go, a fully functional “managed” Home Screen Plug-In. My initial worry was that performance would suffer terribly from the cross process communication, but the home screen was actually very responsive. Users reported that the UI was quite “snappy”.

Unfortunately I don’t have any sample code to provide (yet), since this is all company IP. But maybe it will be released in the future!

Note: I should mention that Home Screen development actually gets easier with this interprocess communication. Developing a purely unmanaged plug-in means that the entire home.exe process needs to be stopped and started with every little change made to the plug-in. This can grow to be quite tedious. With the two-process model, starting and stopping the second managed process leaves the home.exe undisturbed.

Koushik Dutta
Software Engineer
www.koushikdutta.com

Sadly, I did not create an installer for this template.

Installation instructions (adjust your installation directory accordingly):

1. Unzip the contents onto your drive.
2. Copy CESetupDLL.ico, CESetupDLL.vsdir, and CESetupDLL.vsz to C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcprojects\smartdevice
3. Copy the Scripts and Templates folders into C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\VCWizards\SmartDeviceAppWiz\CESetupDLL
4. Edit CESetupDLL.vsz and edit the ABSOLUTE_PATH value to whatever you supplied in Step 3.

And that should do it! You will now find the new project template in Visual Studio under the Smart Device folder in Visual C++.

Koushik Dutta
Software Engineer
www.koushikdutta.com

However Scott, from scottandmichelle.net, successfully reverse engineered the HTCSensorSDK.dll. This allows developers to use the g-sensor that is available on the device. Very impressive work on the part of Scott!

Anyhow, I spent a portion of today writing a managed wrapper for HTC’s Sensor API. You can download it here. The code also includes a sample Teeter-esque type application which allows you to roll a ball around the screen.

The managed API exposes the HTCGSensor class which allows you to hook to query the state of the g-sensor on the device. It exposes the following methods, properties, and events:

GetGVector
Returns a vector that desribes the direction of gravity/acceleration in relation to the device screen.

• When the device is face up on a flat surface, this method would return 0, 0, -9.8. The Z value of -9.8 would mean that the acceleration in the opposite direction of the orientation of the screen.
• When the device is held standing up, this method would return 0, -9.8, 0. The Y value of -9.8 would mean that the device is accelerating in the direction of the bottom of the screen.
• Conversely, if the device is held upside down, this method would return 0, 9.8, 0.

The vector returned will have a length measured in the unit meters per second square.

Ideally the when the device is in a motionless state, the vector would be of length 9.8 (the gravitational constant). However, the sensor is not extremely accurate, so this almost never the case.

Orientation
Retrieves the current orientation of the device, returning one of the following enums: Landscape, ReverseLandscape, Portrait, ReversePortrait, FaceDown, FaceUp.

OrientationChanged
This event fires whenever the device’s orientation changes.

Enjoy, and let me know if you find any bugs!

Koushik Dutta
Software Engineer
www.koushikdutta.com

I hit 3 snags while working on this:

1. Build Service Setup and Permissions
2. Automatic versioning in the standard Major.Minor.Build.Revision style
3. Smart Device CAB files are not supported by MSBuild

Build Service Setup and Permissions

1. Set up Team Build on the Build machine (BuildMachine)
   1. Install Team Build
   2. Install Visual Studio 2008 on the machine as well, otherwise Compact Framework projects will not compile.
   3. Install the Windows Mobile 6 Professional and Standard SDKs, Visual Studio 2008 only ships with Windows Mobile 5 SDKs.
2. Make sure the Build Service account (TFSBuild) has full access and permissions to the share you are publishing (\\PublishMachine\Builds\…).
3. Create a Build Agent (only needs to be done once per server, and then is accessible to everyone). In Visual Studio, click Build, and type the server name (BuildMachine).
4. Create a Build Definition for your project
   1. In Team Explorer, under Builds, create a new Build definition. The wizard is very straightforward. Choose a location in the source tree, and choose a build configuration (Release). This will create a tfsbuild.proj file in the location you specified in the source tree. You will need to edit this file later on.
   2. Right click the build definition and perform a build. Verify it succeeded. You will notice that the build number is Ole Automation dated. Not very easy on the eyes.

Automatic Versioning

Microsoft has some generic MSBuild tasks available that can be used to handle this. They are a separate download from Visual Studio however. Here’s the relevant links:

• TFSBuild
• SDCTasks

1. Setting up your Solution
   1. Add the Microsoft.Sdc.Common.tasks and Microsoft.Sdc.Tasks.dll to the root of your solution. Using the ones provided by Microsoft actually caused me build errors for whatever reason. Some of the tasks they included were the cause. I have commented out all the tasks but those necessary to accomplish versioning. I have attached the .dll and the edited .tasks file to this blog.
2. Preparing the Version.xml File
   1. I have attached a sample Version.xml to this blog. Save this to a network share (preferably the same as the one being used when the Build definition was created). The task will reference this file to retrieve the current version, increment it, and save the new version back to the file.
   2. The build service account (TFSBuild) needs to have full permissions to this file. This file must not be read only.
3. Modifying the TFSBuild.proj
   1. Check the tfsbuild.proj file out for edit
   2. Add the following XML blob before the ending </Project> tag:

      1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

      <!-- This will retrieve and increment a version number from a file on a network share --> <import Project="$(MSBuildProjectDirectory)\Microsoft.Sdc.Common.tasks" /> <target Name="BuildNumberOverrideTarget"> <!-- Now update the version number --> <versionnumber .Update VersionNumberConfigFileLocation="\\emsea100\path\to\Version.xml" SkipSourceControl="true" OnlyIncrementRevision="true"> <output TaskParameter="VersionNumber" PropertyName="BuildNumber" /> </versionnumber> </target>   <!-- This will replace all version numbers in the assemblyinfo.cs files with the one from the share --> <!-- This target is called after Team build gets all the source files from TFS. --> <target Name="AfterGet" DependsOnTargets="VersionAssemblies" />   <target Name="VersionAssemblies"> <!-- Get the Assembly Info files.--> <createitem Include="$(SolutionRoot)\**\AssemblyInfo.cs;"> <output TaskParameter="Include" ItemName="AssemblyInfos"/> </createitem>   <!-- Update the version numbers --> <file .Replace Force="true" Path="%(AssemblyInfos.FullPath)" NewValue="AssemblyVersion(&quot;$(BuildNumber)&quot;)" regularExpression="AssemblyVersion\(\&quot;(\d+.\d+.\d+.\d+)\&quot;\)" ignoreCase="true" /> </target>

   3. Edit the VersionNumberConfigFileLocation value to be configured for your publish machine and directory. You can also change the OnlyIncrementRevision to false so that the build number also gets autoincremented.

Building a Smart Device CAB Project Using MSBuild

There is no “good” way to do this. I did this by creating a standard Smart Device CAB project, and then building it on my development machine. If your project is called SmartDeviceCab, in the SmartDeviceCab\Debug folder, there is a SmartDeviceCab.inf file. That file can be used as input to CabWiz.exe to create the file from a command prompt. I will be using the INF file of our recently released tool, Device IP Utility, as an example.

1. Solution Setup
   1. Copy the EMIPUtil.inf file to the solution root folder.
   2. Right click the solution and add existing file: %SolutionRoot%\ EMIPUtil.inf
2. Modifying the INF file
   1. The INF file will contain a section of absolute paths to the location of the binaries on the development machine. This needs to be changed to absolute paths on the build machine. Note that all the binaries on the build machine will be dumped into the same directory, making it relative easy to edit. The first INF file shows what the file may look on your development machine, and the second will show how it should look on your build server.
      1. Old Paths Local to Your Development Machine

         
         1=,”Common1″,,”C:\Users\kdutta\Documents\Visual Studio 2008\Projects\Device IP Utility\Device IP Utility - Production\EnterpriseMobile.WindowsMobile.IPUtil\bin\Release\”
         2=,”Common2″,,”C:\Users\kdutta\Documents\Visual Studio 2008\Projects\Device IP Utility\Device IP Utility - Production\EnterpriseMobile.WindowsMobile.IPUtil\obj\Release\”
         3=,”Common3″,,”C:\Users\kdutta\Documents\Visual Studio 2008\Projects\Device IP Utility\Device IP Utility - Production\EnterpriseMobile.WindowsMobile.Utilities\bin\Release\”
         4=,”Common4″,,”C:\Users\kdutta\Documents\Visual Studio 2008\Projects\Device IP Utility\Device IP Utility - Production\EnterpriseMobile.WindowsMobile.Utilities\obj\Release\”
         5=,”Common5″,,”C:\Users\kdutta\Documents\Visual Studio 2008\Projects\Device IP Utility\Device IP Utility - Production\WMIPUtil\obj\Release\”
         6=,”Common6″,,”C:\Users\kdutta\Documents\Visual Studio 2008\Projects\Device IP Utility\Device IP Utility - Production\WindowlessControls\bin\Release\”
         7=,”Common7″,,”C:\Users\kdutta\Documents\Visual Studio 2008\Projects\Device IP Utility\Device IP Utility - Production\WindowlessControls\obj\Release\”
         8=,”Common8″,,”c:\Users\kdutta\Documents\Visual Studio 2008\Projects\Device IP Utility\Device IP Utility - Production\EnterpriseMobile.WindowsMobile.IPUtil.Interop\Windows Mobile 5.0 Smartphone SDK (ARMV4I)\Release\”
         

      2. New Paths on Build Machine

         
         1=,”Common2″,,”C:\Documents and Settings\TFSBuild\Local Settings\Temp\Device IP Utility\Device IP Utility - Production\Binaries\Release\”
         2=,”Common3″,,”C:\Documents and Settings\TFSBuild\Local Settings\Temp\Device IP Utility\Device IP Utility - Production\Binaries\Release\”
         3=,”Common4″,,”C:\Documents and Settings\TFSBuild\Local Settings\Temp\Device IP Utility\Device IP Utility - Production\Binaries\Release\”
         4=,”Common5″,,”C:\Documents and Settings\TFSBuild\Local Settings\Temp\Device IP Utility\Device IP Utility - Production\Binaries\Release\”
         5=,”Common6″,,”C:\Documents and Settings\TFSBuild\Local Settings\Temp\Device IP Utility\Device IP Utility - Production\Binaries\Release\”
         6=,”Common7″,,”C:\Documents and Settings\TFSBuild\Local Settings\Temp\Device IP Utility\Device IP Utility - Production\Binaries\Release\”
         7=,”Common8″,,”C:\Documents and Settings\TFSBuild\Local Settings\Temp\Device IP Utility\Device IP Utility - Production\Binaries\Release\”
         8=,”Common9″,,”C:\Documents and Settings\TFSBuild\Local Settings\Temp\Device IP Utility\Device IP Utility - Production\Binaries\Release\”
         

3. Making MSBuild call CabWiz.exe
   1. Check out and edit the tfsbuild.proj file
   2. Before the ending </Project> tag, insert the following:

      1 2 3 4 5 6

      <!-- This will build a CAB file from an .inf file --> <target Name="BeforeDropBuild" DependsOnTargets="MakeCAB"/> <target Name="MakeCAB"> <message Text="Building a CAB file" Importance="normal"/> <exec Command="&quot;C:\Program Files\Microsoft Visual Studio 9.0\SmartDevices\SDK\SDKTools\cabwiz.exe&quot; &quot;C:\Documents and Settings\TFSBuild\Local Settings\Temp\Device IP Utility\Device IP Utility - Production\Sources\EMIPUtil.inf&quot; /compress /dest &quot;C:\Documents and Settings\TFSBuild\Local Settings\Temp\Device IP Utility\Device IP Utility - Production\Binaries&quot;"/> </target>

   3. Modify the following Command Attribute to be set up specifically for your build machine. This defines the path to CabWiz.exe, the path to your INF file, and the output directory of the CAB file.
   4. This XML insert calls the CabWiz.exe prior to publishing the binaries. CabWiz.exe adds the CAB file to the binaries folder, which in turn gets published with everything else.

Sadly there is somewhat poor support for Smart Device Projects in TFSBuild, so making it work isn’t exactly elegant, but it works!

Koushik Dutta
Software Engineer
www.koushikdutta.commicrosoftsdccommon

DPAPI provides easy-to-use functions for encryption and decryption.  A number of applications use DPAPI.  The thing that makes DPAPI easy to use for developers is that they don’t have to wite all the key generation and key management code that typically goes with any encryption solution.  DPAPI uses a master key that is stored in the memory of the device.  When an application calls DPAPI, the same master key is used to generate symmetric keys for all encryption and decryption operations.  In this way, the application does not have to generate or manage the encryption key used.  For a thorough description of DPAPI see the MSDN article covering Windows Data Protection

Of course, this begs the question, “How is the master key protected?” The master key is encrypted itself at the time it is generated.  And, it is decrypted at system boot time.  It must be decrypted for use during boot in case an encrypted file is loaded during the boot process. The key used to decrypt the master key is derived from a password and used during boot.  In Windows Mobile, there are 2 master keys, the “user” master key and the “system” master key.  The “system” master key is encrypted using a key derived from the system “password” which is a mixture of system information.  The “user” master key is typically derived from a user password. 

The “user” master key is considered more secure then the “system” master key because the entropy used to encrypt it includes information only the user knows (i.e., their password).  The “system” master key is more flexible though because the system does not need to go get input from the user.

The “user” master key on WM 6.1 is derived from the Windows Mobile device lock PIN or password that is entered by the user during device boot.  Therefore, when you enable encryption on a device, the user must configure a PIN/Password, if not already configured. 

Note that the encryption of data written to storage cards in Windows Mobile 6.0 and later also uses DPAPI, but with the “system” master key rather then the “user” master key.  This is a lot less of an issue for removable storage card encryption then for main memory file encryption.  The primary attack on the “system” master key requires access to the system used to create it and typically,the attack on the removable storage card is mounted from a different computer that the lost or stolen removable storage card is inserted into.

btw, the default encryption algorithm used since Windows Mobile 6.0 for DPAPI is AES-128.  Prior to Windows Mobile 6.0, DPAPI utilized RC4.

Dave Field, CISSP, MCP
Device Management and Security Architect
Enterprise Mobile, Inc.

The beauty of anonymous methods is that the compiler’s syntactic sugar handles a lot of the aforementioned for the developer very elegantly in the background.

Here’s what a fully asynchronous download looks like now, with error handling and cleanup and all (5 anonymous methods in total):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73

HttpWebRequest req = WebRequest.Create("http://www.google.com") as HttpWebRequest;
MemoryStream memStream = new MemoryStream();
HttpWebResponse resp = null;
 
// anonymous method to handle cleanup
EventHandler Cleanup = (s, ev) =>
    {
        using (resp)
        {
        }
        resp = null;
        using (memStream)
        {
        }
        memStream = null;
    };
 
// anonymous method to handle errors
EventHandler Error = (s, ev) =>
{
    MessageBox.Show((s as Exception).Message);
    Cleanup(null, null);
};
 
req.BeginGetResponse(responseResult =>
    { // anonymous method that waits for a response from the web server
        Thread.Sleep(1000); // for asynchronous testing
        try
        {
            resp = req.EndGetResponse(responseResult) as HttpWebResponse;
            Stream responseStream = resp.GetResponseStream();
            byte[] buffer = new byte[1024];
            AsyncCallback rc = null;
            rc = readResult =>
                { // anonymous method that waits to read a some data from the web server
                    Thread.Sleep(1000); // for asynchronous testing
                    try
                    {
                        int read = responseStream.EndRead(readResult);
                        if (read > 0)
                        {
                            memStream.Write(buffer, 0, read);
                            responseStream.BeginRead(buffer, 0, buffer.Length, rc, null);
                        }
                        else
                        {
                            // We finished downloading! Invoke the UI thread to print the data!
 
                            // anonymous method to handle completion
                            EventHandler Done = (s, ev) =>
                            {
                                memStream.Seek(0, SeekOrigin.Begin);
                                string blob = new StreamReader(memStream).ReadToEnd();
                                Cleanup(null, null);
                                MessageBox.Show(blob);
                            };
 
                            Invoke(Done);
                        }
                    }
                    catch (Exception ex)
                    {
                        Invoke(Error, ex);
                    }
                };
            responseStream.BeginRead(buffer, 0, buffer.Length, rc, null);
        }
        catch (Exception ex)
        {
            Invoke(Error, ex);
        }
    },
    null);