The .NET Micro Framework v3.0 includes a full-featured DPWS stack and a code generation tool, MFSvcUtil.exe, that generates Hosted Service Stubs and Client Proxies from a standard WSDL.
The DPWS stack on the Micro Framework has been developed exclusively for the Micro Framework, and will not run on a Windows platform unless you are running it in the Micro Framework emulator.
There are a number of different configurations you can experiment with:
1) Running a hosted service on a Micro Framework device together with one of the following :
a. A Micro Framework DPWS client in the Micro Framework emulator
b. A Micro Framework DPWS client on a second Micro Framework device. This can actually be the same device that the Hosted Service is running on, but that doesn’t make a lot of sense outside of testing.
c. A WSDAPI client on a Widows computer or a WinCE device
d. A .NET 3.0 Windows Communication Foundation (WCF) client on a Windows computer. In this configuration, Discovery does not work. Discovery is expected to be added to WCF in a future release.
2) Running a Micro Framework DPWS client on a Micro Framework device and:
a. A Micro Framework Hosted Service in the Micro Framework Emulator
b. A WSDAPI Service running on Windows or a Win CE device
c. A WCF Service running on a Windows Computer.
I’ll try to cover the relevant points for each of these scenarios. The DPWS solution I am using is the solution included with the SDK. This sample was built using the SimpleService WSDL (http://msdn.microsoft.com/en-us/library/cc264253.aspx Part of the WHQL certification test suite) and the MFSvcUtil code generation tool.
This is a great scenario for getting the Micro Framework samples running, and for exploring the way the DPWS stack on the Micro Framework works. To set up this scenario, you will need the following:
1) A Micro Framework device with Networking. You can use the GHI Embedded Master or the Device Solutions Tahoe2 board.
2) A Windows Computer with the following installed:
a. Visual Studio 2008 SP1 (Express Edition is OK)
b. .NET Micro Framework V3.0 SDK
c. A network subnet set up between the device and the computer. My network set up is as follows:
i. An Allied Telesyn AT-GS900/8 10/100/1000 Ethernet switch (Any hub should work)
ii. The MF Device and the PC are the only things connected to the switch (plus power, of course)
iii. The Device IP configuration is
1. Addr = 10.1.1.102
2. Subnet Mask = 255.255.255.0
3. Gateway 10.1.1.102
4. DNS = 0.0.0.0
5. DHCP is disabled
iv. The PC TCP/IP configuration is:
1. IP = 10.1.1.104
2. Everything else is the same as the device configuration. Make sure you use the Static IP option
3. Make sure IPSec is not enabled
3) On the PC, navigate to My Documents\Microsoft .NET Micro Framework 3.0\Samples\DPWS and open the DPWS solution. This solution will load both the Micro Framework DPWS Hosted Service project and the Micro Framework DPWS Client. Make sure you start VS with elevated permissions (Run as administrator)
4) Connect the device to the PC
I am going to set up the solution to run the client in the emulator when I press F5, and to deploy the service to the device when I right click on the Service project, select “Debug” and then select “Start a new instance” My device is attached to COM 9. Also, I have modified both the Service and Client projects slightly to help decipher the Debug output. I added “SERVICE:” to all the debug prints in the Service project and “CLIENT:” to all the debug prints in the client project. This helps later to ascertain where a particular message is coming from.
1) On the main tool bar in VS, Select Build/Configuration Manager
a. Make sure the build box is selected for both projects, and the deploy box is checked for the client project and not for the service project
b. Close the dialog
2) Right Click on the Client project in the Solution Explorer and select Properties
a. Select the Micro Framework Tab and set the transport to Emulator and the Device to Microsoft Emulator
3) Back in the Solution Explorer, right click on the Service project and select Properties
a. Set the Transport and device to match your device, Serial and COM9 in my case
Now, when you hit F5 the Client will start up in the emulator. You can minimize the emulator UI since it is not used in this example. The VS Output window will let you know what the client is doing.
With the client running, Right click on the Server project in the Solution Wizard, and select “Debug/Start a new instance. This will cause the service to be deployed to the device and started. Then sit back and watch the client discover and exercise the service. At this point, you can set breakpoints in either project and debug as expected.
This scenario is very similar to the previous scenario 1a. About the only difference is that you set the Client properties to deploy to a device rather than the Emulator.
This Scenario requires that you have a WSDAPI client. It is beyond the scope of this article to describe how to build a WSDAPI client, but you can use the WSDAPI tool SvcUtil.EXE and the SimpleService WSDL to generate your stubs and proxies. There is lots of information about how to do this on the Microsoft.com site.
Scenario 1d: (Please see attached Visual Studio Solution Zip file for source )
This scenario is a little more challenging, since WCF does not currently support WS-Discovery. It is necessary to tell the client the endpoint address of the Service, and then all should work well. Visual Studio supports generating the necessary WCF stubs and proxies for the WCF client from the WSDL. It will also generate a configuration XML file with the same name as the client. In my case, the app is called:
WCFSimpleServiceApp.Exe (this one lists as an application)
and the configuration file is called:
WCFSimpleServiceApp.Exe (This one is listed as an XML Configuration file).
There is a client section near the bottom of this file. When you first see it, it will probable refer to localhost. You need to change three locations to point to the IP address of your device. In this file, the IP address is 192.168.0.3. The WCF client will use this configuration file to locate and connect with the Micro Framework service running on your device.
The contents of the file are:
?xml version="1.0" encoding="utf-8"?>
<textMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16"
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<httpTransport manualAddressing="false" maxBufferPoolSize="524288"
maxReceivedMessageSize="65536" allowCookies="false" authenticationScheme="Anonymous"
keepAliveEnabled="true" maxBufferSize="65536" proxyAuthenticationScheme="Anonymous"
realm="" transferMode="Buffered" unsafeConnectionNtlmAuthentication="false"
<endpoint address="http://192.168.0.3:8084/3cb0d1ba-cc3a-46ce-b416-212ac2419b90" binding="customBinding"
<endpoint address="http://192.168.0.3:8084/3cb0d1ba-cc3a-46ce-b416-212ac2419b91" binding="customBinding"
Scenario 2a is very similar to scenario 1a, with the only change being where you instruct the project to deploy to. In this scenario, you set the client to deploy to the device and the service to deploy to the emulator. Everything else is the same.
This scenario is the same as 1b, Make sure to start the client first, and then the service. As written, the Service sends a “Hello” and the client must be listening for it. Discovery can work both ways. However, Client initiated discovery is just not implemented in this sample.
WCF does not currently support WS-Discovery required for Micro Framework clients to discover and query WCF services. This is being addressed in two ways:
1) WS-Discovery will be supported in WCF in the .NET Framework 4.0
2) We are investigating implementing the WS-Discovery Remote Extensions proposal.
Jim MateerProgram Manager
Jim MateerProgram Manager