A new buzzword that I hear more and more these days, particularly from Microsoft evangelists, is "differentiated user experience" or "differentiated UI". I'm even guilty of using this occasionally myself. And yet, it is one of those terms that often makes people cock their head like a dog that heard a human-inaudible screech.

We have been using it a lot this week, because I have been working with the patterns and practices team at Microsoft on the Composite WPF project, and we want to make sure that what gets built there accommodates a differentiated user experience.

So what does Differentiated UX mean? Given the context of most recent discussions on the subject, one would have to think that a non-differentiated UX would have to mean any kind of UI that came before WPF or Silverlight. But that is not really the case. In fact, it may not even exist now given that a quick search in Live or Google yields almost nothing for the search term “differentiated UX” or "differentiated UI".

I think the term Differentiated UX fits cleanly into a similar space as the term SOA – especially when the SOA term was first being thrown about as the future of software development without any clear definitions anyone could agree on (then or now) about what qualifies an architecture as service oriented. Those talking about the new buzzword seem to have a clear understanding of what they mean, but most are left wondering what they have in mind when they say that term.

Imparting what a differentiated UX is difficult because a lot of it amounts to dynamic graphical behaviors that cannot be statically captured with any fidelity in a written document like this. When I think of a differentiated UX application, I can’t help thinking of a quote I have heard a couple of times when visiting my father-in-law in Kentucky – “Y’all ain’t from around here, is ya?” (delivered with a wide variety of grammatical crimes against humanity). This quote captures that visceral sense that something is different about your experience than what you were expecting or what you are used to. I think that captures the essence of differentiated UX. It should not be a completely alien user experience. The user still needs to know or easily figure out how to get done what they need to get done. But the look, feel, and interaction may be considerably different than the way the same task would have been presented with preceding UI technologies. Usually that difference is that it is more dynamic in some way, including visual effects such as fading, highlighting, scaling, moving, etc.

I think one attribute that would make an application a differentiated UX application is when the application gives the user a unique experience in performing a task that is familiar to them. Another way of spinning the same functionality is to say that a differentiated UX exploits new UI technology to allow experienced or novice users to discover how to complete a particular task with greater ease. Another aspect that puts things into the differentiated UX space in my mind is when an application has a unique visual theme or branding that makes it really stand out, but in a non-obtrusive way, from other applications designed to perform the same tasks, and that makes it somehow more pleasant to look at or use.

A great example of differentiated UX available in the public domain is in the Family.Show reference application by Vertigo software (http://www.codeplex.com/familyshow). The assumed audience for the application is non-technical users who want to enter and track information about their family tree (a genealogy application). There have been dozens of small applications written for this purpose in the past, and most employed traditional UI controls including grids, list boxes, combo boxes, and text boxes to try to convey the potentially dense and hierarchical information contained in a family tree. Family.Show harnesses the ability of WPF to easily display rich 2D graphics (with additional features such as zoom and pan that are extremely easy to implement in WPF due to its vector graphics rendering engine) to show a family tree as just that – a 2D graphical interactive rendering of a family tree with vector representations of individuals in the tree, relationships, other adornments for peripheral information about the individual. The incremental cost of displaying information in this way in WPF if a fraction of the cost it would have taken to do this with Windows Forms, MFC, VB6, or even current web technologies (excluding Silverlight).

Additional information is presented not with traditional drill down dialogs or other UI that requires a distinct context switch for the user, but through rich content pop-ups and detail panels that slide out from a selected location, giving the user graceful transitions that are easier to follow and not get disoriented by the context switches in the application.

The Woodgrove Financial Application is another sample WPF application that demonstrates features I would say puts it into the realm of differentiated UI. Similar to Family.Show, it uses rich graphics (2D and 3D charts in this case) to depict data that would have often been presented with grids, list boxes, and text boxes in a typical line-of-business (LOB) application. It too features rich content pop ups (bar charts inside the tooltip shown, a zoomed view of the chart in the upper right when you hover over it, additional axis labeling in the 3D bar chart when you hover over data that represents a particular vertical market, etc.). All of those are also delivered leveraging WPF’s animation and transparency features to provide gradual, more intuitive transitions for the user so that even though there is a lot more information flying out of the screen at them in response to subtle user interactions, it does not become overwhelming or disorienting.

Another example I like to show that speaks of a differentiated UI is the Cine.View application by thirteen23.com, a WPF design company. Cine.View is a WPF smart client front end for the NetFlix web-based movie rental service. Although the choice of color gradient is a bit overwhelming, the application demonstrates a number of great styling capabilities of WPF that add the sense that this ain’t your typical smart client application anymore. They use a navigation-style WPF application with forward and back navigation like a browser, and use quite a bit of animation, transparency, and element styling to give a really distinctive application feel to something that could be quite mundane otherwise. An intelligent use of transparency and animation in simple things like presenting a drop down menu or transitioning between views can add a lot in terms of just making the user “like” the application.

While a lot of this may seem like just eye-candy, one has to be always cognizant of the impact a simple visceral coolness to an application compared to its competitors may have. I frequently work with customers ranging from internal corporate applications; to ISVs for major industry software including financial, insurance, and medical; to government contractors developing specialized applications for defense and management purposes. In all these arenas, there is always an aspect of sales to the success of the project. If the funding source (the VP of X in the corporate environment, the purchasing bank or insurance company in the ISV scenario, or the General with the budget to give the green light in the government arena) can look at an application for which they have no expertise to judge themselves, but immediately feel like it is impressive in some way (which usually manifests itself graphically first), then they are likely to chose that as the way forward.

Other examples I have encountered in industry (for which I do not have screen shots) include the following:

· Medical monitoring: An arena that used to require specialized, embedded applications to display real time graphical information about patient measurements and status can now be implemented using WPF. Not only does WPF enable rendering of the dynamic graphical displays, it allows tighter interactive integration of traditional (lists, fields, and grids) UI with the graphical displays.

· Maritime navigation simulation: Rendering of near-photo-realistic versions of vendor equipment such as dials, gauges, controls (steering, throttles), and other user interaction screens to directly model the experience for a particular vessel.

· Defense intelligence data visualization: Presentation of 2D graphical iconic views overlaid on 3D models for situational awareness, complete with user interaction with those graphical elements. Also in this same application, traditional grid-oriented presentation of data enhanced by WPF features (animation and styling) to provide contextual clues while merging different sets of data.

An interesting aspect of the concept of a differentiated UI that was brought up by an insightful student in a recent WPF class I was teaching. He observed that for years we have had design standards which dictated that menus and toolbars and status bars and grids and such were supposed to look a particular way and be in a particular place in your UI. And it was always a battle to get developers to conform to those, but eventually the tools started to make it easier to do those things out of the box. Now it seems the trend is to go in the other direction and to seek a differentiated UI – one that at least looks and feels different (and presumably better) than another app that does exactly the same thing. I think part of this is due to the realization that previous rigid design standards didn’t really make any applications considerably easier to use. Just because a menu item can be found in the expected location doesn’t mean you have any clue what will happen when you invoke it or what the side effects of that action may be. Somehow you have to put yourself into the eyes of the user, think like they will think, and find ways to present tasks to them in a way that will make sense and be easier to use. Putting overly restrictive stylistic constraints on the application designer in getting that done just goes in the wrong direction, so differentiated UI is definitive a swing of the pendulum in the other direction from rigid application UI design standards. Now many of the things those standards addressed, such as menu and toolbar actions, are presented directly in the context of what the user is doing through pop up tooltips and controls that present themselves so the user doesn't have to go far away in the UI to get done what they are doing.

So “differentiated UX” remains an ambiguous term at best. I think I know what it means when I hear it, because I have seen a number of examples that I think would qualify for that term, and have thought about what makes these applications different from the way they probably would have been written, appeared, and behaved had WPF not been available.

If you had to boil it down to a few key attributes, I would include the following:

• Application styling and UI features create a unique and distinctive look and feel for the application
• 2D and 3D graphics are leveraged to provide better data visualization that traditional forms over data controls
• Integrated data interaction across multiple different data views
• User context hints provide richer context clues for the user about what they are doing or what they should do next (rich content tooltips, animated attention grabbers for focus shifts, etc.)
• Location of user interface elements is less rigidly defined by the application shell, and may be completely in the control of the user. This may range from something as simple but important as dockable/floatable windows to a Microsoft Surface-like desktop metaphor where application ui widgets can be moved freeform around the screen by the user (Minority Report effect).
• The UI framework (WPF/Silverlight) supports defining these features with a minimum of code

So that's what Differentiated UX means to me. What does it mean to you? Is it worth having a buzzword to capture this essence or mojo that makes a WPF app different from what came before it? What are some experiences you would put into the "differentiated" space?

I suppose a Wikipedia entry is inevitable at some point, maybe this post and discussion can lead to that?

Monday, January 07, 2008 1:34:48 PM (GMT Standard Time, UTC+00:00)
Comments [5]  | 

Well, my wish came true, I've been renewed for another 2 year term as the Microsoft Regional Director of the Mid-Atlantic Region, as well as getting Microsoft MVP .NET Developer - Solution Architect for another year. I blogged about the RD program the other day. MVP has many of the same but also different benefits, so it is great to be part of both programs.

Here's looking forward to another year great year using, evangelizing, and providing feedback on Microsoft technologies!

Thursday, January 03, 2008 3:08:16 PM (GMT Standard Time, UTC+00:00)
Comments [1]  | 

As we enter a new year, I look back on the last couple years being an RD an feel really lucky for the experience. I hope I will be lucky enough to be renewed this year for another two-year term. RD stands for Microsoft Regional Director. There are about 140 of us worldwide, and we are all external partners/individuals who have a strong presence in the developer or IT Pro community and strong relationships with our local Microsoft offices and/or product teams in Redmond. We help give focused feedback from the community to the product teams, and help evangelize new products to the community. We don't get paid for our efforts, but there are a lot of implicit and explicit benefits to being an RD.

I always tell people that the biggest advantage of being an RD is the direct association with the other RDs. The RD community contains most of the biggest and well respected names in the industry, and I feel honored to be lumped in with such a prestigious group. The association manifests itself through our internal RD email alias, in which we have awesome discussions about Microsoft and other technologies in a closed forum where we can speak our minds frankly, exchange a lot of ideas but also be heard by the product teams directly when relevant. The discussions range from the latest and upcoming technologies to devices to home electronics, but we try to keep it focused on things relevant to our roles as RDs. However, that braintrust can really come in handy when you are thinking about what new phone/music device/laptop/etc. to buy!

We also have a number of conference and industry events at which we gather each year so we get some direct contact with each other, and RDs welcome other RDs with open arms whenever they visit each others regions, even if they have never met in person. In the US, getting together with RD friends like Tim Huckaby, Richard Campbell, Carl Franklin, Stephen Forte, Andrew Brust, Pat Hynds, Mark Dunn, Kim Tripp, and so many others is always a treat. And of course my colleagues at IDesign Juval Lowy and Michele Leroux Bustamante are both RDs as well, and we actually don't get together that often ourselves except at some of these same events. Another excellent aspect is getting together with RDs in other countries on their home turf.

For example, last July I was in Norway doing some consulting and training, and was able to get together with Morty Abrahamsen for beers and dinner in Oslo. In addition to learning a lot about Norwegian culture, we of course talked a lot of geek talk and it was a great idea exchange as well.

This year I will be hitting Norway, Sweden, UK, and other countries, and hope to get together with my other RDs on those trips as well.

Other great parts of the RD program are the early insider access to new things that are coming from the developer division (my particular focus, but we get access to other arenas as well), direct interaction with product teams through focus groups and design reviews, and most of all, just the fact that they really seem to listen to the recommendations that we make.

So what does it mean for you? Well, you have access to this great pool of minds in several forms as well. If you haven't already checked it out, you should visit The Region. This is our community site and provides an aggregated view of the blogging that is being done by all the RDs. The posts added to that site are first reviewed to ensure they are technical in nature and nor personal posts. There are of course RSS and ATOM feeds to subscribe and know whenever an RD has put some more of their grey matter out for public display. There is also a calendar on the site, where you can learn about upcoming events that the RDs will be participating in. You can also determine there who your RDs are by region.

RDs speak at most major industry conferences, so you can attend their talks, and I guarantee you that you will get some of the best content at the conference. You can also often hook up with your RD through a local user group, and at major events like TechEd we have a community booth where you can come by, ask questions, network, and have fun.

I just thought it would be good to share some of this to increase awareness of the program since I frequently get asked about it.

Happy New Year!

Sunday, December 30, 2007 2:11:44 PM (GMT Standard Time, UTC+00:00)
Comments [1]  | 

I gave 4 talks at DevConnections in Las Vegas this week, and the links below provide the demos that I did during the sessions.

WPF in Windows Forms and Vice Versa

Advanced WF

Selecting an Appropriate Client Technology

Building WCF-based Services with WF-Enabled Business Logic

As usual, the conference was a great show and continues to shine as the best and biggest independent developer conference in the US. The fact that the fall show is in Vegas does not hurt any for making it so there is plenty to do in the evenings after sessions as well.

Saturday, November 10, 2007 12:38:28 AM (GMT Standard Time, UTC+00:00)
Comments [3]  | 

As promised for those who attended, or anyone else looking for some material on Windows Forms Data Binding, Generics, Smart Client Software Factory here are the slides and demos.

Slides

Demos

Saturday, October 27, 2007 12:42:07 PM (GMT Standard Time, UTC+00:00)
Comments [1]  | 

UPDATE: Thanks to a very quick response from the product team on this on connect.microsoft.com... It turns out the workflow is not deadlocking, but is aborting. And it is not completely silent about it, you just have to be listening to the WorkflowAborted event on the runtime.

I've been bit a couple of times by this one, so I thought I would record it here as much for my own records as for others who might get similarly stuck.

Tracking and Persistence are two of the powerful capabilities that Windows Workflow Foundation (WF) offers that work right out of the box. You can easily enable them with code like the following:

Tracking allows you to capture lifecycle events of your workflows and activities to a provider (SQL Server persistent store with the built in provider) for operations management monitoring or diagnostic purposes. You can even use tracking events to drive some of your application logic, such as knowing when particular workflows have completed.

Persistence is even more powerful. With persistence enabled, when workflows go idle (waiting on an external event or timer), the workflow runtime can persist the workflow (serialize the workflow object and all of its contained activities state) and stick it in a persistent store (SQL Server with the built in provider). Then when the event occurs, the runtime can wake the workflow back up and turn it back into objects and get it running again. This keeps you from consuming resources on the server for long-running workflows that are just waiting for something that might take hours, days, weeks, or months. It also allows you to scale out the execution of your workflows to multiple servers in a farm, because another (less busy) server can pick up the workflow when it is ready to run instead of the one that was originally running it. You can also prevent this from happening with a process lock if that makes sense for your scenario. Persistence also allows your running workflows to survive across server restarts. All amazing capabilities that you get for free from the workflow runtime.

Both tracking and persistence can also be enabled through your config file as well.

So where is the gotcha? Tracking and Persistence work perfectly fine with one another, normally. However, you can find yourself with your workflows deadlocking indefinitely if you turn them both on, and the cure may not be very apparent unless you really understand how they are working under the covers. OK, even if you understand that, you really have to think it through to understand the cause.

First, the short answer: If you find that your workflows are hanging or deadlocking when they go idle with both persistence and tracking turned on, check to make sure your Distributed Transaction Coordinator (DTC) service is running.

The explanation: If you enable tracking and persistence with code like shown above, both services write their data to the database as part of a transaction. Depending on whether you put them in the same database and depending on which workflow commit batch service (whole separate topic there) you use, the writes to your tracking and persistence stores may or may not use the same connection to talk to the database (obviously if separate databases, they will not). However, they do get wrapped up into a single transaction when a persistence point is hit at the same time as a tracking point (such as when an workflow goes idle). So if the DTC is not running, the transaction cannot promote to a DTC transaction and the workflow ends up deadlocking. Getting the DTC service running fixes the problem.

Normally DTC should be running on a machine with SQL Server running anyway, but I have had it happen on more than one machine where it was not running and had this problem.

The workflow runtime should really be throwing an exception or timing out after a reasonable time if it can't promote the transaction, but instead it just silently deadlocks.

Hopefully if you have this problem, you will find this post through your search engine of your choice and your problem will be solved.

Saturday, October 13, 2007 9:50:46 AM (GMT Standard Time, UTC+00:00)
Comments [0]  | 

Why would you want to do that, you might ask? The scenarios are not many, but picture a window's whose whole purpose in life is to display data pumped into it by other processes. Maybe you have heard of such a thing.... one of these you might have heard of is called Performance Monitor (although that of course is not written in WCF). Or you could envision a manufacturing line monitoring application where the droid controller applications constantly send status, position, count, etc. information to the monitor app.

There is are some subtle tricks to doing this that you should be aware of if you head down this path.

First issue: Concurrency

By default, WCF answers incoming service calls on threads from the thread pool. There is a hard rule in windows programming that thou shalt not make modifications to the UI from a thread other than the UI thread. Windows Forms did not really enforce this, but stood the chance of crashing at unpredictable times (as with all concurrency problems) if you ignored the rule. VS 2005 and beyond help us out by throwing an InvalidOperationException when in debug mode if it detects that you are violating this rule. WPF makes it more rigorous by baking it into the DispatcherObject from when all UI elements derive so that any attempt to access a member of a DispatcherObject derived class from a non UI thread (if that object has thread affinity) will immediately throw an exception.

The good news here is that WCF also by default detects thread affinity when you open your service host, and if it sees that the calling thread has a SynchronizationContext (as both Windows Forms and WPF do), it holds a ref to that object so it can use it to automatically marshal the incoming calls to the right (UI) thread. This is driven by the UseSynchronizationContext property of the ServiceBehavior, which is true by default.

So basically if you do nothing in a forms app, the right thing happens and all incoming calls to the service will be marshalled to the UI thread, so those calls can be safely dispatched to the window, and you can update the UI from within the service method of the call chain that ensues.

Note that you can still run into concurrency issues if you call out from the window on the UI thread and that call chain comes back into the thread as an incoming service call or callback. Then the incoming call tries to marshal over to the UI thread, but that thread is blocked until the outgoing service call completes, which can't happen because it is waiting for the incoming call to complete as part of its call chain... deadlock. There are a number of ways to break that deadly embrace, but that is a separate post. The  good news again... WCF protects you better than normal .NET multithreading because calls timeout. So you will only be deadlocked until the outgoing call times out (60 seconds by default), then an exception will ensue.

Second Issue: Instancing

Because in many situations you don't have to explicitly worry about the instancing modes of WCF, you might not think about this when setting up your window to expose it as a service. For example, you might write try to write your code like the following:

 

    1 public partial class Window1 : Window, ITalkToPeer

    2 {

    3     ServiceHost m_host = new ServiceHost(typeof(Window1));

    4     public Window1()

    5     {

    6         InitializeComponent();

    7         m_host.Open();

    8     }

    9 

   10     // Service method

   11     public void SendMessage(string msg)

   12     {

   13         m_PeerMessageListBox.Items.Add(msg);

   14     }

   15 

   16     private void OnWindowClosed(object sender, EventArgs e)

   17     {

   18         m_host.Close();

   19     }

   20 }

 

In the code above, ITalkToPeer is the service contract and defines a single member SendMessage, which is implemented by the window as the service.

So what is wrong with this code? Well, if you put it together and try to run it, you will not see any messages flowing into the ListBox when clients make the calls.

If you understand the instancing modes of WCF, you can fairly quickly piece together why. Where is the data going? it won't even matter if you make all the calls from a single client through the same proxy or if multiple clients are calling. What's the deal?

By default, the instancing mode (ServiceBehavior.InstanceContextMode to be specific) of a WCF service is Session. That means if the same client calls through the same proxy instance, the calls will all get dispatched to the same instance of the service implementation class (which is Window1 in our example). The problem is that WCF is in charge of creating the instances, and it does so when the calls come into the service. So even though our service hosting environment is set up from within our single window instance, we just told it what type to create through the ServiceHost constructor, we didn't give it a reference to the instance.

The fix is quite simple once this realization is made. We just have to change our instancing mode to Single (meaning singleton), and use the overloaded constructor of ServiceHost which allows us to pass in a reference to a pre-constructed singleton instance. The fixed code is shown below. The problem was that a separate window instance was being created (but not shown) for the incoming calls, so the data was just going into the object model of that non-visible window instance instead of being shown in the main window you were expecting it to.

 

    1 [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]

    2 public partial class Window1 : Window, ITalkToPeer

    3 {

    4     ServiceHost m_host;

    5     public Window1()

    6     {

    7         InitializeComponent();

    8         m_host = new ServiceHost(this);

    9         m_host.Open();

   10     }

   11 

   12     public void SendMessage(string msg)

   13     {

   14         m_PeerMessageListBox.Items.Add(msg);

   15     }

   16 

   17     private void OnWindowClosed(object sender, EventArgs e)

   18     {

   19         m_host.Close();

   20     }

   21 }

Sunday, October 07, 2007 11:03:31 PM (GMT Standard Time, UTC+00:00)
Comments [3]  | 

Those of you who have worked with me or have seen me present know I am a big fan of CodeRush and Refactor Pro, from DevExpress. In fact, if you get me talking about it, you can't shut me up. To sum all my fan boy slobbering praise down to what you really need to know if you have never heard of it or checked it out, CodeRush is a tool that:

• Is like a combination of Visual Studio Code Snippets and Intellisense, both on super-crazed, interplanetary steroids
• Adds code visualization, navigation, and clipboard tools that will also make you way more productive while pounding out code
• Bottom line: it is a tool that even if used to only 10% of its capabilities, will pay for itself within a week or two in making you more productive
• Comes with Refactor Pro, another essential tool to make it much faster and safer to refactor your code to make it clean

Anyway, last week they released a small update (2.5.4) which includes some awesome new templates for WCF coding.

If you have done much WCF coding, you'll know that WCF coding is more about adding attributes and config file entries than it is about writing imperative code, at least for the WCF specific stuff. For examples, defining a service contract, operation contracts, service behaviors, transaction flow, etc. is all done with attributes in code. But there are also a few common constructs you'll write in code, such as creating an instance of ServiceHost or creating a client-side proxy class by hand because the code that VS and svcutil generates is way more verbose than it needs to be.

Then there is the config file... this is where you will spend a lot of your time, and there is nothing worse than writing a lot of angle brackets by hand (even with intellisense helping) just to get some structure in place for the values you really need to provide. The SvcConfigEditor helps some here, but it sometimes does a little too much magic behind the scenes for you, so knowing exactly what is being set means digging into the config file yourself.

This is where the CodeRush templates come in. With a little collaboration with an unnamed individual at IDesign, they have come up with a great set of templates for all the most common code chunks you will add to your WCF services and clients.

For example, instead of having to type 17 characters to decorate an interface with a ServiceContract attribute (see... it physically hurt me to have to actually type all those characters just now, knowing CodeRush could do most of that for me if I were just in VS), I can type 3 plus the space bar - [sc and I have [ServiceContract()] in my code, with the focus inside the parens in case I want to set some properties, and enter jumps me to the end of line in case I don't. Maybe those extra 14 characters don't sound like a lot to you, but add them up over and over and you will get the idea. Here is a tool that can make you 82% faster immediately. OK, well, intellisense saves you some of that, and that assumes you never have to think when coding. I think only Mark Miller, the architect of CodeRush, is that good. But still, trust me, you will feel the time savings in the form of keystroke savings very quickly as you adopt CodeRush.

Even more important, consider a service host you are adding the first service to. To get that service hosted, you need a chunk of code like the following in your config file:

<system.serviceModel> 
  <services> 
   <service name="MyNamespace.MyService"> 
    <host> 
     <baseAddresses> 
      <add baseAddress="http://localhost:2112/"/> 
     </baseAddresses> 
    </host> 
    <endpoint address="MyService" binding="wsHttpBinding" 
       contract="MyNamespace.IMyService" /> 
   </service> 
  </services>
</system.serviceModel>

There are over 200 characters of pure structure in there. I can write this now with one character - s and a space bar hit. Placeholders are put on the items I do need to customize (service name, addresses, binding, and contract) so it is very quick to move from one to another by overtyping, enter, overtype, enter, etc.

Lots of great templates along these lines. For the XML config file entries, you can see the top level ones in the template browser:

These are all backed by stuff hiding in that System folder that let you hit all the most common combinations such as bt for a TCP binding, bh for an HTTP binding, etc.

Mark even added some new smarts for detecting parent elements so it will check if the binding has an enclosing <bindings> parent, and will only add it if not.

Code wise the two there for now are to add a service host block:

using (ServiceHost host = new ServiceHost(typeof(ApplicationService))) 
{ 
  host.Open(); 
  Console.WriteLine("Press Enter to Exit..."); 
  Console.ReadLine(); 
}

And a "hand coded" proxy class for a client:

public class MyServiceProxy : ClientBase<IMyService>, IMyService 
{ 
  public MyServiceProxy() { } 
  public MyServiceProxy(string endpointName) : base(endpointName) { } 
}

As long as you have the interface type in scope, you can then just implement the interface, add the calls through the base class Channel and you have a lean, clean proxy in about 30-60 seconds, usually faster than you can get a verbose messy one through Add Service Reference or svcutil.

Anyway, if you are a WCF programmer and using CodeRush, check out the new templates under the WCF categories in C#/VB and XML code types. If you are a WCF programmer and have not considered CodeRush, maybe you should now.

Sunday, October 07, 2007 7:39:26 PM (GMT Standard Time, UTC+00:00)
Comments [0]  | 

We are gearing up for another code camp in the DC/Northern Virginia area. It will be held at the Microsoft Reston training facility on Nov 17th.

We have a great set of tracks lined up, and now we just need to fill them with all the brilliant speakers in the area. So if you are willing to come share your expertise with your fellow developers in the area, please lend a hand.

Jeff Schoolcraft has a nice description of each of the tracks and what we are looking for here.

You can find the full details on the code camp here. You'll need to register and login to submit your abstracts.

Thanks and hope to see you there!

Thursday, October 04, 2007 10:27:51 AM (GMT Standard Time, UTC+00:00)
Comments [1]  |