# Thursday, May 13, 2010

Recently I extended a previous blog post and published it on Code Project under the title Generic WCF Service Host and Client. An astute reader asked about calling a service method asynchronously, something I had not given much thought.

I decided that I wanted a way to support asynchronous calls on the generic WCF client without having to modify my service contract (interface) or implementation class libraries. I also wanted a way to do asynchronous calls with as little client code as possible, which meant support for a simple event based solution.

So I went to work experimenting. If you want the WCF version of the solution, visit the Code Project article and you can get the updated code there just as soon as I get an update published.

In this post, I'll present a more generalized version of the solution I created. The GenericAsyncWrapper<T> class is the heart of the solution. Take any instance of T (any class) and GenericAsyncWrapper<T> puts an event based asynchronous wrapper that allows you to call any method on the instance asynchronously.

I'm not going to explain how standard delegates are used to make asynchronous calls. If you want to brush up on the basics, check out Microsoft's How to call a Visual C# method asynchronously along with thousands of other online resources. I will show some examples of using standard generic delegates to do the asynchronous calls to compare with the use of the generic wrapper's event model.

Here's my test class. It does nothing, as you can see, but it does allow me to test my wrapper.

internal class MyTestClass
{
  public void DoNothingNoParams()
  {
    Console.WriteLine("MyTestClass.DoNothingNoParams called on thread: {0}", 
      Thread.CurrentThread.ManagedThreadId);
  }

  public string DoSomething(string input)
  {
    Console.WriteLine("MyTestClass.DoSomething called on thread: {0}", 
      Thread.CurrentThread.ManagedThreadId);
    return "Output of DoSomething with " + input + " as input.";
  }
}

And here's the test code. Just a simple console app that first shows the test class being called directly, then using standard generic delegates and finally using the wrapper. One advantage you may note is that with the wrapper, you also get all your original input params back.

class Program
{
  static void Main(string[] args)
  {
    Console.WriteLine("Main called on thread: {0}", Thread.CurrentThread.ManagedThreadId);
    Console.WriteLine("+++++++++++++++++++++++++++++++++++++++++++++");
    Console.WriteLine("synchronous calls");
    var mytest = new MyTestClass();
    mytest.DoNothingNoParams();
    string output = mytest.DoSomething("my name is Tyler");
    Console.WriteLine(output);

    Console.WriteLine("+++++++++++++++++++++++++++++++++++++++++++++");
    Console.WriteLine("Action<> and Func<> delgate calls");
    Action action = new Action(mytest.DoNothingNoParams);
    action.BeginInvoke(new AsyncCallback(ActionCallback), "test1");

    Func<string, string> func = new Func<string, string>(mytest.DoSomething);
    func.BeginInvoke("my name is Arnold", new AsyncCallback(FuncTTCallback), "test2");

    Thread.Sleep(1000);

    Console.WriteLine("+++++++++++++++++++++++++++++++++++++++++++++");
    Console.WriteLine("asynchronous wrapper calls");
    var wrapper = new GenericAsyncWrapper<MyTestClass>(mytest);
    wrapper.AsyncCompleted += new EventHandler<GenericAsyncWrapperCompletedEventArgs>(wrapper_AsyncCompleted);
    wrapper.AsyncInvoke("DoSomething", "test2", "my name is Bob");
    wrapper.AsyncInvoke("DoNothingNoParams", "test1", null);

    Console.ReadLine();
  }

  static void FuncTTCallback(IAsyncResult result)
  {
    Console.WriteLine("FuncTTCallback called on thread: {0}", Thread.CurrentThread.ManagedThreadId);
    Thread.Sleep(250);
    Func<object, object> deleg = ((AsyncResult)result).AsyncDelegate as Func<object, object>;
    if (deleg != null)
    {
      object returnValue = deleg.EndInvoke(result);
      Console.WriteLine("FuncTTCallback return value: {0}", returnValue);
    }
  }

  static void ActionCallback(IAsyncResult result)
  {
    Console.WriteLine("ActionCallback called on thread: {0}", Thread.CurrentThread.ManagedThreadId);
    Thread.Sleep(250);
    Action deleg = ((AsyncResult)result).AsyncDelegate as Action;
    if (deleg != null)
    {
      deleg.EndInvoke(result);
    }
  }

  static void wrapper_AsyncCompleted(object sender, GenericAsyncWrapperCompletedEventArgs e)
  {
    Console.WriteLine("wrapper_AsyncCompleted called on thread: {0}", Thread.CurrentThread.ManagedThreadId);
    if (e.Error == null)
    {
      Console.WriteLine("methodName: {0}, userState: {1}, result: {2}", 
        e.MethodName, e.UserState, e.Result);
      if (e.InValues != null)
      {
        for (int i = 0; i < e.InValues.Length; i++)
        {
          Console.WriteLine("   value[{0}] = {1}", i, e.InValues[i]);
        }
      }
    }
    else
    {
      Console.WriteLine(e.Error.ToString());
    }
  }
}

Now here's the real magic. The GenericAsyncWrapper<T> class and its attendant event args class.

public class GenericAsyncWrapper<T> where T : class
{
  private T _instance;

  public GenericAsyncWrapper(T instance)
  {
    if (instance == null) throw new NullReferenceException("instance cannot be null");
    _instance = instance;
  }

  public T Instance { get { return _instance; } }

  public event EventHandler<GenericAsyncWrapperCompletedEventArgs> AsyncCompleted;

  public void AsyncInvoke(string methodName, object userState, params object[] inValues)
  {
    if (string.IsNullOrEmpty(methodName)) throw new NullReferenceException("methodName cannot be null");
    MethodInfo mi = this.Instance.GetType().GetMethod(methodName);
    if (null != mi)
    {
      Func<MethodInfo, object[], object> func = new Func<MethodInfo, object[], object>(this.ExecuteAsyncMethod);
      func.BeginInvoke(mi, inValues, new AsyncCallback(this.FuncCallback), 
        new GenericAsyncState() { UserState = userState, MethodName = methodName, InValues = inValues });
    }
    else
      throw new TargetException(string.Format("methodName {0} not found on instance", methodName));
  }

  private object ExecuteAsyncMethod(MethodInfo mi, object[] inValues)
  {
    return mi.Invoke(this.Instance, inValues);
  }

  private void FuncCallback(IAsyncResult result)
  {
    var deleg = (Func<MethodInfo, object[], object>)((AsyncResult)result).AsyncDelegate;
    var state = result.AsyncState as GenericAsyncState;
    if (null != deleg)
    {
      Exception error = null;
      object retval = null;
      try
      {
        retval = deleg.EndInvoke(result);
      }
      catch (Exception e)
      {
        error = e;
      }
      object userState = state == null ? null : state.UserState;
      string methodName = state == null ? (string)null : state.MethodName;
      object[] inValues = state == null ? null : state.InValues;
      GenericAsyncWrapperCompletedEventArgs args = new GenericAsyncWrapperCompletedEventArgs(retval, error, methodName, userState, inValues);
      if (this.AsyncCompleted != null)
        this.AsyncCompleted(this, args);
    }
  }

  private class GenericAsyncState
  {
    public object UserState { get; set; }
    public string MethodName { get; set; }
    public object[] InValues { get; set; }
  }
}

public class GenericAsyncWrapperCompletedEventArgs : EventArgs
{
  public GenericAsyncWrapperCompletedEventArgs(object result, Exception error, string methodName, object userState, object[] inValues)
  {
    this.Result = result;
    this.Error = error;
    this.MethodName = methodName;
    this.UserState = userState;
    this.InValues = inValues;
  }
  public object Result { get; private set; }
  public Exception Error { get; private set; }
  public string MethodName { get; private set; }
  public object UserState { get; private set; }
  public object[] InValues { get; private set; }
}

You can download the code here GenericUtils.zip (7.33 KB). If you find it useful, I'd love to hear from you. If you think this was a total waste of time, turn the TV back on.

posted on Thursday, May 13, 2010 2:39:41 PM (Mountain Daylight Time, UTC-06:00)  #    Comments [0]
# Wednesday, May 12, 2010

Do you have a hard time making decisions? Even the most decisive of us can get caught in the headlights of the oncoming project train, unable to choose left, right or straight ahead. Here’s a few strategies that I’ve found useful and sometimes forgotten about while stuck on the software development analysis thought pot.

  1. Ready, aim, fire! Research, evaluate, decide. Hesitation breeds doubt. Doubt is the father of indecision. Make a reasonable degree of confidence your standard and avoid looking for absolute guarantees. There are none.
     
  2. Put away fear of failure and accept the fact that there is more than one acceptable outcome to life’s challenges, including your project. Learn from mistakes but don’t be too afraid to make new ones.
     
  3. Begin. Make a start. Act. No journey or decision can ever be taken without the first step. Make a small decision, take action and then improve on your progress by evaluating regularly. Take digestible course correction decisions. Don’t derail your project by overcorrecting and rolling the bus at full speed.
     
  4. Set a decision deadline and stick to it. Lay out an incremental research and evaluation plan with a list of questions you need answers to in order to make your decision. If you don’t have a perfect answer, enumerate what you have anyway and incorporate it into your final decision.
     
  5. When the problem is too big and the decision too overwhelming, break it down into smaller, more specific pieces. Apply the strategies you find effective on the more manageable elements. Do that until you’ve put all the pieces together and before you know it, the puzzle will be complete.
     
  6. If the outcomes of the decision, regardless of the choice, are equally acceptable, flip a coin. Move on. Don’t waste time dwelling on equally acceptable paths to different but relatively satisfying conclusions.
     
  7. Go crazy. Make a choice even if you don’t have a reasonable level of confidence. Get off the ice berg and start swimming. Something will happen and that will lead to something else. It might turn out to have been a mistake, but at least you’ll have momentum on your side. A moving car is far easier to turn around than one that is parked.
     
  8. Put things into perspective. This project decision you’re worrying about, the one keeping you up at nights. Can it compare with watching your kid’s school play? Will your client attend your kid’s wedding? Or your funeral? Beyond successful completion or abject miserable failure on the project, will the outcome have a permanent impact on your life in the long term? Will it matter to your grandkids? Perspective can be a powerful decision making tool.
     
  9. If you can’t take the plunge off the high dive, run an experiment. Try out your decision on a smaller scale. See what happens. Take the results and boldly make the real decision.
     
  10. Change your point of view. Look for a distraction. Take a walk in a Japanese garden. See a movie. Read a good book. Take your wife on a date. Go to church. Do something to get away from it all, even if just for a few hours. Then come back with a few oxygenated brain cells and make a decision. Ready, aim, fire!

What strategies have you found useful when stuck, unable to make a critical choice on a project? I’d love to hear from you.

Update: I know these are generalized platitudes, but sometimes a good platitude can spark the inspiration one needs to find a specific solution to a real problem.

posted on Wednesday, May 12, 2010 4:39:46 PM (Mountain Daylight Time, UTC-06:00)  #    Comments [0]
# Tuesday, April 20, 2010

Over the weekend, I began to think about how to better protect proprietary algorithms and other sensitive code in a Silverlight application, keeping the assembly away from prying, snooping eyes. I decided the best way would be to keep the code in memory and never have it committed to the hard drive. A little research and a little coding and badda bing (er, badda google?).

The solution turns out to be rather simple. You need four projects: the Silverlight app, the web app, the contract (interface) and the implementation Silverlight class libraries. The Silverlight app references the contract library which pulls it into the XAP. The implementation library references the contract library to implement the interface, of course. And the web app does its thing, supplying the XAP file to the browser and most importantly supplying the protected bits via a stream that presumably is protected by SSL, authentication and authorization mechanisms, items I've conveniently left out of this post and the sample code for brevity.

Start with the AppManifest.xaml (in Dinorythm.xap)
Note that the manifest contains only the Silverlight app and the contract class library along with the other assemblies required for the Silverlight Navigation Application (find what you need at Scott Guthrie's informative Silverlight 4 Released blog post).

<Deployment 
    xmlns="http://schemas.microsoft.com/client/2007/deployment" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    EntryPointAssembly="Dinorythm" 
    EntryPointType="Dinorythm.App" 
    RuntimeVersion="4.0.50401.0">
  <Deployment.Parts>
    <AssemblyPart x:Name="Dinorythm" Source="Dinorythm.dll" />
    <AssemblyPart x:Name="DinoContracts" Source="DinoContracts.dll" />
    <AssemblyPart x:Name="System.ComponentModel.DataAnnotations" Source="System.ComponentModel.DataAnnotations.dll" />
    <AssemblyPart x:Name="System.ServiceModel.DomainServices.Client" Source="System.ServiceModel.DomainServices.Client.dll" />
    <AssemblyPart x:Name="System.ServiceModel.DomainServices.Client.Web" Source="System.ServiceModel.DomainServices.Client.Web.dll" />
    <AssemblyPart x:Name="System.ServiceModel.Web.Extensions" Source="System.ServiceModel.Web.Extensions.dll" />
    <AssemblyPart x:Name="System.Windows.Controls" Source="System.Windows.Controls.dll" />
    <AssemblyPart x:Name="System.Windows.Controls.Navigation" Source="System.Windows.Controls.Navigation.dll" />
  </Deployment.Parts>
</Deployment>

 

DinoContracts a Silverlight 4 Class Library (in Dinorythm.xap).
To any nosy disassembler looking for the secret sauce code, all they will get is the interface and perhaps a few domain classes if you need them.

namespace DinoContracts
{
  public interface IMySecretCode
  {
    string DoSecretWork(string input);
  }
}

 

SecretAlgorithms a Silverlight 4 Class Library (NOT in Dinorythm.xap)
This library has a project reference to DinoContracts and copies it's output to the Dynorythm.Web/App_Data folder.

namespace SecretAlgorithms
{
  public class MySecretCode : IMySecretCode
  {
    public string DoSecretWork(string input)
    {
      return "results of my secret code";
    }
  }
}

 

Dinorythm.Web an ASP.NET MVC 2 project
Obviously this code is not production ready. You need some security here, but what you see here will get you the result you seek. Securing this action method might be a good topic for another blog post.

namespace Dinorythm.Web.Controllers
{
  [HandleError]
  public class HomeController : Controller
  {
    //...other code removed for brevity

    public FileContentResult Secret()
    {
      string ctype = "application/octet-stream";
      string fileName = "SecretAlgorithms.dll";
      byte[] dll = GetFile(fileName);
      return File(dll, ctype, fileName);
    }

    byte[] GetFile(string fileName)
    {
      string path = HostingEnvironment.MapPath(@"~/App_Data/" + fileName);
      byte[] bytes = System.IO.File.ReadAllBytes(path);
      return bytes;
    }
  }
}

 

Dinorythm a Silverlight 4 Navigation Application
This app has a project reference to DinoContracts but knows nothing about the SecretAlgorithms project. The secret code in this demo won't win any awards but it might help you conceive (and me to remember) of how to get the job done with your real intellectual property.

namespace Dinorythm
{
  public partial class About : Page
  {
    public About()
    {
      InitializeComponent();
    }

    // Executes when the user navigates to this page.
    protected override void OnNavigatedTo(NavigationEventArgs e)
    {
      WebClient down = new WebClient();
      down.OpenReadCompleted += new OpenReadCompletedEventHandler(down_OpenReadCompleted);
      Uri location = new Uri(System.Windows.Application.Current.Host.Source, @"../Home/Secret");
      down.OpenReadAsync(location);
    }

    void down_OpenReadCompleted(object sender, OpenReadCompletedEventArgs e)
    {
      AssemblyPart part = new AssemblyPart();
      Assembly asm = part.Load(e.Result);
      IMySecretCode secret = (IMySecretCode)asm.CreateInstance("SecretAlgorithms.MySecretCode");

      if (secret != null)
        this.ContentText.Text = secret.DoSecretWork("help me");
      else
        this.ContentText.Text = "was null";
    }
  }
}

Help credits go to Tim Heuer for some comparison with cached assemblies and to the practical help from a Silverlight Tip of the Day.

A Note About Security: I am not a self-proclaimed security expert. I'm sure there are ways to defeat this approach, but I suspect that doing so would be more trouble than it would be worth. But certainly this would be more efficient than simple or even complex obfuscation. Then again one could obfuscate and then dynamically download and instantiate in memory. That ought to really throw a would be intellectual property thief for a real loop. (Also note, I've never tried obfuscation in a Silverlight class library, so perhaps it's not even possible. Hmm... Another research and blog topic.)

If you find this code useful, I'd love to hear from you. Download Dinorythm.zip (313.34 KB) here.

posted on Tuesday, April 20, 2010 9:17:49 PM (Mountain Daylight Time, UTC-06:00)  #    Comments [0]
# Friday, April 16, 2010

In his annual letter to shareholders, Warren Buffett wrote (emphasis added):

“We tend to let our many subsidiaries operate on their own, without our supervising and monitoring them to any degree. That means we are sometimes late in spotting management problems and that both operating and capital decisions are occasionally made with which Charlie and I would have disagreed had we been consulted. Most of our managers, however, use the independence we grant them magnificently, rewarding our confidence by maintaining an owneroriented attitude that is invaluable and too seldom found in huge organizations. We would rather suffer the visible costs of a few bad decisions than incur the many invisible costs that come from decisions made too slowly – or not at all – because of a stifling bureaucracy.

There are times when working in an enterprise can be frustrating because there are individuals who deliberately and regularly hinder your work while hiding behind the plausible deniability and comfortable safety of that stifling bureaucracy of which Warren Buffett so sagely speaks.

The question is what to do when you find yourself in that situation. There can be only three answers, I believe. Either you succeed in spite of the efforts of well seasoned bureaucrats and hope that attrition wins the day or you fail while trying or even give up somewhere along the line, resigning yourself to failure. The third alternative is that you find another ball field and another team on which to play and never look back.

Which one would you choose?

posted on Friday, April 16, 2010 8:58:25 AM (Mountain Daylight Time, UTC-06:00)  #    Comments [0]
# Tuesday, April 06, 2010

I rarely just parrot-link another blogger’s post, but I’m going to make an exception here to give props to Chris Sells and his excellent “The Performance Implications of IEnumerable vs. IQueryable.”

Chris, the venerated Microsoft Legend, walks us through a great example of where the use of IEnumerable vs IQueryable can get you into trouble. With a simple swap, Chris goes from returning every row in a table to a simple count(*).

The critical thing to learn is that IQueryable is “composable” meaning that you can make one from another before executing the final “outer” query and having the composed expression parsed and executed.

One additional note, however, is the gotcha that can bite you on the keester if you’re not careful. With an IQueryable dependent upon a data context, don’t lose the context or you’ll end up with:

ObjectDisposedException: Cannot access a disposed object. Object name: 'DataContext accessed after Dispose.'.

So watch out for the dangling context. :)

posted on Tuesday, April 06, 2010 8:58:12 PM (Mountain Daylight Time, UTC-06:00)  #    Comments [0]
# Thursday, April 01, 2010

The question of the value of third party UI libraries has often come up in my career. At one time I was an eager advocate of using a comprehensive UI library. Now my attitude is a bit more pragmatic.

Third party UI libraries are sometimes a boon and sometimes a bane. Even for well seasoned UI frameworks. UI libraries for web applications tend to be particularly troublesome because they so often have a clumsy, heavyweight configuration and API that end up requiring more time to use than they save while the vendors race to win the feature count contest.

For some years, the trend seemed to lean toward the use of UI libraries because building a UI by hand was hard regardless of whether you were working with spaghetti script or with Win32 and MFC. Now Microsoft's toolset supports a much richer set of UI paradigms making the delivery of a great UI much easier right out of the box. The trend seems to be gravitating away from reliance on third party controls toward a more simplified user interface style with a more elegant framework relying more on convention than a feature bloated configuration and black box API.

One area where UI libraries seem to continue to do well, in my view of course, is with Silverlight and WPF (XAML) applications. These UI frameworks and their supporting third party UI control sets seem to have been made for each other. Both rely heavily on the powerful UI declarative language XAML. The rich user interfaces that can be spun up using Silverlight or WPF can be intoxicating.

Ultimately, we need to use UI libraries judiciously, being careful not to overuse them where requirements and the effort needed to learn and configure them are not warranted. One could argue that the limited way in which many third party controls are used in a variety of applications provide us with a bountiful set of examples of the gratuitous overuse of these libraries. Sometimes all you need is a good closet and the kitchen sink that comes with that room builder toolkit is just plain old overkill.

posted on Thursday, April 01, 2010 10:27:31 PM (Mountain Daylight Time, UTC-06:00)  #    Comments [0]
# Tuesday, March 30, 2010

I love Orson Scott Card’s books. My first and still all time favorite is Ender’s Game.

If you’re not a fan, go read the book anyway. If you are, you already know what I’m talking about. The iPad is Ender’s desk, or perhaps its precursor.

Here’s a composite I just made thinking of this concept. One image from Apple and the other from a very innovative early childhood education software company called Imagine Learning.

endersdesk

I’ve never wanted to own an Apple produce product (slip of the finger, but an apple is a fruit after all) or develop software for it until now.

When I think of the amazing ways that educational content and interactivity could be delivered to students using this device, I get very excited. And I imagine a very smart kid hacking the device and sending rude messages to another student. That makes me more excited for the future of technology than anything I’ve seen lately.

posted on Tuesday, March 30, 2010 9:15:56 PM (Mountain Daylight Time, UTC-06:00)  #    Comments [4]

The .NET technology map keeps expanding, but I have my eye on one particular continent, a little piece of the .NET 4 world I’m calling the Silverlight 4 Enterprise Stack. There seems to be focus coalescing on this important piece of technology real estate.

The Patterns & Practices team blog has a great post looking into the enterprise crystal ball. Be sure to check out their Prism (Composite Application Guidance) on CodePlex.

The primary pieces of the Silverlight 4 Enterprise Stack are:

Other supporting players in the stack are:

With the eminent release of these technologies on April 12, we the Enterprise Software rank and file have much to look forward to in terms of new toys to play with while delivering some amazing new user experiences in the enterprise world.

If you want to keep tabs on the Silverlight 4 Enterprise Stack, be sure to set your RSS reader to tap into these key bloggers:

For us enterprise software geeks, the year 2010 is shaping up to be a very good year!

posted on Tuesday, March 30, 2010 8:45:04 PM (Mountain Daylight Time, UTC-06:00)  #    Comments [0]
# Sunday, March 28, 2010

I've been wanting a simplified WCF plugin architecture for .NET Windows service with easy debug console mode to make my life easier. Building services with Windows Communication Foundation (WCF) is simple and hard. The service and data contract code is simple, like this:

namespace Test2Common	
{
  [ServiceContract]
  public interface IMyOtherService
  {
    [OperationContract, FaultContract(typeof(WcfServiceFault))]
    string GetName(string seed);

    [OperationContract, FaultContract(typeof(WcfServiceFault))]
    Person GetPerson(int id);
  }

  [DataContract]
  public class Person
  {
    [DataMember]
    public string Name { get; set; }

    [DataMember]
    public string Title { get; set; }
  }
}

But that is where simple ends. The hosting and client proxy code and the configuration XML (or code) is not simple. Even when I use tools to generate these artifacts, I find myself having to tweak and fix and delve deeper than time permits. And since I prefer simple, I decided to create a reusable framework for hosting my limited scope services. Here's what I wanted (download PluggableWcfServiceHost.zip (38.05 KB)):

  • Fast net.tcp binding
  • Windows credentials and authentication
  • Encrypted and signed transport (no packet sniffing allowed)
  • Simplified configuration (hide everything I don't want to see)
  • Windows Service host that behaves like a Console app when I'm debugging
  • Dynamic loading of the service (no changes to the host code to add a new service)
  • Generic client so I don't have to write or generate proxy code
  • Client that is truly IDisposable (hide Abort vs Close for me)
  • Long timeout in DEBUG mode so I can really take my time while debugging
  • Inclusion of exception details in DEBUG mode only
  • Base service class with a simple Authorize method to support multiple Windows groups
  • Support for multiple Windows group authorization
  • Identical configuration for server and client
  • Cached resolution of service plugin service and contract types
  • Minimal number of assemblies (projects) in the solution
  • Keep the implementation of the service hidden from the client
  • (Probably some I've forgotten to mention)

Here's the simplified config with two services configured:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="wcfServices" 
          type="WcfServiceCommon.WcfServiceConfigurationSection, WcfServiceCommon" />
  </configSections>
  <appSettings/>
  <connectionStrings/>
  <wcfServices consoleMode="On">
    <services>
      <add key="test1"
          serviceAddressPort="localhost:2981"
          endpointName="Test1EndPoint"
          authorizedGroups="WcfServiceClients,someOtherGoup"
          hostType="Test1Service.ThatOneService, Test1Service"
          contractType="Test1Common.IThatOneService, Test1Common" />
      <add key="test2"
          serviceAddressPort="localhost:2981"
          endpointName="Test2EndPoint"
          authorizedGroups="WcfServiceClients,someOtherGoup"
          hostType="Test2Service.MyOtherService, Test2Service"
          contractType="Test2Common.IMyOtherService, Test2Common" />
    </services>
  </wcfServices>
</configuration>

And here's the implementation of the service (It really is simple):

namespace Test2Service
{
  public class MyOtherService : WcfServiceBase, IMyOtherService
  {
    public string GetName(string seed)
    {
      base.Authorize();
      return "This is my name: " + seed.ToUpper();
    }

    public Person GetPerson(int id)
    {
      base.Authorize();
      return new Person { Name = "Donald Trumpet", Title = "King of the Hill" };
    }
  }
}

Now for the really fun part. The client. Hey, where's the proxy? Hidden away just like it ought to be.

namespace WcfSvcTest
{
  class Program
  {
    static void Main(string[] args)
    {
      using (var client1 = WcfServiceClient<IThatOneService>.Create("test1"))
      {
        Console.WriteLine(client1.Instance.GetName("seed"));
        var add = client1.Instance.GetAddress(8);
        Console.WriteLine("{0}", add.City);
      }

      using (var client2 = WcfServiceClient<IMyOtherService>.Create("test2"))
      {
        try
        {
          Console.WriteLine(client2.Instance.GetName("newseed"));
          var per = client2.Instance.GetPerson(7);
          Console.WriteLine("{0}, {1}", per.Name, per.Title);
        }
        catch (FaultException<WcfServiceFault> fault)
        {
          Console.WriteLine(fault.ToString());
        }
        catch (Exception e) //handles exceptions not in wcf communication
        {
          Console.WriteLine(e.ToString());
        }
      }

      Console.ReadLine();
    }
  }
}

To save space, I only wrapped the use of the client in try catch on the second test service.

Note: You have to remember that the WcfServiceHost requires the "common" and the "service" assemblies of your dynamically loaded services in it's bin folder. The client (see WcfSvcTest project in the solution) will also need a copy of the "common" assemblies in it's bin folder. You'll find I'm doing that for the test using post-build commands (copy $(TargetPath) $(SolutionDir)WcfServiceHost\bin\debug\). And of course, both need to have identical config sections as shown in the code.

I hope you find this WCF plugin architecture and the accompanying code useful. I will certainly be using it. If you do use it, please let me know how it goes.

Download PluggableWcfServiceHost.zip (38.05 KB)

posted on Sunday, March 28, 2010 8:58:40 PM (Mountain Daylight Time, UTC-06:00)  #    Comments [0]
# Thursday, March 25, 2010

Let’s face it. Most of us code slingers have no innate understanding of what makes a great user experience (UX) design. We spend so many hours in front of multiple user interfaces that navigating and using software becomes virtually intuitive, instinctual. But we are not “normal” users.

I’ve just finished reading and mean to re-read Whitney Hess’s “25 Guiding Principles for UX Designers” on Inside Tech. It’s a great piece with some very good references. I recommend you read the entire article multiple times. Here are some of my favorites (my number is not the same as Whitney’s):

1. Understand the underlying problem before attempting to solve it.
How often do we just begin coding and throwing a user interface together without having spent much, if any, time with the target audience to understand their needs, challenges, skill level and approach to solving the problem currently?

2. Make things simple.
How often do we try to put every feature we can pack into a single view thinking to make the software powerful and reduce round trips to the server or some other resource?

3. Provide context.
How often do we place controls or information in a user interface that we consider convenient but in reality is out of context and will confuse a user who does not understand what is going on “under the covers” so to speak?

4. Be consistent.
How often do we design one page in a certain way only to bounce the user to another page in a web application that uses a different design paradigm, making the user spend some time just to figure out where the OK or Cancel button or link is now?

You can read about these and the 21 principles at Whitney’s article (see link above). I also recommend the following resources, a selection from those Whitney recommends:

UX Principles and Design Guides

If you have some favorite principles of your own, please share them here.

posted on Thursday, March 25, 2010 10:25:55 AM (Mountain Daylight Time, UTC-06:00)  #    Comments [0]
# Wednesday, March 24, 2010

I’ve been giving the question of why software teams fail some considerable thought in the past few days. Reading Brad Abrams’ post Don’t Waste Keystrokes and his statement that “By far the biggest problem I see on teams of > 1 is communication” led me to compile the following list. Here are some of the reasons, in addition to the most important one that Brad pointed out already, that a software team, or any team really, fails:

  1. The team does not practice regularly, no coordinated learning.
  2. The coach does not know the strengths and weaknesses of the players.
  3. The players do not know their role, their zone or the plays.
  4. The players do not get along, they are not one in purpose.
  5. The players do not trust or respect the coaching staff.
  6. The coaching staff puts players with no skill on the starting lineup for unknown reasons causing resentment amongst the other players and guaranteeing a loss at game time.
  7. The players do not believe the coaching staff understand the game.
  8. The players are more focused on individual agendas, they do not work together to win.
  9. The rules of the game are not well understood and change during the game.
  10. The coaching staff and team captains disagree on how the game should be played.
  11. The coaching staff recruits new players looking for players who will agree with their ideas rather than seeking out players who can actually play.
  12. The players fail to improve their skills on their own time.
  13. The players lack motivation and fail to come to practice and give only a half-hearted effort in the game.
  14. The team captain spends more time arguing with the coaching staff than he does leading and motivating the players.
  15. Winning becomes secondary to just finishing the season.

If you can think of any others, please let me know. And if you have ideas for how to fix these situations, I would love to hear from you as well.

posted on Wednesday, March 24, 2010 10:06:34 AM (Mountain Daylight Time, UTC-06:00)  #    Comments [1]