Saturday, August 19, 2006

FP on the brain

I did a presentation for our internal user group about languages other than C# including SML, Scheme, and Ruby. I was attemping to illustrate functional programming, code as data, lazy evaluation, and dynamic typing to a group who had mostly only dealt with C#, partly to talk about elements from those sources that LINQ will incorporate and partly just to share my enthusiasm.

I hadn't touched SML in quite awhile, but it was really easy to pick back up and still was just as much fun to write. It's powerful, expressive, and has a nice, clean syntax. It might fit really well in a middle-tier type setting, since that would side step the need for strongly typed database access or a web service toolkit. I need to investigate SML.NET and F# some more as potential avenues to make this happen. The OCAML syntax of F# bugs me, but I read a cool paper linked off of LtU about its template/meta-programming capabilities which seemed really promising.

The more I learn about Ruby, the more I like it as a language, too. The dynamic typing bit still scares me some (especially after SML), but metaprogramming as a means to eliminate boilerplate junk and also to build internal DSLs is just cool. The interop with .net story isn't quite there yet, but I bet it will be soon. For the time being, I'm going to play around with using Ruby to generate C#/XML/WSDL/etc.

Tuesday, August 08, 2006

WF, ASP.NET, and transactions

My current project has some pretty simple business logic that seemed like it would be a good fit for WF. I was looking for a good excuse to try it out for real so I started investigating using it and immediately ran into several key problems.

The first is that there aren't many samples available relating to using WF with an ASP.NET host. Some of this is because it's still beta, but the only ASP.NET stuff available is either hopelessly trivial (start a workflow on a button click and then wait for it to finish before returning) or just not analogous to a real situation (no error handling, transactions, etc.). Additionally, you have to use a manual scheduler as opposed to the default one. I'm trying to get WF to replace business logic, so it would live in the service layer. I'd need extra code there to check whether we were running with the manual scheduler or not (in order to call RunWorkflow if necessary), which seems gross.

The other big issue is that it doesn't seem possible to have workflows participate in a transaction that is initiated by the host. My scenario involves keeping track of many running instances that all need to be finished and exported at once. This would involve iterating over each instance, sending it a specific event, and then, once all instances have been notified, running a stored proc (or something) once to do the export. All of that needs to be in one transaction, but it appears this isn't possible.

I might have to not use WF for this scenario if I can't find answers to those questions. I'm also concerned that if there aren't good answers, it may severely limit the applicability of WF.

Tuesday, August 01, 2006

More WinFX WF Beta 2 fun

Although I got my installation problems resolved on my laptop, my work machine continued to have problems with Workflow Foundation. When starting Visual Studio I'd get the following error:

Package Load Failure
Package 'Microsoft.Workflow.VSDesigner.DesignerPackage, Microsoft.Workflow.VSDesigner, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' has failed to load properly ( GUID = {FD526733-BD72-4F81-BEEC-BEB06E2AF59F} ).

I found some people who had similar problems that arose from using an incompatible WinFX beta with a pre-release version of Visual Studio, but nothing with RTM. While tracking down the problem I discovered how to generally troubleshoot Visual Studio package load failures. If you start Visual Studio from the command line with the "/log" option ("devenv /log"), an xml log file is created in "c:\Documents and Settings\[username]\Application Data\Microsoft\VisualStudio\8.0\" called "ActivityLog.xml".

Mine showed 1 warning (CheckPackageSignature failed; invalid Package Load Key {FD526733-BD72-4F81-BEEC-BEB06E2AF59F}) and 2 errors (SetSite failed for package [Microsoft.Workflow.VSDesigner.DesignerPackage, Microsoft.Workflow.VSDesigner, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35] and End package load).

Searching on those GUIDs and more detailed error messages I was able to find someone with a similar problem that resulted from having an old Add In file pointing to a location that no longer existed. Sure enough, in "C:\Documents and Settings\[username]\Application Data\Microsoft\MSEnvShared\Addins" I had a ".AddIn" file I had created ages ago in a folder that no longer exists. Once I deleted this file, Visual Studio loaded just fine.

I have no idea why this seemingly unrelated thing caused WF to fail, but at least it's resolved.