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]  | 

My colleagues and I from IDesign are currently hitting 6 cities across the US over this week and next (Ft Lauderdale, Atlanta, and Dallas this week, Denver, Minneapolis, and Boston next week) showcasing .NET 3.5 technologies. I'm giving the sessions on WPF and WF.

For those who attended: thanks for being a great audience!

You can grab the demos here.

Thursday, September 13, 2007 12:50:40 PM (GMT Standard Time, UTC+00:00)
Comments [0]  | 

Beta 2 is finally here. Got it installed last night and of course one of the first things I wanted to play with is the WPF designer to see how far it had come along since Beta 1 and the Nov CTP tools for VS 2005.

Positives:

• The designer surface itself has come a long way and the snap lines, margin guides, and other adornments to help get elements positioned within the UI and visualize what underlying layout properties have been set looks really nice.
• There is a zoom control that makes it really easy to zoom in and out with smooth scaling to focus on the parts of the UI you are working on as a nice alternative to scrolling.
• They have a great little breadcrumb control at the bottom that lets you see where you are in the element hierarchy and even gives you a pop-up rendering of the other items in the hierarchy as you hover the mouse over them (see below).
• Picks up container locations such as grid cell when you drag and drop a control.
• The properties grid is fixed as far as being able to edit collection properties such as the RowDefinitions and ColumnDefinitions properties of a Grid.
• The XAML editor has improved IntelliSense with icons that help identify different constructs (namespaces, classes, etc when the IntelliSense list is up. The IntelliSense includes listing available namespaces with a clr-namespace construct for types in the project. Once the clr-namespace has been added, custom types show up in the IntelliSense tag list. Nice.
• Common WPF constructs (Window, Page, UserControl) are in the Add > menu from the project.
• Double click to hook up default event! Finally!

There are still a number of annoying aspects that I sure hope will be worked out by release.

Negatives:

• Designer load time: Still takes a really long time to load an empty form in the designer.
• Properties grid: No option to sort the properties alphabetical, so you still need to scroll around looking for what category the property you care about might be lurking in. Unfortunately no property search like Blend has.
• XAML Editor: Still does not add closing element tags when you create an open element tag. Very annoying productivity hit wen forced to bang out XAML by hand. Fills everything that is not inside an element tag with a cyan background. There does not appear to be any way to customize this.

Overall, I'm quite pleased with what I see. I think I can finally ditch using the Nov CTP in VS2005 for WPF development! I'll still be using a mix of this and Blend though.

Saturday, July 28, 2007 2:33:11 PM (GMT Standard Time, UTC+00:00)
Comments [1]  | 

I gave a talk on Connecting Applications with WCF to the Space Coast .NET and Orlando .NET User Groups over the last two nights. Had great attendance and questions, thanks to all who attended.

If you want the key takeaway from the talk (other than the demos and mechanics of how to connect two applications with WCF and use different bindings and capabilities of WCF), here is the elevator pitch.

WCF is a remote communications technology based on SOAP messaging. It is interoperable, powerful, flexible, easy to maintain, and supercedes all the previous remoting technologies in the .NET space:

• .NET Remoting
• ASP.NET Web Services
• Enterprise Services (COM+ for .NET)
• MSMQ

Basically, if you are writing a new application or new portion of an application that needs to make remote calls, use WCF and forget all the above exist. WCF gives you a single API for doing remote communications that rolls up all the capabilities of the technologies listed above, allowing you to write your code with most of the details of the remote communications abstracted away. This allows you to change major aspects of your remote communications approach, such as wire level protocol, encoding, security mechanisms, reliability, etc. without touching your programmatic code - you just modify config file settings. If you need to switch from TCP sockets with binary encoding to HTTP SOAP XML messaging, it literally takes about 30 seconds of editing your config files to do so.

There are a few fringe cases such as interoperating with a legacy .NET Remoting app, or certain advanced features of MSMQ that you will not be able to do with WCF, but for 98% of the remote communications needs out there, WCF is the choice you should make.

If you want the slides and demos I presented, you can grab them here:

Slides     Demos

Friday, July 20, 2007 1:54:28 PM (GMT Standard Time, UTC+00:00)
Comments [0]  | 

In my ClickOnce book, I talk about David Guyer's excellent tool for creating Bootstrapper manifests for a custom bootstrapper item for your ClickOnce deployed applications. The URL I gave in the book is no longer valid, the BMG has been moved to codeplex at the following address:

http://www.codeplex.com/bmg

Basically, this tool gives you a nice dialog driven interface on the XML manifest files that make it so you can just check a box in Visual Studio (the Publish tab of project properties, Prerequisites button) to select your custom installers to be included in the bootstrapper setup.exe that is generated by ClickOnce. 

Tuesday, July 17, 2007 11:34:41 AM (GMT Standard Time, UTC+00:00)
Comments [1]  | 

I've had a number of requests to get an errata out for my Data Binding book. Luckily, the editors at AW did a wonderful job so the number of errors is really low for a first edition book. But there were a few little things here and there that should be noted.

You can download the errata for the book here:

http://www.softinsight.com/databindingbook/Errata%20for%20Data%20Binding%20with%20Windows%20Forms%202.0.doc

Tuesday, June 19, 2007 11:26:03 PM (GMT Standard Time, UTC+00:00)
Comments [1]  | 

I get a lot of questions about what kinds of windows can be created from where in WPF when I give WPF talks. In a talk in Cleveland the other night, there was an attendee who was concerned because he didn't see a way to set a parent window for another window, and thought that is why they did not include an MDI windowing style in WPF.

If you want to set up a window ownership model in WPF like you did in Windows Forms, you just need to look at the Owner property, instead of Parent. The behavior is not exactly the same, but a lot of the same concepts apply.

If you create a window instance and set its Owner property to a reference to another Window, then when you show the child window it will always be displayed on top of the Owner window. This is typically used when creating an application modal dialog, but it behaves that way even if you show the window with a call to Show vs ShowDialog. The latter just adds the behavior that you cannot select the owner window and interact with it while the dialog is in place. When you call Show on an owned window, the user can still move the window out of the way, click on the owner window and interact with controls in that window. You could do this to create a floating tool palette window for example.

The fact that there is not a built-in implementation of MDI doesn't mean the framework doesn't support it, the WPF team just decided to leave that out of scope for the initial (v 3.0) release because very few applications are built from scratch with the MDI model these days.

If you really want MDI, you have two choices:

• Write it yourself. This would be a little tricky because you would have to detect Window movement and either prevent them from leaving the horizontal or vertical constraints of their owner window's client area, or you would have to deal with how to do clipping of the contained windows, because WPF does not clip by default.
• Adopt Acropolis. This framework is coming out in the Orcas timeframe and provides a modular WPF architecture based on concepts carried over from the Composite UI Application Block and the Smart Client Software Factory. It adds better support for inexperienced programmers to use the framework, adds pre-built components, a great design time interaction, and certain other application level support - such as an MDI application model.

Another window management question that often comes up is to ask whether you can use Windows Forms windows or Windows Forms message boxes within your WPF application. The short answer is - yes you can. You can simply construct a Windows Forms Form class and call show and it will just be another top level window presented by your application. Since Windows Forms message boxes really just make an interop call into the OS to display an OS message box, that is of course supported too. However, WPF has its own MessageBox class, so using Windows Forms MessageBoxes is really only interesting while migrating an existing Windows Forms application to WPF.

Tuesday, June 19, 2007 11:21:45 PM (GMT Standard Time, UTC+00:00)
Comments [0]  | 

More security is a good thing. At least until it starts to cause you pain and suffering, and then it is easy to either decide that more security is bad or that the software that is providing you better security is bad. But the fact is, more security is a good thing, and you will be better off if you learn how to exist in that more constrained world rather than live free and unprotected. Gosh, that started to sound like a pro-Bush  restriction of freedoms post... lets get back to the tech quick.

The biggest pain points in adopting Windows Vista are usually due to non-existent, incompatible, or poorly written drivers. This is not Microsoft's fault, but the hardware vendor's fault. The next one that hits you in the face after you get past your driver pain is the fact that Microsoft is getting smarter and smarter (and more protective of you and your machine) with each new software product they put out. IE7 and Windows Vista definitely fall into this realm.

If your machine is set up as a standalone machine, or as part of a workgroup network (i.e. most home users), there is a subtle little security setting in IE7 that may cause you pain and suffering as a developer as you migrate to IE7 or Windows Vista.

Specifically, you may get prompted for credentials when accessing a local machine virtual directory when you think you have integrated authentication enabled and you shouldn't be prompted.

To explain why this occurs and how to fix it, lets first quickly recap life as we knew it in Windows XP and Server 2003 prior to IE7.

If you are working with web projects from your local machine, you will likely be creating virtual directories or IIS applications on your local install of IIS.

Turning On Integrated Windows Authentication in IIS

On XP, if you set the security settings for the site with Integrated Windows Security enabled and Anonymous Access disabled (see figure below), then when you browse to that local site from IE on the local machine, Windows automatically negotiates authentication between the browser and IIS and passes your logged in user credentials to the server (which is on the same machine), and you are let into the site or page (assuming your user account has ACL access to the underlying folders/files). In other words - integrated security does its job behind the scenes and you don't get prompted for credentials, but you are accessing the site with your logged in user credentials.

On Windows Vista, the security settings on the site are a little different, but basically mean the same thing. The corresponding authentication settings for Vista/IIS7 are shown in the figure below. Specifically, set Anonymous Authentication to Disabled, and Windows Authentication to Enabled.

IE7 Intranet Security Settings

If you are configured as a workgroup from a network perspective, when you first try to access a localhost web site, you might (or more importantly might not) notice an information bar at the top of IE telling you that Internet security settings are being applied to the Intranet zone by default. It gives you an opportunity to click on the info bar and revert to Intranet settings if you like. If you don't, after a certain number of prompts (which I don't know how many there are, it may just be once), it will stop telling you that.

The issue is that IE will set the Intranet zone security to automatically detect the network. However, depending on your connectivity, network setup, and possibly the celestial alignment of Jupiter and Venus, it will not detect that localhost is in fact in the Intranet zone. In a Windows domain this should not be a problem, but standalone it definitely is.

Because it can't tell that localhost is in fact local intranet, it plays it safe and applies internet zone security to the site. And with the default security settings, automatic authentication through Windows is disabled in the internet zone. Thus the prompt for credentials when you hit your localhost site through the browser.

The Fix

The fix is quite simple... just hard to find unless you are a psychic or know super brilliant people like Chris Kinsman or Kate Gregory.

To get back to behavior like you are used to on your retro XP box, go into IE Internet Options, Security tab. Select the Local Intranet zone, and press the Sites button (see below).

In the popup (see below), uncheck the "Automatically detect intranet network" box and make sure the three child check boxes are checked. Click OK and you should be back to integrated security as you know and love it.

Friday, June 15, 2007 10:07:04 PM (GMT Standard Time, UTC+00:00)
Comments [1]  |