TadSharp .Net

Flickr WCF Part II - Hosting WCF Components In-Process

Tad — Mon, 16 Feb 2009 22:38:08 +0000

This is Part Two in an on-going series of articles about WCF components, all centered around a simple component I created to talk to the Flickr api. You can find Part I here.

Now that we’ve hosted the Flickr WCF component in IIS, let’s take the same service definition and implementation and do something more interesting with them than just spitting out a list of URLs. It would be cool if we could see each of the pictures and cycle through them. And, so that I can point out a potential WCF gotcha, let’s do this in a WinForms application.

Let’s also host the component in process. In process components should always use named pipes. I’ve found that the easiest possible way to host a component in process is by using Juval Lowy’s ServiceModelEx library. You can download the library at this link. We’ll use his InProcFactory class which he describes in some detail on pages 60-63 of his WCF Bible, “Programming WCF Services.”
With InProcFactory all you need to do is to add references to the class libraries which contain your component’s contracts and implementation.

Then you can make calls like this:


IMyContract proxy = InProcFactory.CreateInstance();
proxy.MyMethod();
InProcFactory.CloseProxy(proxy);

Notice that when we use InProcFactory we don’t have to worry about setting up hosts, config files, or really worry about anything other than our interfaces and implementation classes. This is almost as easy creating regular c# objects with the new keyword! Using named pipes is also the fastest and most secure way to deal with WCF components.

So, for this example, let’s create a new Windows Forms Application and name it WCFInProcFlickrApp. Add references to your BasicFlickrWCFContracts and FlickrInfoService dlls as well as Juval Lowy’s ServiceModelEx library.

Add a new Form and call it Viewer. Add a PictureBox (picBox) and two buttons (btnNext and btnPrev). Make your form look like this:

Now let’s make sure that we can connect to our WCF component without any problems. Double click the View form and then add code to the Viewer_Load method that looks like this:


        private void Viewer_Load(object sender, EventArgs e)
        {

            IFlickrInfo proxy = ServiceModelEx.InProcFactory.CreateInstance();

            photos = proxy.GetRecentPhotos();

            ServiceModelEx.InProcFactory.CloseProxy(proxy);

            picBox.ImageLocation = photos[0].Url;
        }

Now try running the app. When you run this you should expect the picture box to show the first image returned by component. Instead the application hangs for a long time and eventually you’ll get an error message that looks like this:

The problem here is that we’ve hosting the component in-process after the UI thread has started. This causes the component to run on the UI thread associated with the form. The UI thread’s message loop acts as a throttle for message processing. When the form calls the service in-process like this that call blocks the UI thread while WCF posts a message to the UI thread to invoke the service. We’re stuck in a loop now because of the blocking UI thread and hence we end up with this deadlock shown in the error above.

The problem is that WCF components have the UseSynchronizationContext attribute set to true by default. When this behavior is set to true, the component gains thread affinity with the code that called it. In our WinForms app this makes a big difference because of the message loop. One really simple way to fix this would be to decorate our implementation class with the following attribute which sets that context to false:


[ServiceBehavior(UseSynchronizationContext=false)]

This removes the thread affinity and lets our component run on its own thread, eliminating the blocking and deadlock issue. In this example I don’t want to go this route, because I’ve already created my component and it works just fine. I would only be adding this attribute to help it work in this one case. This is starting to smell like coupling, which I try to avoid if at all possible. Either way, now that my contracts and implementation are in dlls, I don’t want to have to go and recompile them just to get them to work for WinForms. There’s got to be another way.

Fortunately there is. All we need to do is to start hosting the component before the UI thread is set. To do this, we need to create the host in the Main method that starts the WinForms app. This method can be found in the Program.cs file in the solution. Now we run into another problem. The way that Lowy wrote InProcFactory, the service host is created, if needed, when you make the call to CreateInstance. If I put this call in the Main method then I’ll need something like a global variable to hook into in my Viewer form that would be of no use to other forms in my project. That’s a pretty stinky code smell too.

To solve this issue, I created a new static method on InProcFactory - CreateHost. The method is as follows:


      public static void CreateHost()
          where I : class
          where S : class, I
      {
          if (m_Hosts.ContainsKey(typeof(S)))
          {
              return;
          }

          HostRecord hostRecord;
          ServiceHost host;

          if (m_Singletons.ContainsKey(typeof(S)))
          {
              S singleton = m_Singletons[typeof(S)] as S;
              Debug.Assert(singleton != null);
              host = new ServiceHost(singleton, BaseAddress);
          }
          else
          {
              host = new ServiceHost(typeof(S), BaseAddress);
          }

          string address = BaseAddress.ToString() + Guid.NewGuid().ToString();
          hostRecord = new HostRecord(host, address);

          m_Hosts.Add(typeof(S), hostRecord);

          host.AddServiceEndpoint(typeof(I), Binding, address);          

          if (m_Throttles.ContainsKey(typeof(S)))
          {
              host.SetThrottle(m_Throttles[typeof(S)]);
          }

          host.Open();
      }

This is almost a verbatim copy and paste of the GetHostRecord method that’s already in ServiceModelEx. Yes, I can and should refactor out the similarities, but for the purposes of this article I think it’s helpful to see what’s going on. CreateHost creates a new Named Pipe in-proc host just like CreateInstance does. Since it’s a static method on a static class, the host will stick around after the Viewer form is created. When CreateInstance is called, InProcFactory will see that our host has already been created and will use that one. In this way we don’t gain thread affinity with the UI thread.

So now, change the code in the Main method inside Program.cs to look like this:


        [STAThread]
        static void Main()
        {
            InProcFactory.CreateHost();
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            Application.Run(new Viewer());
        }

You can now run the application again and you should see the first picture returned back in the picture box. To round out our little app, hook in the buttons click events (by double clicking each of them) and then add code to them like this (as well as adding the ShowCurrentImage method):


        private void btnNext_Click(object sender, EventArgs e)
        {
            currentIndex++;
            if (currentIndex > 99)
            {
                currentIndex = 0;
            }
            ShowCurrentImage();
        }

        private void ShowCurrentImage()
        {
            picBox.ImageLocation = photos[currentIndex].Url;
        }

        private void btnPrev_Click(object sender, EventArgs e)
        {
            currentIndex--;
            if (currentIndex < 0)
            {
                currentIndex = 99;
            }
            ShowCurrentImage();
        }

Now you can use the Next and Prev buttons to cycle through all of the interesting photos returned back from Flickr! The part about all of this that I like the most is that we didn’t have to change our component at all in order to do any of this. Hurray for component reuse!

All of this same information can be used in WPF applications as well. I’m not really familiar with WPF applications, but I understand you can configure your WPF application to use a custom Main method by right-clicking the App.xaml file, selecting Properties, and setting the Build Action to “Page.” Now create a static class Program.cs in the root and insert a Main() method like this:


public static class Program
{
    [STAThread]
    static void Main()
    {
        WPFClient.App app = new WPFClient.App();
        app.InitializeComponent();
        app.Run();
    }
}

I haven’t actually tried this, but if you have any problems with this method in WPF, please leave a comment below and I’ll do some research for you.

Here’s a copy of my WCFInProcFlickrApp source.

Here’s a copy of my enhanced version of ServiceModelEx.

REFERENCES:
For a much better explanation of InProcFactory, please see “Programming WCF Services” pages 60-63.
“Programming WCF Services” - Chapter 8 pages 388 through 413 were very helpful.
Peter De Jonghe’s post on the MSDN WCF forums.
Jeremy Wiebe’s “WCF service blocking when self-hosting (or How the ServiceBehavior’s Use SynchronizationContext parameter saved me)”
Code Magazine’s article about WCF Hosting, Page 3

StackOverflow update

Tad — Thu, 12 Feb 2009 05:40:06 +0000

I have recently had two of my WCF related answers to questions on StackOverflow rated as top answers!

Are Enterprise Level DataContracts a Good Practice?

Logic first, WCF security later?

I enjoy going through the StackOverflow questions that are tagged as WCF related on a near daily basis. I have learned an awful lot just reading other people’s answers and sometimes the questions inspire me to go learn something I hadn’t thought about.

Also, tonight I asked:

What are your favorite resources concerning RESTful WCF?

If you have a good answer, I’d love to hear it!

Flickr WCF Part I - Basic Manual WCF Component

Tad — Tue, 10 Feb 2009 16:46:40 +0000

This is the first part in a series of blog posts where I see how many different aspects of WCF I can exercise with the same basic component definition. In this article we’re going to define our contracts, create a service, create a IIS host, hand-code a proxy and have a Console app spit out URLs to the 100 most recent photos uploaded to Flickr.

This and subsequent articles assume some basic working knowledge of WCF. If you’ve worked your way through a couple of tutorials, you’ll be fine.

The basic logic of the calling out to Flickr and the extension method I use are described in the previous blog post which is a prelude to this series. Please take a look at that article if you have trouble following along.

For simple cases like the one we’re working on here, I find that hand coding all of the WCF logic is the easiest and most straightforward way to make my code work. Using the svcutil.exe or the Add Service Reference feature in VS 2008 works, but both methods add unnecessary cruft that add to the complexity and understanding of the code. So, here we go!

Our objective is to call the Flickr API getting information about the 100 photos flickr deems interesting for the day, extract out of the XML the necessary information to create URLs to the medium sized jpg and then spit the URLs out to the console window. The first thing we’ll do is create a Class Library project called BasicFlickrWCFContracts in a solution named BasicFlickrWCFApp. Add references for System.ServiceModel and System.Runtime.Serializations.

In this solution, add a new class file named FlickrPhoto.cs. The code for FlickrPhoto will look like this:

   
using System;    
using System.Runtime.Serialization;
  namespace Donaghe.FlickrInfoComponent   
{    
[DataContract]    
public class FlickrPhoto    
{    
string farm = string.Empty;    
string server = string.Empty;    
string id = string.Empty;    
string secret = string.Empty;    
string owner = string.Empty;    
string title = string.Empty;    
string url = string.Empty;    
string flickrUrl = string.Empty;
  [DataMember]   
public string Farm    
{    
get { return farm; }    
set { farm = value; }    
}
  [DataMember]   
public string Server    
{    
get { return server; }    
set { server = value; }    
}
  [DataMember]   
public string Id    
{    
get { return id; }    
set { id = value; }    
}
  [DataMember]   
public string Secret    
{    
get { return secret; }    
set { secret = value; }    
}
  [DataMember]   
public string Owner    
{    
get { return owner; }    
set { owner = value; }    
}
  [DataMember]   
public string Title    
{    
get { return title; }    
set { title = value; }    
}
  [DataMember]   
public string Url    
{    
get { return url; }    
set { url = value; }    
}
  [DataMember]   
public string FlickrUrl    
{    
get { return flickrUrl; }    
set { flickrUrl = value; }    
}    
}    
}

This class definition is basically just a plain vanilla WCF data contract. We will use this class to help us build our photo URLs.

Now add an interface file to your project. Name is IFlickrInfo.cs. This will define a single operation to return recent Flickr photos. The code is simple and looks like this:

   
using System;    
using System.Collections.Generic;    
using System.Linq;    
using System.Text;    
using System.ServiceModel;
  namespace Donaghe.FlickrInfoComponent   
{    
[ServiceContract]    
public interface IFlickrInfo    
{    
[OperationContract]    
List GetRecentPhotos();    
}    
}

The next step is to create the service which will give life to our new ServiceContract. Create a new Class Library project and name it FlickrInfoService. Add a reference to System.ServiceModel as well as a Project Reference to the BasicFlickrWCFContracts project.

I use an extension method that I created for System.Net.WebClient as described in the previous blog post. You can either create this yourself or download a copy of my extensions dll here. If you use my dll, add a reference to it and you’ll need to add a using statement in your code like this:

   
using TadsExtensions;

Add a new class file to this project and name it FlickrInfoService.cs. Copy and paste this code into it:

   
using System;    
using System.Collections.Generic;    
using System.Linq;    
using System.Net;    
using System.ServiceModel;    
using System.Text;    
using System.Xml.Linq;    
using TadsExtensions;
  namespace Donaghe.FlickrInfoComponent   
{    
public class FlickrInfoService : IFlickrInfo    
{    
#region IFlickrInfo Members
  public List GetRecentPhotos()   
{    
List photos = new List();
  XElement x = (new WebClient()).DownloadXElement("http://api.flickr.com/services/rest/?method=flickr.interestingness.getList&amp;amp;amp;amp;api_key=YOURFLICKRAPIKEYHERE");
  var query = from b in x.Elements("photos").Elements("photo")   
select new FlickrPhoto    
{    
Farm = b.Attribute("farm").Value,    
Id = b.Attribute("id").Value,    
Secret = b.Attribute("secret").Value,    
Server = b.Attribute("server").Value,    
Owner = b.Attribute("owner").Value,    
Title = b.Attribute("title").Value    
};
  foreach (FlickrPhoto photo in query)   
{    
StringBuilder urlBuilder = new StringBuilder();
  urlBuilder.Append("http://farm");   
urlBuilder.Append(photo.Farm);    
urlBuilder.Append(".static.flickr.com/");    
urlBuilder.Append(photo.Server);    
urlBuilder.Append("/");    
urlBuilder.Append(photo.Id);    
urlBuilder.Append("_");    
urlBuilder.Append(photo.Secret);    
urlBuilder.Append("_m.jpg");
  photo.Url = urlBuilder.ToString();
  StringBuilder urlBuilder2 = new StringBuilder();
  urlBuilder2.Append("http://www.flickr.com/photos/");   
urlBuilder2.Append(photo.Owner);    
urlBuilder2.Append("/");    
urlBuilder2.Append(photo.Id);
  photo.FlickrUrl = urlBuilder2.ToString();
  photos.Add(photo);   
}
  return photos;   
}
  #endregion   
}    
}

The bulk of this code is explained in the my previous blog entry. Please see it if you need a better understanding of what’s going on.

Of interest is the code that sets the photo.Url and photo.FlickrUrl. The Url is the link to the actual photograph and the FlickrUrl is a link to the page on Flickr where you can view the photo in the owner’s photostream. This code follows the simple recipe given by Flickr on this page. For this solution we’re only interested in photo.Url. In my Flickr Toy app, I use photo.FlickrUrl to allow users to click a photo and go to its Flickr page.

Now it’s time to create a host for our component. In this case we’ll create an IIS host. I find IIS hosts very simple to implement and use. So, go to File->New->Project->ASP.NET Web Application. Name it FlickrInfoIISHost.

Delete the Default.aspx page - we won’t need it. Add Project references to BasicFlickrWCFContracts and FlickrInfoService. Now add a plain text file to the project. Name it FlickrInfoIISHost.svc. Edit the file to look like this:

[sourcecode language="asp"]
<%@ ServiceHost Service=”Donaghe.FlickrInfoComponent.FlickrInfoService” %>
[/sourcecode]

Open the Web.config file and paste the following code down at the bottom just before the configuration end node:

Find the compilation tag and set its debug attribute to true like this:

I like to specify the port for my IIS hosting projects manually. To do this, right click on the FlickrInfoIISHost project and choose Properties. Click the Web tab and make sure the “Specific Port” radio button is selected. For this example I set the port to 51030. You’ll see why when we create our client.

Now let’s try our host and see if it’s working properly. In Solution Explorer, right click the FlickrInfoIISHost project and chose “Set as Startup Project” from the context menu. Now run the solution by pressing ctrl-F5. This will start the service and will probably show a web page in your default browser just showing a directory listing. This isn’t what we’re interested in. Append FlickrInfoIISHost.svc to the end of the URL shown in the page that opened up. Now you should see the default WCF page showing how to set up Metadata Exchange which we’re going to ignore in this tutorial. This is good enough to let you know that your service is being hosted.

Next we need to create a proxy which will be used by our client to communicate with our new host. Most WCF tutorials have you create a proxy by adding a Service Reference or by using svcutil.exe. Here we’ll do it manually. It’s awfully simple, actually.

So, add a new Class Library project to your solution and name it FlickrInfoProxy. Change the name of the class file that’s been added for you to FlickrInfoProxy.cs. Add a Project Reference to BasicFlickrWCFContracts and a reference to System.ServiceModel. Now replace the code in your class with this code:


using System;
using System.Collections.Generic;
using System.Linq;
using System.ServiceModel;
using System.Text;

namespace Donaghe.FlickrInfoComponent
{
public class FlickrInfoProxy : ClientBase, IFlickrInfo
{
#region IFlickrInfo Members

public List GetRecentPhotos()
{
return Channel.GetRecentPhotos();
}

#endregion
}
}

Our proxy is a subclass of the ClientBase generic class based on our IFlickrInfo interface. Our proxy will also implement the IFlickrInfo interface. ClientBase gives us the proxy magic. It creates a WCF communications channel between our client (which specifies the host in its configuration) and our host. Implementing IFlickrInfo allows our proxy to call the proper method at the right time. We only have one method in our interface and our proxy just passes the call on to the host.

Building a proxy in this way allows us to reuse it with any number of other clients. It will be built as a dll and can be referenced whenever a client needs it without polluting the client project with irrelevant details. Proxies can become a lot more complex, as you can see if you ever create one by adding a ServiceReference, but in simple cases, why not use a simple proxy?

Now for the client. In this example we will create a super simple console application client. So, add a new Console Application to the solution and name it FlickrInfoClient. Add Project references to BasicFlickrWCFContracts and FlickrInfoProxy as well as a reference to System.ServiceModel.

Replace the code in Program.cs with this code:


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Donaghe.FlickrInfoComponent
{
class Program
{
static void Main(string[] args)
{
FlickrInfoProxy proxy = new FlickrInfoProxy();

Console.WriteLine("Getting recent Flickr photos...");

using (proxy as IDisposable)
{
List photos = proxy.GetRecentPhotos();

foreach (FlickrPhoto photo in photos)
{
Console.WriteLine(photo.Url);
}
}

Console.WriteLine("Press the ENTER key to end this program...");

Console.ReadLine();
}
}
}

First we create a new instance of our proxy. The using line allows us to treat our Proxy as IDisposable. This lets us not need to worry about opening and closing the communications channel to the host. It’s done for us automatically. The rest of the code in the using block is straightfoward and shows just how easy it is to deal with a WCF component that’s hosted by IIS. Of course, we’d use the same exact code if the component was hosted on another machine in a Windows Service and accessed via NetTCP.

This isn’t everything we need though. Our client needs to contain information so that the proxy knows how to talk with the host. We’ll put this information into an App.config file. So, right click on the client project and chose Add New Item and in the dialog choose Application Configuration File. This will add a new file named App.config. Make your App.config file look like this:




binding="wsHttpBinding"
contract="Donaghe.FlickrInfoComponent.IFlickrInfo"
/>

In our client configuration we always need to specify the ABC’s of WCF. Address, Binding and Contract. The address is, unsurprisingly the address to the .svc file that we put in our IIS Host. Note that the port used is the same as the one we specified in the host. The binding is also the same as what we configured on the host side. The contract is the fully qualified name of our component’s interface.

Here’s how to run and test our WCF application. First, press ctrl-F5 to run the IIS host. Now, while the host is running, right click on the client project and chose Debug->Start new instance. This will open the Console window and run the client code. Your results should look something like this:

In subsequent articles we’ll use this same component and extend it and exercise many WCF features with it. Coming up we’ll create a simple Windows Form application and use our component in-process.

I am by no means an expert in this, so please feel free to leave a comment if you’ve spotted a bug, or a better way to do something or even any criticism you have. I appreciate it!

Here is a zip file containing all of the source code in the application talked about above: Basic Flickr WCF App

Calling the Flickr API getRecent method with c# and Linq to XML

Tad — Sat, 07 Feb 2009 18:05:02 +0000

UPDATE: I have updated this article to now use the flickr.interestingness.getList method instead of getRecent. I love getRecent, but out of every 3 to 400 pictures there’s almost always one or two pictures that most audiences would consider offensive. All of the photos returned by flickr.interestingness.getList are artistic and very few of them would be considered offensive by most people.

One of my favorite features of Flickr is browsing through photos that have just been uploaded. You can get a glimpse of this on Flickr’s home page, but I decided I’d write some code so I could look at a bunch of them all at once. I also like making calls against other web API’s (like from Twitter, FriendFeed or delicious).

Here’s a sample of the kind of code you might write to call Flickr:


using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using System.Net;

namespace CurrentFlickrPicsConsoleExample
{
class Program
{
static void Main(string[] args)
{
string currentPicsXML = GetCurrentFlickrPicsXML();
Console.WriteLine(currentPicsXML);
Console.WriteLine();
Console.WriteLine("Press ENTER to exit this app...");
Console.ReadLine();
}

private static string GetCurrentFlickrPicsXML()
{
string result = new WebClient().DownloadString("http://api.flickr.com/services/rest/?method=flickr.interestingness.getList&amp;api_key=YOURFLICKRAPIKEY");

return result;
}

}
}

If you want to execute this code, copy it and paste it into a new Console application and be sure to replace ‘YOURFLICKRAPIKEY’ with your key. Instructions to get a Flickr API key are here.

A subset of the XML returned from Flickr looks like this:

In order to get the Linq to XML magic, you need to create a System.Linq.Xml.XElement object. The XElement can parse the XML string. I created this extension to System.Net.WebClient to make the process super simple:


public static XElement DownloadXElement(this System.Net.WebClient webClient, string address)
{
string result = webClient.DownloadString(address);

XElement x = XElement.Parse(result);

return x;
}

Assuming I have a class created called Photo, I can write this super simple Linq to XML code to create an IEnumerable collection of photos (assuming x is of type XElement):


XElement x = (new WebClient()).DownloadXElement("http://api.flickr.com/services/rest/?method=flickr.interestingness.getList&amp;api_key=YOURFLICKRAPIKEY");

var query = from b in x.Elements("photos").Elements("photo")
select new Photo
{
Farm = b.Attribute("farm").Value,
Id = b.Attribute("id").Value,
Secret = b.Attribute("secret").Value,
Server = b.Attribute("server").Value,
Owner = b.Attribute("owner").Value,
Title = b.Attribute("title").Value
};

foreach (Photo photo in query)
{
photos.Add(photo);
}

This query is very simple - we just loop through all of the photo elements which are children of the photo element. At each photo, we create a new Photo object, reading its values from the attributes of the xml photo. Those Photo objects then go into the result of the query, query, which we know implements IEnumerable. Its actual type is irrelevant to use since we’re only interested in its IEnumerable implementation.

For the purposes of this article, we can put all these pieces together into one console app, call the Flickr API, receive the XML, parse it into a collection of Photo objects and then spit out the photo urls for each of those objects.

I have created a web application using this code. I call it “Tad’s Flickr Toy - Interestingness.” You can view this application here.

This article is sort of a prelude to a series of articles using a WCF component built around this code. In the series I will be hosting and using the component in all sorts of scenarios, showing how to use WCF in many different ways.

Best of WCF, January 25, 2009

Tad — Mon, 26 Jan 2009 04:00:44 +0000

Two way client server network communication

A question on StackOverflow about 2 way WCF communication. The answers provide some excellent links to resources concerning WCF duplex messaging. Chapter 5 of Juval Lowy’s excellent Programming WCF Services has a lengthy discussion on Duplex messenges including Server/Client event models - really cool stuff!

Async Operations in WCF: Event Based Model

Along the same lines, I found this gem of a 5 part series on two-way messaging in WCF the other day. Excellent article - I hope to have a screencast and sample solution of my own concerning Events in WCF before long.

Manual WCF - An extension

Tad — Mon, 19 Jan 2009 05:14:31 +0000

While going through the WCF questions on StackOverflow a few days ago, I found a link to an excellent article on setting up WCF manually from bottom to top written by Miguel A. Castro for Code Magazine. You can find the article here. Please go and read it before proceeding.

The thrust of the article is to show how to create a WCF contract, service, host, proxy and client without relying on Visual Studio or other external tools to create anything for you. In particular Castro prefers to create his own .config files and proxies.

In the article, Castro shows two different ways to set up a client proxy for his service. The author of the question that lead me to the article had trouble with one of the proxies, shown below:

    
using System;    
using System.ServiceModel;
  namespace CoDeMagazine.ServiceArticle   
{    
public class AdminClient : IProductAdmin    
{    
public AdminClient()    
{    
IProductAdmin productAdminChannel =    
new ChannelFactory().    
CreateChannel();    
}
  IProductAdmin productAdminChannel = null;
  #region IProductAdmin Members
  public void UpdateProduct(   
ProductData product)    
{    
productAdminChannel.UpdateProduct(    
product);    
}
  public void DeleteProduct(Guid productID)   
{    
productAdminChannel.DeleteProduct(    
productID);    
}
  #endregion   
}
  }

The problem here is that as far as I can see, I can only get this to work by referencing the endpoint name pointed to by the client. If I change constructor to look like this:


  public AdminClient()   
{    
IProductAdmin productAdminChannel =    
new ChannelFactory("endpointName").    
CreateChannel();    
}

given an endpoint configuration in the client like:

http://localhost:9224/ProductService.svc
binding="wsHttpBinding"
name="endpointName"
contract="CoDeMagazine.ServiceArticle.
IProductBrowser" />

it works! I’m not sure if Mr Castro is just wrong or if there’s something that I and the other folks on StackOverflow missed.

Either way, I created a sample project to share and a very brief screen cast to go along with it. My example is simpler, but fully working - you shouldn’t have to do any extra work to get it up and running and you can apply the concepts in your own work.

ManualWCFExample

View the screencast here.

I may well have made a goof or error in this post, the code linked, or in the screencast. If you find something you’d like to correct, feel free to leave a comment below.

Thanks for reading!