I have been using the Service Factory Modelling Edition a lot lately, whilst they do produce a lot of projects and may appear unwieldy at first glance, the consistency of implementation alone is worth it in some of the larger implementations.

The issue I have was a need to migrate a Service Factory project into another pre-existing solution (I am a tidy freak).  The best way I found was to manually copy and edit the sln file; all you need to do is copy the ProjectMapping.xml file along with the folders containing the implementations and the models into the new solution folder, then start to edit the new sln file!  As a word of caution remember to make copies of everything before you start, as editing the sln file can lead to splinters...

In the project section for Solution Items add the ProjectMapping.xml file:

Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Solution Items", "Solution Items", "{A47C9E2B-340A-4E76-AA04-EE0B0A053637}"
            ProjectSection(SolutionItems) = preProject
                        ProjectMapping.xml = ProjectMapping.xml
            EndProjectSection
EndProject

If there is no Solution Items section just add a file to the root of the new solution in the IDE then close and start again.

The copy all of the Project sections relating the the folders and projects for the Service Factory from the original solution into the new solution, they are quite nicely grouped together, so this should be easy.  Just be wary to ensure that any other projects added to the original solution are not copied across.

Finally (to make sure you get all the solution folders setup correctly) copy all of the relevant nesting from the section:

GlobalSection(NestedProjects) = preSolution

This is usually at the end of the sln file, to the same location in the new sln.  If you have done everything correctly (some luck required) the new solution should open and build correctly in the IDE!  If the solution won't build and moans about project references, the most likely cause is the NestedProjects section. This section is sensitive to non existent projects, which is easy to do if If you are moving the project from a solution that contains more than just the Service Factory. Check each identifier in the section exists in the solution file, removing all those that don't.

After checking out a Visual Studio 2008 solution from our Subversion repository to a new machine (and new physical location) I started getting failure on the post build event reporting an exit code of 9009.  As ever it was building fin on another machine (luckily for once this failure wasn't on the continuous integration server).

With an exception like that It would have been easy to go off on one!  This project had some post build processing running in batch file, including RegAsm!  Looking at the simple things first, it had been checked out to a location with long file names such that the batch file was not running correctly.

	$(ProjectDir)\Install\Install.cmd  

Just wrapping the command in quotes sorted it. 

	"$(ProjectDir)\Install\Install.cmd"  

Ridiculously simple I know, but I thought I would write this one up - the way this was reported you could easily burn an hour or so chasing your tail...

So we all love the XmlSerializer right! Probably a lot more than the DataContractSerializer, but then we have had more time to get used to it's ways.  Most of the time we don't need to care what's going on, but sometimes (and usually when we are forced into doing some custom serialization) it doesn't do exactly what we expected and after the allowable "couple of minutes" of trial and error (or is that just me) we need to step through the serialization code to see what's up.

First thing needed is to add diagnostics switches on XmlSerializer in the applications config file:

   1: <system.diagnostics>

   2:       <switches>

   3:          <add name="XmlSerialization.Compilation" value="1" />

   4:       </switches>

   5: </system.diagnostics>

Then compile and run the application in debug to the point immediately after the XmlSerializer in constructed for the type:

   1: XmlSerializer ser = new XmlSerializer(typeof(MyType));

The dynamic assembly and c# source is created in c:\documents and settings\[user]\local settings\temp under XP or c:\users\[user]\appdata\local under Vista - open the latest created *.cs file in your debug visual studio instance and off you go!

Most people are aware that Workflow Foundation is a massively powerful flexible toolset to allow you to build workflow based applications.  In true golden hammer style, once you have used it you will be surprised just how many problems look like they need to be solved with workflow!  What you may have missed is that part of the delivery is a very powerful rules engine that can easily be used outside of workflow applications.

In an effort to keep this post short I will keep it very simple and demonstrate how easy it is to use the rules engine outside of the context of workflow activities.

Before you start make sure you have .NET 3.0 installed (http://www.microsoft.com/downloads/details.aspx?FamilyID=10CC340B-F857-4A14-83F5-25634C3BF043&displaylang=en), installed the Visual Studio 2005 extensions for WF (http://www.microsoft.com/downloads/details.aspx?familyid=5D61409E-1FA3-48CF-8023-E8F38E709BA6&displaylang=en) and finally make sure you have read the excellent introduction to the rules engine by Jurgen Willis http://msdn2.microsoft.com/en-us/library/aa480193.aspx.

The simplest way to create a RuleSet is to use the RuleSetDialog in the System.Workflow.Activities.Rules.Design namespace to create and edit a RuleSet. The dialog is supplied a context object on construction - basically the type is reflected to see what is available for the intellisense on the editor dialog.  To use the RuleSetDialog you need to reference the System.Workflow.Activities and System.Workflow.ComponentModel assemblies.

The RuleSetDialog allows you to define rules which are constructs similar to a basic If-Then-Else programming structure, with the condition and actions defined in an expression language based on the CodeDom model (read Jurgens article for more description).  Basically you can access properties and methods on you context object, and static methods on any class referenced within the host assembly.

The RuleSet is serialisable (to XAML), so dead easy to create persist and reload collections of rules - you can work this bit out for yourself.

To execute a RuleSet you use the RuleEngine in the System.Workflow.Activities.Rules namespace.  You supply it an instance of your object and then Execute and off it goes.

As you can see in this somewhat traditional bogus example, the rule checks for a literal value on a property of the context object, setting it to a different value if true.

Bogus though the example is, it doesn't take much imagination to picture how the rules engine can be harnessed to create massively powerful and extensible apps - with rules persisted outside of the app and editable by users that are able to operate on and affect data within your objects!  Get me a nail I have a new hammer...

I recently had to go back in time, and debug some traditional/classic ASP.  The fact that the code was relatively nasty is pretty much irrelevant, having the capability to debug and edit in my familiar Visual Studio 2005 IDE made the job a little easier to bear! Here are the steps to enable ASP debugging in studio...

Firstly you need to Enable Server Side ASP script Debugging in IIS - this can be done at the web site level or at the virtual directly level.  For the web site go to the Home Directory Tab on properties page, and for the Virtual Directory go to the Virtual Directly tab on the properties page.  From this tab select the Configuration button under Application Settings.  On the Configuration screen select the Debugging tab and check the Enable server-side ASP script debugging.

The quick way to get to the point of debugging with all code in the IDE is to open the Web site in Visual Studio (File, Open, Web Site).

If you are using server side JavaScript then you can use the debugger statement in code to force debugging - you are offered the choice of debug tools...  Or you can attach to the running process using Debug Attach to Process.  On XP the ASP process runs under a process dllhost.exe under the IWAM user.  Clearly you need to ensure you attach to the correct process, fortunately the IDE gives a nice visual warning if you get the wrong one.

Either way you do it you will be shown a warning when attaching to the process

And once you attach you can step through the code as normal!

In the code I was looking at there was another interesting feature.  At some point during the difficult and painful life of this product the page Language had managed to get set to JScript.Encode (even though the code was no longer encrypted) which blocks debugging.