…Now the fun begins…, let’s code and we’ll get back to a few InfoCard concepts later…

Follow the following instructions:

1. Create a New Project. Choose the project type, for our walkthrough, let’s just pick a Console Application, and name your project "MyFirstHelloApp".

2. Add the references using Project | Add Reference…

3. Choose System.ServiceModel and Microsoft.InfoCards. Indigo and InfoCard applications primarily use System.ServiceModel, while Microsoft.InfoCard is normally used to catch a few exceptions thrown by InfoCard System.

4. Add the following "using" for C#:

using System.ServiceModel;
using Microsoft.InfoCards;

Now, you are ready to write your first hello world application. First, we’ll create the simplest HelloWorld Indigo client-service app; we’ll then add InfoCard binding that triggers the InfoCard UI on the client. To make it even simpler (for debugging purposes) we’ll even combine client and service code in one *.cs file. In normal cases, the service will be hosted by IIS.

For brevity, we will also omit catching exceptions. Note: There are many good Indigo samples in the WinFX SDK and other blogs; this exercise is just a stepping block to get into InfoCard.

What we’re building. We’ll be building a simple client and service app. Service will implement a contract in an interface called IHello. The client will call this interface. In the next posting, we’ll modify the app.config to trigger the InfoCard UX on the client.


Add the following code:

namespace MyFirstHelloApp
{

[ServiceContract]
interface IHello
{
  [OperationContract]
  string Say();
}

class Hello : IHello
{
 
public string Say()
  {
  
return "Hello World";
  }
}

class Program
{
  
static void Main(string[] args)
  
{

   /////////////////////////////////////////////////
  
// Service Code
  
/////////////////////////////////////////////////
  
ServiceHost<Hello> sh = new ServiceHost<Hello>( new Uri("http://localhost:4123/myService"));
   sh.Open();
  
Console.WriteLine("Listening....");

  /////////////////////////////////////////////////
 
// Client code
 
/////////////////////////////////////////////////
 
ChannelFactory<IHello> cnFactory = new
  ChannelFactory<IHello>("myClient");
 
IHello chn = cnFactory.CreateChannel();

 
Console.WriteLine(chn.Say());

 
// Clean up
 
cnFactory.Close();
 
sh.Close();

  }

 }

}

That’s it! for both the client and service.  The service which implement IHello is listening at http://localhost:4123/myService (I just picked an arbitary port); The service implement IHello:Say(), which nothing more than returning "Hello World" string. The client’s channel information will be read from "myClient" configuration in the app.config.

Next step, add App.Config to configure the binding, address, and contract (since we combine the service and the client, this app.config is for both the service and the client)

To create App.Config:
  
1. From Project, select Add New Item
  
2. Select "Application Configuration File", and click Add.

Add the following XML segments:

<configuration>
<system.serviceModel
>
  <
bindings
>
  
<
customBinding
>
      
<
binding configurationName="myBinding"
>
      
<
httpTransport
/>
 </
binding
>
 
</
customBinding
>
</
bindings>

<services>
  
<
service serviceType="MyFirstHelloApp.Hello">
  
<
endpoint address="endpoint1" contractType="MyFirstHelloApp.IHello" bindingSectionName="customBinding" bindingConfiguration="myBinding" />
 
</
service>
</
services>
<
client>
  
<
endpoint configurationName="myClient" address="http://localhost:4123/myService/endpoint1" contractType="MyFirstHelloApp.IHello" bindingSectionName="customBinding" bindingConfiguration="myBinding">
  
</
endpoint>
</client>
</system.serviceModel>
</configuration>

Build and set break points, and debug…., you should see the following outputs:
Listening....
Hello World

You may want to set one break point on IHello:Say implementation, so you’ll see when the code transition from client to service (and vice versa).

As seen in the app.config, we’re using http as the transport binding, both the client and the service point to the binding. Since the address, binding and contract are the same, the client and the service will be able to communicate. One thing that I really like about this model is to separate code implementation from the infrastructure. Later, if I would like to change my transport ( for example, namepipe or tcp-ip), I do not have to change the code (in few cases, only minimal code modifications) – I just need to modify my App.Config.

It’s not too bad, is it?