# Thursday, April 15, 2010

While I guess I understand why this would be a problem, I don’t understand why it worked before…

If I want to create a style for a button, let’s say with a red background, I might create a brush resource that defines my special color of red, then reference that brush in a style resource like so

<SolidColorBrush x:Key="TheBrush">
<Style x:Key="RedButton" TargetType="Button">
    <Setter Property="Background" Value="{StaticResource TheBrush}"/>

That works just fine.  I get a red button like this


If the two resources are in the opposite order

<Style x:Key="RedButton" TargetType="Button">
    <Setter Property="Background" Value="{StaticResource TheBrush}"/>
<SolidColorBrush x:Key="TheBrush">

then at runtime I’m going to end up with an exception because the resource “TheBrush” can’t be found.  Hmmm.  I suppose that makes sense if we imagine the XAML processor instancing objects as it comes to them in the XZML file.  It would try to instance “RedButton” and not be able to create the static reference to “TheBrush” because that object hasn’t been instanced yet.

If I happen to apply that style some something in my XAML

    Style="{StaticResource RedButton}" 
    Content="Red Button" Height="23"
    Click="button1_Click" />

I’ll get a compile error.  OK.  If, however, the reference to “RedButton” is in something like a DataTemplate that doesn’t get applied until runtime, then I get a rather jarring runtime exception instead. 

Again, I suppose this behavior makes sense given my theoretical model of the XAML processor (though it smacks of C++-ishness).  What doesn’t make sense is why it worked just fine in the RC, and just recompiling in the release of VS 2010 I now get runtime exceptions.  Something obviously changed in the way resources are loaded and/or referenced at runtime.

Thursday, April 15, 2010 1:02:03 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, February 12, 2010

We just caught this one this morning…  It looks like WF 4 reuses activity instances across workflow instances.  So if I have a WorkflowService that’s hosted in IIS, and I call it from two different client threads at the same time, the two workflow instances now running on the server may be using the same activity instances for child activities.  The documentation is not clear on this point, but that’s the behavior we observed. 

The implication is that you have to treat calls to your Activity’s Execute method as stateless, and not maintain any state in your activity between calls to Execute.  (Our specific problem was around EntityFramework containers.  Apparently they don’t like being called on multiple threads. :) )

Makes sense, but it’s not clear at all from the documentation that it would be the case.  You can rely on the thread safety of your InArguments and OutArguments, since they are accessed through the context, but private fields are right out unless whatever you store in them is also threadsafe.

Friday, February 12, 2010 11:14:40 AM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, February 10, 2010

This is probably one of those things that is obvious to everyone but me, but just in case it’s not…

We’re using Unity as our IoC container, and we are also using .NET 4 Workflow Services hosted in IIS, meaning .xamlx files that are served up by IIS 7.  In order to get full value out of Unity, we need one instance of the Unity container that gets properly configured somewhere that is then available to any WF activity that might need to resolve a reference.  But…since IIS is hosting, there’s no direct access to the WorkflowServiceHost to add the Unity container as an extension (which is how we do it in places where we are hosting using WorkflowApplication in WPF apps, etc.).  I suspected that the solution was a WCF Service Behavior extension, because that’s how you set up a tracking participant if you are hosted in IIS, and luckily that turned out to be the case.  I’d been putting off nailing it down because I suspected it was hard, but as luck would have it (or, rather, the cleverness of the ServiceModel team) it’s not hard at all.

First, we need a behavior extension that creates (and ultimately configures) the Unity container.  It has to implement IServiceBehavior, since we need it to be a service behavior to get access to the host.

public class UnityServiceBehavior : IServiceBehavior

    #region IServiceBehavior Members

    public void AddBindingParameters(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase, System.Collections.ObjectModel.Collection<ServiceEndpoint> endpoints, System.ServiceModel.Channels.BindingParameterCollection bindingParameters)

    public void ApplyDispatchBehavior(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase)
         WorkflowServiceHost host = serviceHostBase as WorkflowServiceHost;
         if (host != null)
             IUnityContainer container = new UnityContainer();
             host.WorkflowExtensions.Add<IUnityContainer>(delegate { return container; });

    public void Validate(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase)

Secondly, we want it to be configurable through web.config, which calls for a BehaviorExtensionElement. 
public class UnityBehaviorElementExtension : BehaviorExtensionElement
    public override Type BehaviorType
        get { return typeof(UnityServiceBehavior); }

    protected override object CreateBehavior()
        return new UnityServiceBehavior();

Then, in our web.config, just register the extension, which in turn will configure and return behavior.

        <!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
        <serviceMetadata httpGetEnabled="true"/>
        <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->
        <serviceDebug includeExceptionDetailInFaults="false"/>
      <add name="unityExtension" type="UnityBehavior.UnityBehaviorElementExtension, UnityBehavior, Version=, Culture=neutral, PublicKeyToken=null"/>
  <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />

In this case, the fact that the behavior element doesn’t include a name means the set of behaviors it contains will be applied to any WCF service that is relying on the default configuration (one of the coolest things in .NET 4!) which is how our .xamlx file works in this example.

Once all that’s done, from any activity in my .xamlx workflow I can access the IUnityContainer interface as an extension.

public sealed class CheckForUnity : CodeActivity
    // Define an activity input argument of type string
    public OutArgument<bool> HasUnity { get; set; }

    // If your activity returns a value, derive from CodeActivity<TResult>
    // and return the value from the Execute method.
    protected override void Execute(CodeActivityContext context)
        IUnityContainer container = context.GetExtension<IUnityContainer>();

        context.SetValue<bool>(HasUnity, (container != null));
.NET 4 | Unity | WF
Wednesday, February 10, 2010 5:03:13 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, December 16, 2009

Feedburner has apparently started decorating the URLs they embed to link back to my full posts, which is causing my decrepit version of dasBlog to yak up 404’s.  I’m working on it now, and apologize for the inconvenience.

Wednesday, December 16, 2009 9:51:04 AM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [1]  | 
# Tuesday, December 15, 2009

Just in case someone is googling (binging?) this later…

If you are running Visual Studio 2010 (Beta 2) on Windows 7, and you want to create a Windows Identity Foundation STS or relying party application, you need to run VS as an administrator, or it won’t create the project correctly.  I suspect it’s because it’s trying to install a cert, but there is some other stuff that fails too, probably as a result.  Once I ran VS as an admin, it all works fine. 

And, just for the record, WIF is awesome!  I’ve build an STS and relying app by hand for WCF 3, and this is SOOOOO much easier.  Excellent work guys!

Tuesday, December 15, 2009 4:16:05 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, November 25, 2009

I’m trying to get a handle on WF 4 (which is awesome, BTW) and currently working on persistence.  We have a need to encrypt the workflow instance data, and it took me quite some time to figure out how that might best be done.  The biggest drawback to working with WF 4 right now is that the documentation is pretty lame.  There are very few samples, and beta 2 hasn’t been around long enough to generate the “this is how you solve that problem” blog posts we’ve all come to depend upon.  I looked at PersistenceParticipant, but couldn’t see a good way to make that do what I wanted, then a bunch more time trying to figure out what was going on in the SqlWorkflowInstanceStore, etc. 

I think I’ve got a workable solution, although I’ve yet to actually try it out.  Turns out that the SqlWorkflowInstanceStore keeps all that good data in varbinary(MAX) columns, and only messes with them via a set of stored procs that get created when you create the instance store schema.  It should be an easy thing to modify said stored procs to use native SQL 2005/2008 column level encryption, without having to change the schema at all. 

I’ll let you know if it works…

Wednesday, November 25, 2009 1:30:39 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 

This one stumped me for a bit today, so I wanted to get it out there for the search engines to find... I created a new WCF Service Library project in VS 2010, taking all the defaults and targeting .NET 4.0. I needed to add a [WebGet] attribute so that I could make REST calls to the service. To do that, you need a reference to System.ServiceModel.Web.dll. It didn't show up on the list of .NET references in the Add Reference... dialog. OK, weird. So then I tracked down the file manually and added it. It got added to the list of references, but showed up with the yellow-triangle "I don't know how to find this reference" icon. Huh.

The problem turned out to be that for some reason, the project got created with a target framework of .NET 4.0 Client Profile, which doesn't include that assembly. Once I switched to the full .NET 4.0 target, it works just fine. The Client Profile seems like a strange choice for a WCF Service Library.

Wednesday, November 25, 2009 1:23:57 PM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, November 09, 2009

So I’m trying to figure out how to use WF 4 as a controller for a Prism app, and already I’m running into some interesting behavior.  First off, in anything but a very simple solution, custom activities don’t show up in the toolbox like they should.  That’s not a huge deal, but annoying.

Of greater interest (concern?) is the fact that if I put my workflow XAML file in the main WPF app solution, everything builds and runs just fine, except the workflow does absolutely nothing.  It just finished successfully, having run none of it’s activities.  If I take exactly the same XAML file and put it in another assembly, then run it from the WPF app, it works just like it should.  I’m guessing this is a byproduct of the new unified XAML engine, but I haven’t had time (or inclination really) to delve.  Mostly it just means I have to have at least one superfluous assembly, which for now isn’t too high a price to pay. 

The day I installed beta 2, I managed to crash the workflow designer about 10 times, but it seems to have settled down now.  Overall, I really appreciate the new model for WF, which seems much more composable and easy to use. 

Monday, November 09, 2009 9:09:28 AM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, November 06, 2009

I realize this is a bit late, but as of just about 4 weeks ago I’m now the Architect at Eid Passport.  I’m really looking forward to building some cool stuff, with a team that’s had quite a bit of experience in this space. 

In short, Eid Passport makes perimeter security systems for secure facilities, and manages access to those facilities by vendors.  For example, say you are the Coke delivery guy at a military base.  It’s a hassle to get through the gate every time you deliver, since they have to make sure it’s OK for you to be on the base.  Now the Coke guy has the option of going to our kiosk at the base and signing up for an access card that will allow him to spend much less time getting in and out.  We do some background checks, employment verification (does he still really work for Coke, etc.) and then issue a credential that he can use to get through the gate.  Now Coke delivery guy can make N more deliveries in a day because he’s not spending time at the gate.  This is a new domain for me, so there’s a lot to learn, but it’s pretty exciting stuff.  All the way from a handheld scanner that reads all kinds of cards to back end access control and data processing servers. 

If any of that sounds interesting to you, we’re looking for some additional developers.  There are instructions on the website (see above) for how to submit your resume if you are interested.

Friday, November 06, 2009 9:32:28 AM (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, June 17, 2009

We’ve added some new classes to the SoftSource training calendar, including a one-day Blend 2 class, and SQL 2008 for Developers.  Other offerings coming up are “Agile in a Day”, WPF, WCF, ASP.NET 3.5, LINQ, Silverlight, and of course, C#.  Discounts available for multiple students from the same organization, and custom on-site training also.

Wednesday, June 17, 2009 10:19:27 AM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  |