# Wednesday, 25 November 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, 25 November 2009 13:30:39 (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, 25 November 2009 13:23:57 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, 09 November 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, 09 November 2009 09:09:28 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, 06 November 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, 06 November 2009 09:32:28 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  |