Ruurd Boeke Enterprise development and technobabble

Wednesday, February 20, 2008

Postcompiling for Entity Framework: Part III

This is the second of a series about how to go about using postcompilation in your solutions. You can read it as a tutorial on how to use PostSharp. I am very much a new to that framework, but the power it provides could seriously change how you build your applications. While working on the EF contrib project, I had to dive into PostSharp, and I hope to share some of the things I learned along the way.

This post introduces the first real step I took: the compound aspect.

The full table of contents:

Introducing Entity Framework Contrib- Easy IPoco implementation V 0.1

Part II, Postsharp Core versus Postsharp Laos

Part III, the compound aspect

Part IV, the PocoInterfaceSubaspect

Part V, hooking up the weaver

Part VI, the EdmScalarWeaver

Recap

We wish to create an attribute that can be placed on top of our ordinary Poco class, that will magically transform it into a class that implements the 3 IPoco interfaces. These are needed by the Entity Framework to do it's work. We will use PostSharp to do this.
Post 1 introduced the project and post 2 introduced PostSharp.

The Compound aspect

I have created an attribute class that can be placed on top of other classes, like so:

    /// <summary>     
    /// <para>     
    /// Attribute that can be used to decorate normal POCO classes with. It is used to start off a post compilation phase     
    /// that will modify the IL of the class. After this phase, the class will implement:     
    /// <list type="">     
    /// <item>INotifyPropertyChanged</item>     
    /// <item>IEntityWithChangeTracker</item>     
    /// <item>IEntityWithKey</item>     
    /// <item>IEntityWithRelationships</item>     
    /// </list>     
    /// </para>     
    /// <para>     
    /// It will also place EDMScalarattributes on your properties.     
    /// </para>     
    /// <para>This results in a type that is completely ready for consumption by the EntityFramework</para>     
    /// </summary>     
    [AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = false)]     
    [MulticastAttributeUsage(MulticastTargets.Class, AllowMultiple = false)]     
    public sealed class PocoAttribute : CompoundAspect     
    { 

... implementation   
    }

As you can see it inherits from the compound aspect class, from the PostSharp.Laos assembly.

The compound aspect basically allows you to define other aspects to do the job for you. This is very nice when you want to do more things, but only want to use one aspect.

By overriding the ProvideAspects method, we can add our other aspects:

  1         public override void ProvideAspects(object element, LaosReflectionAspectCollection collection)     
  2         {     
  3             // Get the target type.     
  4             Type targetType = (Type)element;     
  5     
  6             // implement the INotifyPropertyChanged interface on the class     
  7             collection.AddAspect(targetType, new AddNotifyPropertyChangedInterfaceSubAspect());     
  8             // implement the three IPOCO interfaces on the class     
  9             collection.AddAspect(targetType, new PocoInterfacesSubAspect());     
 10             // inspect the complete class and add EDM scalar attributes to the properties     
 11             collection.AddAspect(targetType, new EDMAttributesSubAspect(this.EDMContainerName, Name, NamespaceName, PathToConfigFile));     
 12     
 13             // iterate the properties     
 14             foreach (PropertyInfo property in targetType.UnderlyingSystemType.GetProperties())     
 15             {     
 16                 if (property.DeclaringType == targetType && property.CanWrite)     
 17                 {     
 18                     MethodInfo method = property.GetSetMethod();     
 19     
 20                     if (!method.IsStatic)     
 21                     {     
 22     
 23                         // throw notifypropertychanged events     
 24                         collection.AddAspect(method, new OnPropertySetNotifyPropertyChangedSubAspect(property.Name, this.AspectPriority));     
 25     
 26                         // TODO: possibly refactor to only include edm properties     
 27                         // call the changetracker     
 28                         collection.AddAspect(method, new OnPropertySetChangeTrackSubAspect(property.Name, this.AspectPriority));     
 29                     }     
 30                 }     
 31             }     
 32         }

As you can see, on line 4 I cast the element parameter to a type. That is the type we have adorned with our attribute (your 'Person' Poco class, for instance). Then, I specify that I want 3 other aspects to work on this type!

The AddNotifyPropertyChangedInterfaceSubAspect, will implement the INotifyPropertyChangedInterface. (note: this aspect is added just for simplicity, it has nothing to do with IPoco, so I might remove it).
The PocoInterfaceSubAspect, will implement the 3 interfaces (see following post)
The EDMAttributesSubAspect, will put EDMScalar attributes on top of our properties, needed by EF to do it's job

After that, I loop through the properties in our targetType and add aspects to their setters. These will inject methods into the setters to throw the PropertyChanged event and let the EF changetracker know that the property was changed.

That's all the work this compound aspect does. It just provides aspects to the correct codeblocks. The real work is done inside of these aspects and will be explained in following posts.

EF-Contrib

Wednesday, February 20, 2008 1:34:36 PM (Romance Standard Time, UTC+01:00)

Comments [0] | Trackback

Scott announces WPF enhancements

Scott Guthry announces the .Net 3.5 client product Roadmap here.

Highlights are improved bootstrapping of 3.5 for your client applications and improved cold startup times.

But the real news for the WPF addicts: the dropshadow and blur bitmap effects will now be hardware accelerated!! That is a big thing. These effects are completely useless at the moment, but if they are hardware accelerated, you will be able to do some great stuff. He also hints at a new effects API and data virtualization support.

On top of that, he announces that there is a real DataGrid control coming, and my personal favorite: a Calendar/Datepicker control.

I can easily live without a datagrid, these are so easy to create with the listview, that I don't see a reason to actually build a new control. However, the lack of an official datepicker is in-excusable for enterprise applications. I'm happy to see they are working on it!

WPF (Avalon)

Wednesday, February 20, 2008 12:16:33 PM (Romance Standard Time, UTC+01:00)

Comments [0] | Trackback

MVC with WF: new sample application

This is an intermezzo from the MVC with WF series. I have added a new sample to the project, which I hope demonstrates the flexibility of using WF.

The rest of this series can be found here:

Workflow as controller: Introducing <M,V,C> where M: ViewModel, V : WPF, C : WF

Part II, starting the application, and the adapter

Intermezzo: new sample application

Part III, your first view

Part IV, decoupling view from controller

Part V, marshalling commands from WPF to WF

Part VI, Injecting a controller in a subview / workspace

Part VII, IOC on the cheap: injecting and retrieving objects

Part VIII, Broadcasting for all to see

It is a simple 4 screen 'wizard' where logic determines that it should skip one screen. Also, when the save button is hit, a popup will show that asks if you are sure. If you are, you will be sent to the first screen, otherwise you will return to your last screen. It has buttons on the left that determine where you can go, as well as 'next' and 'previous' buttons.
All of this was done with a minimum of code and a maximum of dragging and dropping activities. The whole reason for doing this, is that when you now get a new feature request ("We have a new screen that sits in between the client and adres screen!!!"), using WF it will be dead-simple to add it.

I have uploaded the executable here, just in case you don't feel like opening up the project and building yourself.
The application looks like this:

And when you reach the 'Car' screen, it will look like this:

Hitting the Save button here:

A few things to notice about this sample:

There are 2 controllers doing their job here:
- The usersettings controller, with a view on top. It allows you to check a checkbox. Doing so makes you an administrator. Notice how, when you do so, you are able to browse to the 'Role' screen. You see, if you are not an administrator, you are not allowed to enter the role screen.
- The 'ImportantWizardController', which handles the mainview. It shows a few buttons (Client, Adres, Role and Car) on the left, which will allow you to go to the screens you have already passed. It also shows a previous and next screen button. Finally, it defines a contentpresenter where our subviews will be injected.
The buttons react immediately. Go to the Car screen, and then check your checkbox to make yourself Administrator. This means you have the right to visit the Role screen, and it immediately pops up.
No code behind. Nowhere. The only codebehind is on the ImportantWizardControl to 'load data' (actually returning an empty client, but you get the drift).
It felt really cool to build this plumbing without coding.

Let's look at the steps to produce this application:

I added a Controller project (type workflow), a Domain project (with a few very simple classes), a shell project that will be used to start us up and a view project which holds the views we are going to use:
I created a ClientService and a UserService class which will be classes used by our workflows:

    [Serializable]
    public class UserService
    {
        public bool IsAdministrator { get; set; }

    }

    [Serializable]
    public class ClientService
    {
        public Client CurrentClient { get; set; }

    }

Then the shell was used to inject our main view and also inject a global userservice class:

  1 <Window x:Class="EditLogicShell.Window1"
  2     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  3     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  4     xmlns:logic="clr-namespace:EditLogicControllers;assembly=EditLogicControllers"      
  5     xmlns:c="clr-namespace:ControllersAdapters;assembly=ControllersAdapters"
  6     Title="Window1" Height="300" Width="300">
  7     <Window.Resources>
  8         <logic:UserService x:Key="globalUserService" />
  9     </Window.Resources>
 10     <StackPanel>
 11         <Border BorderThickness="1" BorderBrush="Black" Background="Beige">
 12             <c:GenericWorkflowAdapter WorkflowController="{x:Type logic:ManageUserSettingsController}" />
 13         </Border>
 14         
 15         <c:GenericWorkflowAdapter WorkflowController="{x:Type logic:ImportantClientWizard}" />
 16     </StackPanel>
 17 </Window>

Note line 8, where we place a UserService instance in the resources section
On Line 12 we start our UserSettings controller
On Line 15, we start our main wizard.

Let's not go into the usersettings controller. It's just too simple. It will inject a view, and set the datacontext to the userservice class. He retrieved that class using the 'RetrieveObjectFromResources' activity.
I then asked our designer (yup, that was me too... could you tell??) to design our individual views. Everywhere the designer knew he had to interact with the system, a command was created in a static class. That class turned out to be like this:

    public static class ImportantWizardInteractions
    {
        public static readonly RoutedUICommand Next;
        public static readonly RoutedUICommand Back;

        public static readonly RoutedUICommand GotoClientScreen;
        public static readonly RoutedUICommand GotoAdresScreen;
        public static readonly RoutedUICommand GotoRoleScreen;
        public static readonly RoutedUICommand GotoCarScreen;

        public static readonly RoutedUICommand Save;
        public static readonly RoutedUICommand SaveYes;
        public static readonly RoutedUICommand SaveNo;

        static ImportantWizardInteractions()
        {
            Next = new RoutedUICommand("Next", "Next", typeof(ImportantWizardInteractions));
            Back = new RoutedUICommand("Back", "Back", typeof(ImportantWizardInteractions));

            GotoClientScreen = new RoutedUICommand("GotoClientScreen", "GotoClientScreen", typeof(ImportantWizardInteractions));
            GotoAdresScreen = new RoutedUICommand("GotoAdresScreen", "GotoAdresScreen", typeof(ImportantWizardInteractions));
            GotoRoleScreen = new RoutedUICommand("GotoRoleScreen", "GotoRoleScreen", typeof(ImportantWizardInteractions));
            GotoCarScreen = new RoutedUICommand("GotoCarScreen", "GotoCarScreen", typeof(ImportantWizardInteractions));

            Save = new RoutedUICommand("Save", "Save", typeof(ImportantWizardInteractions));
            SaveYes = new RoutedUICommand("SaveYes", "SaveYes", typeof(ImportantWizardInteractions));
            SaveNo = new RoutedUICommand("SaveNo", "SaveNo", typeof(ImportantWizardInteractions));

        }
    }
And on individual screens, the commands were used like this:
```
            <Border Background="Beige" BorderThickness="1" BorderBrush="Black" DockPanel.Dock="Left" Width="120" >
                <ListView>
                    <Label FontWeight="Bold">Previous screens</Label>
                    <Button Command="{x:Static local:ImportantWizardInteractions.GotoClientScreen}">Client</Button>
                    <Button Command="{x:Static local:ImportantWizardInteractions.GotoAdresScreen}">Adres</Button>
                    <Button Command="{x:Static local:ImportantWizardInteractions.GotoRoleScreen}">Role</Button>
                    <Button Command="{x:Static local:ImportantWizardInteractions.GotoCarScreen}">Car</Button>
                </ListView>
            </Border>
(This is the list of buttons that are shown on the left hand side of the screen)
```
The views were passed to the developer (guess who) and the following state machine was created:

Obviously a thing of beauty.
1. The state initialization will retrieve the userservice, load data, set our maincontent to the mainView and set our next state to clientDetails
2. The clientdetail has an initialization as well: it will set the datacontext to our customer and inject the ClientView as a datatemplate. Then it waits for only one command: Next. If that is triggered, it will simply move to the AdresDetails State.
  When moving out of a state, the state finalization is triggered, which will remove the view from the resources.
  Note how great it is never to have to think about that cleanup code again, it is always executed when moving out of a state.
3. The adresDetails state has a few more commands it will listen to. When moving 'Next', a piece of logic is executed:
  
  There is a declerative rule in the IF/ELSE that goes a little something like this: this.GlobalUserService.IsAdministrator == True
  That rule is automatically put in the rules repository and can be used by others. It determines if the next screen will be the Role screen or the CarDetails screen.
4. Role is simple.
5. CarDetails also reacts to the Save-command. When it get's triggered, it will inject our popup into the resources section, and move on to the save state.
6. The Save state will react to 'SaveYes' and 'SaveNo'. It will remove the popup from the resources, and go to another state.
The views are dead simple, just binding to properties. However, the ImportantWizardMainView does require our attention. It has this definition for our subview:
```
            
            <ContentPresenter 
            Content="{Binding RelativeSource={RelativeSource FindAncestor, 
            AncestorType={x:Type local:ImportantWizardMainView}, AncestorLevel=1}, Path=DataContext}" 
            ContentTemplate="{DynamicResource CurrentWizardScreen}" />
```
Apparently, when using the contentTemplate, the datacontext is not inherited. So I have to set it up to react to the changing datacontext of our main screen. So, when the DataContext of ImportantWizardMainView is changed, the Content of our presenter is changed to match it. (Leave comment on how I could do this simpler, if you know how).
Also interesting is that I used a Grid on that view, with two children that overlay eachother. The other child is our popup screen:
```
        
        <ContentPresenter ContentTemplate="{DynamicResource PopupScreen}" />
```
When we set a datatemplate with name Popupscreen, it will be shown on top of our regular screen. I like it!

I have added a new activity, InjectViewAsDataTemplate. We already had the InjectControllerAsDataTemplate, but there are times you don't want a whole controller.

I've replaced the original project file with the most recent. It can be found here.
If you are interested in seeing more about this subject, please leave a short comment!

WF (Workflow) | WPF (Avalon)

Wednesday, February 20, 2008 11:55:27 AM (Romance Standard Time, UTC+01:00)

Comments [0] | Trackback

Tuesday, February 19, 2008

Postcompiling for Entity Framework: Part II

This post quickly introduces PostSharp, before we move on to the real stuff!

The full table of contents:

Introducing Entity Framework Contrib- Easy IPoco implementation V 0.1
Part II, Postsharp Core versus Postsharp Laos
Part III, the compound aspect
Part IV, the PocoInterfaceSubaspect
Part V, hooking up the weaver
Part VI, the EdmScalarWeaver

PostSharp

The PostSharp home introduces PostSharp as follows:

PostSharp is a tool that can reduce the number of lines of code and improve its logical decoupling. Therefore its helps you delivering higher stability, cleaner design, and cheaper source code maintenance

And best of all, PostSharp is free and open source. Yes, even for commercial use

Basically, it allows you to use attributes on top of code to indicate that after the normal visual studio compilation, PostSharp should do 'something' to the code. That 'something' could be anything you want. The result is a compiled assembly that does more than you would expect from the sourcecode. This is a good thing, when you have 'code noise': code that might be important, but distracts from the real work.

Code noise could be your logging mechanism, or your transaction mechanism. In my case, I did not want to implement the IPoco interfaces that EntityFramework needs, in order to make my business objects work with EntityFramework. I want my business objects to represent a person, car or whatever, and not have to deal with the data access logic at all.

The simplest example you can think of, is shown on the frontpage:

public class SimplestTraceAttribute : OnMethodBoundaryAspect  
{  
  public override void OnEntry( MethodExecutionEventArgs eventArgs)  
  {  
    Trace.TraceInformation("Entering {0}.", eventArgs.Method);  
    Trace.Indent();  
  }  
  public override void OnExit( MethodExecutionEventArgs eventArgs)  
  {  
    Trace.Unindent();  
    Trace.TraceInformation("Leaving {0}.", eventArgs.Method);  
  }  
}

By adding an [SimplestTrace] attribute on top of your code, you will have instant tracing information, without actually seeing it in your code. The fun thing about PostSharp is, that this code is actually in your assembly after post-compilation, as opposed to other AOP frameworks, that will do it at runtime.

Laos versus Core

PostSharp offers a full representation of your code, a bit like reflection. But it can be hard to work with. That is why PostSharp Laos was created. Laos is a 'plugin' on the core functionality that abstracts away most of the hard stuff, and leaves you with ready to implement aspects.

I found it wildly confusing the first time I came across the two parts of postsharp. Laos is such a high-level abstraction, that you use it quite differently from Core. In the latter, you have to spinup your own weaver, in Laos you do not ever see a weaver.
(A weaver is a class that will actually inject IL methods into your assembly.)

When you use Laos, some smart hooks exist to use it's own weaver. That weaver knows how to deal with Laos Aspects. And so, you can use the Laos abstractions without any knowledge about IL or weaving.

The shown example uses the OnMethodBoundaryAspect, from Laos. The Laos weaver will inject the necessary IL methods on every method (that matches your desire to trace it) to call the OnEntry and the OnExit methods you defined. There are quite a few aspects ready to inherit from. I urge you to look at the documentation to find out which.

If you were to implement that functionality using the Core library, you would have to inject all the IL yourself. It would however, give you the opportunity to actually inject the Trace calls into the methods, instead of the easier method calls.

One very interesting aspect that Laos offers, is the CompositionAspect, which allows you to set a specific interface to implement and give an implementation object that is called for every defined method on the interface. I use it for the three IPoco interfaces.

In short: Laos is a very high-level abstraction that will get you very far. In some cases you need to take it a little further, and you will need Core.

In the next couple of posts, I will show both the Laos aspects and the Core aspect, how they were applied and how they do their job.

EF-Contrib

Tuesday, February 19, 2008 12:28:26 PM (Romance Standard Time, UTC+01:00)

Comments [0] | Trackback

MVC with WF: Part II, starting the application

This is the second of a series about using Workflow Foundation to control your UI Logic in a WPF application. The full table of contents:

Workflow as controller: Introducing <M,V,C> where M: ViewModel, V : WPF, C : WF

Part II, starting the application, and the adapter

Intermezzo: new sample application

Part III, your first view

Part IV, decoupling view from controller

Part V, marshalling commands from WPF to WF

Part VI, Injecting a controller in a subview / workspace

Part VII, IOC on the cheap: injecting and retrieving objects

Part VIII, Broadcasting for all to see

I thought it best to just put out that TOC, to force myself to actually write these short posts ;-)

Recap

In the previous post, the complete solution was presented. I am presenting a solution to use workflow as the controller part in your MVC inspired WPF application. It is inspired on the thought that you do not need complex frameworks, because WPF already gives you great power (routed eventing, resources). So, no IOC is used, no event aggregator etcetera: it's taken care of by WPF and WF, a natural fit.
The solution is very decoupled and I feel it's a great advantage to be able to visual your control logic.

Starting the application / Shell

The term 'Shell' is used to indicate a startable 'host' for your application. In WPF, that is probably your App.xaml view. In there, you point to a startupUri of a window. We do not need anything different for our application, but we do need to start the workflow runtime.

I have chosen not to build a generic application.start method, because I am still thinking about threading. For now, I have chosen to use the ManualWorkflowSchedulerService to let the workflow instances do it's thing. Normally the workflow runtime uses a workerthread to execute the workflow instances on the background. That means that when you send a command to the workflow, it will be run in the background. That sounds great, but will give you some pain when changing data that is bound to the UI thread. For this first version, I did not want that pain, so I used the ManualWorkerThreadScheduler. Now, the workflow instance will do nothing, until we explicitly donate our (UI)thread to it.

Starting the runtime is simple:

  1         public App() 
  2         { 
  3             // start a workflow runtime 
  4             workflowRuntime = new WorkflowRuntime(); 
  5 
  6             ManualWorkflowSchedulerService manualSvc = new ManualWorkflowSchedulerService(false); 
  7             workflowRuntime.AddService(manualSvc); 
  8 
  9             ExternalDataExchangeService dataSvc = new ExternalDataExchangeService(); 
10             workflowRuntime.AddService(dataSvc); 
11             dataSvc.AddService(new CommandService(workflowRuntime));    // add our generic communication service 
12 
13 
14 
15             workflowRuntime.StartRuntime(); 
16             workflowRuntime.WorkflowTerminated += new EventHandler<WorkflowTerminatedEventArgs>(workflowRuntime_WorkflowTerminated); 
17             workflowRuntime.WorkflowAborted += new EventHandler<WorkflowEventArgs>(workflowRuntime_WorkflowAborted); 
18             workflowRuntime.WorkflowCompleted += new EventHandler<WorkflowCompletedEventArgs>(workflowRuntime_WorkflowCompleted); 
19 
20 
21             ControllersAdapters.WorkflowRuntimeHolder.SetCurrentRuntime(workflowRuntime); 
22 
23             this.Exit += new ExitEventHandler(App_Exit); 
24         }

At line 7, the ManualWorkflowSchedulerService is indeed added to the runtime.
At line 11, our own communicaton class (CommandService) is added to the runtime. You can interpret the runtime as a global object container: when we ever want to use that commandService singleton, we can just ask the runtime for it.
Lines 15 through 18 hookup some eventhandlers to certain events. We'll cover them next.
Line 21 sets this runtime at a static propery for the controllerAdapters to fetch. A quick and dirty solution.

The events that we subscribe to are handled as follows:

  1         void workflowRuntime_WorkflowCompleted(object sender, WorkflowCompletedEventArgs e) 
  2         { 
  3             ICommandService cmdsvc = workflowRuntime.GetService(typeof(ICommandService)) as ICommandService; 
  4 
  5             cmdsvc.SendMessage(new InstanceWasRemovedMessage(e.WorkflowInstance.InstanceId)); 
  6         } 
  7 
  8         void workflowRuntime_WorkflowAborted(object sender, WorkflowEventArgs e) 
  9         { 
10             ICommandService cmdsvc = workflowRuntime.GetService(typeof(ICommandService)) as ICommandService; 
11 
12             cmdsvc.SendMessage(new InstanceWasRemovedMessage(e.WorkflowInstance.InstanceId)); 
13         } 
14 
15         void workflowRuntime_WorkflowTerminated(object sender, WorkflowTerminatedEventArgs e) 
16         { 
17             ICommandService cmdsvc = workflowRuntime.GetService(typeof(ICommandService)) as ICommandService; 
18 
19             cmdsvc.SendMessage(new InstanceWasRemovedMessage(e.WorkflowInstance.InstanceId)); 
20         } 
21 
22         void App_Exit(object sender, ExitEventArgs e) 
23         { 
24             workflowRuntime.StopRuntime(); 
25         }

As you can see, I fetch the command service from the runtime, and ask it to send a message. The commandservice will 'broadcast' this message to all living controller adapters. When a workflow is finished, either by termination or just because it finished it's process, we need to let the adapter know so that it can unsubscribe from events from the commandservice.

The adapter

The GenericWorkflowAdapter is a WPF control that handles the communication between WPF and WF. We will see pieces of it in the upcoming posts, but we'll need to go into a little more detail here.

    /// <summary> 
    /// This is a WPF type that can be placed anywhere in your UI tree. It can be configured with a workflow type. 
    /// When it is, it will instantiate the Workflow. 
    /// This adapter will then be able to pick up WPF Command (RoutedUI) and send them to the workflow, as well 
    /// as listen to events coming from the runtime, the commandsvc and the workflow instance 
    /// </summary> 
    public class GenericWorkflowAdapter : ContentControl, IWeakEventListener 
    { 
           ... 
    }

As you can see, it is a contentControl. The workflowcontroller is able to place an arbitrary view as it's content.
It has one property: WorkflowControllerProperty, typeof(Type), which will fire off the SetWorkflowController method when it is set.

  1         private void SetWorkflowController(Type type) 
  2         { 
  3             // actually start the controller! 
  4             instance = runtime.CreateWorkflow(type); 
  5             instance.Start(); 
  6 
  7             // allow it to do it's thing 
  8             threadSvc.RunWorkflow(instance.InstanceId); 
  9 
10             Debug.WriteLine(String.Format("Adapter has started workflow instance {0}, of type {1}", instance.InstanceId, type.ToString())); 
11 
12 
13             // we will filter commands to only manage commands that we have defined in our workflow 
14             // so we have to walk recursively through all activities 
15             IEnumerable<System.Workflow.ComponentModel.Activity> flattenedActivities = 
16                 (instance.GetWorkflowDefinition() as System.Workflow.ComponentModel.CompositeActivity).EnabledActivities. 
17                 SelectRecursiveSimple(activity => (activity is System.Workflow.ComponentModel.CompositeActivity) ? 
18                     ((System.Workflow.ComponentModel.CompositeActivity)activity).EnabledActivities : 
19                     new System.Collections.ObjectModel.ReadOnlyCollection<System.Workflow.ComponentModel.Activity>(new List<System.Workflow.ComponentModel.Activity>())) 
20             ; 
21 
22             // let's get the handlecommands 
23             var commands = flattenedActivities.Where(act => act is HandleCommand).Select(act => ((HandleCommand)act).CommandName) 
24             ; 
25 
26             implementedCommands = new ReadOnlyCollection<string>(commands.ToList()); 
27 
28             SetupCommandSinks(); 
29         }

As you can see, this method actually goes into the workflowruntime and ask for it to spin up a workflowinstance. Then it donates it's thread to actually 'run' the instance. The workflow instance probably has initialization code attached to it. That code get's run at this point.

At line 15, I use Linq to go through every activity that is defined in the workflow and look at the HandleCommand activities. These are activities that wait for a command and act upon it. I need to know which commands this workflow might respond to, so I create a readonly collection from this. Later, we will only let the adapter pass commands that are actually implemented by the workflow!

At line 28, there is a call to setup the command sinks:

        private void SetupCommandSinks() 
        { 
            // set up command sinks 
            CommandManager.AddExecutedHandler(this, CmdExecuted); 
            CommandManager.AddCanExecuteHandler(this, CmdCanExecute); 
        }

Here you see the simple code that will register this contentcontrol to handle RoutedUICommands from WPF. As you can probably guess, when a command reaches these handlers, they will be filtered by the 'implementedCommands' collection we defined earlier on, and if they are implemented AND they are currently enabled, the command is posted to the workflow.

I have setup two events: the lost and gotFocus events, to also send commands to the workflow. If the workflow chooses to do so, it can handle these. I use them to remove and add options to the menu shell.

The last thing to cover, is the ReceiveWeakEvent method. This adapter will register itself at the commandService, and the commandService will subscribe the adapter to a few events. It uses weakevents to do so, so that the lifespan of this adapter is not tied into the commandService (which will live forever).
There are a whole host of message that can be sent in the system, and the ReceiveWeakEventMethod will implement different behavior for all of them. It will look at at the arguments that were passed, and check for a specific type.

(I might refactor that, to actually put the logic into the messages).

That's it for now, in the next post we will actually get our hands dirty and put together our first application!

WF (Workflow) | WPF (Avalon)

Tuesday, February 19, 2008 11:36:14 AM (Romance Standard Time, UTC+01:00)

Comments [0] | Trackback

Monday, February 18, 2008

Introducing Entity Framework Contrib: Easy IPoco implementation V 0.1

In this post I'd like to introduce version 0.1 of the first Entity Framework contribution project: Automatically implement the IPoco interfaces.
The project is aimed at helping you build your domain layer in a more persistence ignorant way, than is possible at this moment.

[official codeplex location of the project is here]

The full table of contents:

The Problem: baseclass needed

Microsoft is on the brink of releasing the Entity Framework. It is at beta 3 at this moment. If you are reading this blog, you are probably familiar with it, but let's do a quick summary:
The Entity Framework is a framework that maps between a database and your domain objects. It's grand vision is to easily allow you to (with a funky design-experience) create (multiple) conceptual models that know how to talk to the database. Although more than an OR-mapper, most people like to position it as such anyway.
EF is an abstraction layer on top of your datastore and will allow you to work with business objects that actually make sense from an object-oriented perspective, instead of making you work with datarows, tables and sets.

One part of the criticism that the Entity Framework gets at this moment, is the lack of persistence ignorance. This means that, when you use the Entity Framework, you will have to create business entities that are aware of the Entity Framework (they need to derive from a Entity Framework baseclass).
This goes against too many principles to mention, and the ADO.Net team have gotten quite a bit of comments about it (other more mature frameworks, like nHibernate do not force you into this). Rightfully so!
In the end, Daniel Simmons blogged about the criticism here: Persistence Ignorance: OK, I think I get it now.

The suggested Solution: implement interfaces

In order to take away the need to implement a base-class, the EF-team created a few interfaces that need to be implemented. That is as far as they can go in the first release.

So, you can implement 3 interfaces on your business objects, and no baseclass is needed.
Although much better, I feel I should not have to spend time on, or burden my domain layer with, code to facilitate data access. My domain layer should be able to focus on one thing: solving the business problems of the client.
By introducing other code to my domain layer, developers will be distracted.

Bill McCafferty posts about DDD (Domain Driven Design) and EF here. He concludes:

In short, and at the risk of being laconic, I feel that the ADO.NET Entity Framework does for data communications what the ASP.NET page life cycle did for the presentation layer. In trying to introduce simplification and increased productivity, it's actually going to result in higher complexity and decreased maintainability in the long run. I appreciate what Microsoft is trying to do, and absolutely love some of their other ideas, but, for now, I'm going to pass on the ADO.NET Entity Framework.

Billy McCafferty

He is quite right!!

EF-Contrib: Easing the implementation of these interfaces

The 3 interfaces we are talking about are:

IEntityWithChangeTracker
IEntityWithKey
IEntityWithRelationships

Implementing these interfaces is sometimes called "IPoco": Poco stands for Plain Old C# (or Code) Object, and the I in IPoco means that you can still use your Poco object but have to implement these interfaces. (so, not Poco at all... but still!)

The current checked in project (find it here) uses Postsharp to actually change the IL-code of your assembly and implements these interfaces. That means that you can build a domain layer with a class like this:

    [Poco("ConnectionName")] 
    public class Person 
    { 
        public int PersonID { get; set; } 
        public string Firstname { get; set; } 
        public string Lastname { get; set; } 
    } 

After compilation, the class will actually look a bit different on disk:

    public class Person : IEntityWithChangeTracker, IEntityWithKey, IEntityWithRelationships 
    { 
... 
    } 

So you can use this Person class, like you would use the classes that EF generates.

It is important to understand that there will be very little runtime performance costs involved. The code transformation is done at compile-time, once. At runtime, there is no magic AOP or whatever involved.

This approach is used by several other OR-Mappers and is very common in the Java world.

Is this Persistence Ignorance?

Obviously, it's not. Hopefully, in version 2.0 of the Entity Framework, full ignorance is achieved. However, if you want to use EF at your datalayer today, this approach will let you focus on the important stuff, instead of data access code.

Imagine changing your conceptual model. When implementing IPoco yourself, you will have to take care to change all kinds of attributes on top of your properties. This will quickly become a burden.

How does it work?

You will need to download and install Postsharp on all the machines that will build your application (developer machines and teambuild machine(s)).
Your domain layer will have to reference the EntityFrameworkContrib.PostSharp4EF assembly, and the PostSharp.Laos and PostSharp.Public assemblies. By referencing these, Postsharp will know to do a post-compilation phase on your assemblies.
You will need to supply a 'psproj' file in your assembly, to let our attribute know where it should look to actually do the implementation. This allows me to seperate the implementation assembly from what you need at runtime!
You have already created your edmx file, which EF will dissect into the individual .csdl, .msl and .ssdl files and place them in your bin/debug folder.
The project for now assumes a connection string to be present in your app.config
You can create your own simple business object.
That connection string is needed during the postcompilation phase to get to the individual mapping files, so use the attribute [Poco("")] to let us know you need to change this class.
The interfaces are implemented and the setters of your properties are modified to actually do changetracking
Actually, at this moment: INotifyPropertyChanged is implemented as well (let me know if you actually want this).

So, let's first look at the psproj file you need. In the Test-project, there is one already:

<Project xmlns="http://schemas.postsharp.org/1.0/configuration">
	<SearchPath Directory="../EntityFrameworkContrib.PostSharp4EF.Weaver/bin/{$Configuration}"/>
	<SearchPath Directory="{$SearchPath}" />
	<Tasks>
		<AutoDetect />
		<Compile TargetFile="{$Output}" IntermediateDirectory="{$IntermediateDirectory}"  CleanIntermediate="false" />
	</Tasks>
</Project>

The referenced assembly EntityFrameworkContrib.PostSharp4EF only defines the Poco attribute, but does not contain the actually 'code-weaving'. If we would have placed the code-weaving in the same assembly as the Poco-attribute, you would have a much larger assembly to reference and you could get into licensing problems. By separating them, you only need to reference a tiny assembly.

The weaving assembly should not be distributed with your final product!

However, during the build, PostSharp does need to find the weaving assembly. Therefor, you need to create a psproj file that extends it's normal searchpath to also include the weaving dll.
Take care in naming the file: it should be named "projectname.psproj".

When the project is more mature, you might find it best to actually just place the weaving assembly into one of the default searchpaths for postsharp to find, and you will not need this psproj file.

Now, let's look at our attribute:
In it's constructor, it takes the name of the EDMcontainer, which should match your connection string. I have also added a few properties: Name, NamespaceName, PathToConfigFile. I'll get back to these in a later post. In the future, others will be added.

During the weaving, I have to do quite a bit of work to actually get to the correct mapping files. So, I try to load in your app.config and extract the file path's from it. The Testproject has the following app.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <connectionStrings>
    <add name="OneSimpleTypeConnection" connectionString="metadata=.\bin\debug\OneSimpleType\OneSimpleType.csdl|.\bin\debug\OneSimpleType\OneSimpleType.ssdl|.\bin\debug\OneSimpleType\OneSimpleType.msl;provider=System.Data.SqlClient;provider connection string=&quot;Data Source=VISTAX64\SQLEXPRESS;Initial Catalog=EntityFrameworkTest;Integrated Security=True;MultipleActiveResultSets=True&quot;" providerName="System.Data.EntityClient" />
  </connectionStrings>
</configuration>

So, after loading that app.config, I use the supplied ConnectionContainer to get that connectionstring, and then use some simple regex work to get the path's to the mapping files. Then I try to load these to create a MetadataWorkspace.

When I finally have a MetadataWorkspace, stuff get's easier: I can iterate the properties in our original class and find the property in the metadataworkspace. Then I create the correct EDMScalar Attributes on top of those.

Implementing the interfaces is done by PostSharp, where it will look at an interface and just use a class I provide to call when one of the interface methods is called.

The result

Let's look through reflector at how the end result looks like. I won't show the methods, to keep things short and sweet.

  1 [EdmEntityType(Name="Person", NamespaceName="EntityFrameworkContrib.PostSharp4EF.Tests.OneSimpleType")] 
  2 public class Person : INotifyPropertyChanged, IComposed<INotifyPropertyChanged>, IProtectedInterface<IFirePropertyChanged>, IPocoFacade, IComposed<IPocoFacade> 
  3 { 
  4     // Fields 
  5     private IPocoFacade ~EntityFrameworkContrib.PostSharp4EF.IPocoFacade; 
  6     private readonly InstanceCredentials ~instanceCredentials; 
  7     private INotifyPropertyChanged ~System.ComponentModel.INotifyPropertyChanged; 
  8     [CompilerGenerated] 
  9     private string <Firstname>k__BackingField; 
10     [CompilerGenerated] 
11     private string <Lastname>k__BackingField; 
12     [CompilerGenerated] 
13     private int <PersonID>k__BackingField; 
14 
15     // Methods 
16     static Person(); 
17     public Person(); 
18     void INotifyPropertyChanged.add_PropertyChanged(PropertyChangedEventHandler value); 
19     EntityKey IEntityWithKey.get_EntityKey(); 
20     RelationshipManager IEntityWithRelationships.get_RelationshipManager(); 
21     void INotifyPropertyChanged.remove_PropertyChanged(PropertyChangedEventHandler value); 
22     void IEntityWithKey.set_EntityKey(EntityKey value); 
23     void IEntityWithChangeTracker.SetChangeTracker(IEntityChangeTracker changeTracker); 
24     protected InstanceCredentials GetInstanceCredentials(); 
25     [DebuggerNonUserCode] 
26     IPocoFacade IComposed<IPocoFacade>.GetImplementation(InstanceCredentials credentials); 
27     [DebuggerNonUserCode] 
28     INotifyPropertyChanged IComposed<INotifyPropertyChanged>.GetImplementation(InstanceCredentials credentials); 
29     [DebuggerNonUserCode] 
30     IFirePropertyChanged IProtectedInterface<IFirePropertyChanged>.GetInterface(InstanceCredentials credentials); 
31 
32     // Properties 
33     [EdmScalarProperty(IsNullable=true)] 
34     public string Firstname { [CompilerGenerated] get; [CompilerGenerated] set; } 
35     [EdmScalarProperty(IsNullable=false)] 
36     public string Lastname { [CompilerGenerated] get; [CompilerGenerated] set; } 
37     [EdmScalarProperty(IsNullable=false, EntityKeyProperty=true)] 
38     public int PersonID { [CompilerGenerated] get; [CompilerGenerated] set; } 
39 } 
40 
41 

Line 1 implements the needed EntityType attribute for EDM to work.
Line 2 shows that INotifyPropertyChanged and IPocoFacade is implemented. The facade interface just hides the 3 IPoco interfaces, so that's them! PostSharps adds IComposed interfaces as well.
Line 26 shows a call to the GetImplementation method of that interface. This way, a class I have added is returned where the actual work of the interface is done.
Line 33, 35 and 38 show the EDMScalarProperties being set.

What it does not do at this moment

I do not set default values for fields and I haven't spend any time on complex types and relations.

I first want to gauge community interest before spending more time on this project. So let me know if you would use this approach if it would be complete. I'm quite sure these things aren't too hard to accomplish, but they will take some time.

The Future

I'd like the EntityFramework Contrib project to provide easy tools to use EF in an enterprise system. I'm mostly interested in client/server SOA solutions. Other projects that might help in that aspect:

A custom changetracker that can be used on the client. This way the client will not have to reference Entity Framework at all.
Better serialization possibilities. Note that I do not automatically place datacontract attributes on top of the properties. I think it was a mistake for the ADO.Net team to implement their codegen to do this. (although I understand why).
When I serialize a EF entity at this moment, I see all kinds of references to EF in the xml. I do not like that, and would like a beautiful clean xml representation of my business objects. (I don't want to be forced to use DTO's.).
Serializing original values. I can see a representation of the value with a xml attribute that shows what the original value was.

Feel free to contact me, or leave a comment here or at the projects home to let me know if you are interested!

EF (Entity Framework) | EF-Contrib | OR-Mapping

Monday, February 18, 2008 2:50:21 PM (Romance Standard Time, UTC+01:00)

Comments [4] | Trackback

Workflow as controller: Introducing <M,V,C> where M: ViewModel, V : WPF, C : WF

In this post and a few upcoming posts, I would like to present a solution I have built using Workflow as the controller for your WPF applications. I wish I could call it a framework and think of a great name for it, but it does not aim to solve all your UI-building problems in one go. It does however offer a very easy way to build a loosely coupled application, driven by WF and could be used to build upon for your own solution.

This is the first of a series about using Workflow Foundation to control your UI Logic in a WPF application. The full table of contents:

Inspiration

Like I mentioned in a blog post here, Josh Smith writes about using MVC in a WPF application where he does not use a funky IOC-container to help him build a MVC architecture, but uses the WPF framework itself to accomplish most of it.
This resonated with me, because I just left a project where the combination of WPF and CAB did not make good on all it's promises. The team sometimes felt the combination was overly complex.

Also Jeremy Miller writes about implementing all of the different aspects of CAB yourself. While doing so, he reasons (my interpretation) that it's best to build the simplest solution that is a precise fit for your problem, instead of using all kinds of big-time frameworks that abstract away so much, that you start to feel constrained.

A great little post by Rob Teixeira concludes that most frameworks are way too complex to really use.

I have had a bit of experience using WF on the server side, but have always thought of WF to be an excellent fit for the UI as well. When building complex UI's I would like nothing better than to be able to invite a business analyst to sit next to me and just show him what will happen when a button is pushed.
I have had a team build a large UI for a LOB application. Although at first glance it looked very simple, there is always going on much more than you expect. Having a visual representation of the flow of actions in your program, is a good thing.

This project aims to provide the most straight forward easiest plumbing possible, to get the job done. It tries to be explicit and make it easy for you (the developer) to do the right thing. It hopes that the use of WF provides some sort of DSL-feel to your application.

So, what does this mean

First, what does the solution not do:

It is explicitly not an IOC based solution (but perhaps you don't need that)
It is not a complete eventing mechanism (although controllers are able to communicate just fine)
It is not a finished solution (I might have called it a framework then!)

What it is, is this:

It is a suggestion for how you could very easily use workflows as a controller
It combines some fun tricks I've learned, that will facilitate us here
It uses the native power of WPF, so no learning of new concepts just because you have a ShinyNewFramework, if you understand WPF, you understand how to hook things up
It uses the native power of WF to create your controller logic, this translates into a very descriptive usecase with easy handoff between developers and opens up possibilities of just letting your business analysts create the first draft themselves! WF always feels like a cheap-ass DSL to me.
It is one adapter class, a couple of activities and a command service. Very easy to understand and adjust to fit your own needs
It facilitates loose coupling to the extend where your views and your controllers do not need references to eachother
It is message based
Excellent testability, because of loose coupling and messages.

Show us the goods

I have uploaded the goods zipped here.
It needs .net framework 3.5.

In the previous post, I explained how you could combine the controller and wpf in one project. It seems that this does not work as well as it should: sometimes I get build errors that aren't there. It's fine to have logic and views separate for the real sample, but the shell consists of two projects now as well, that may seem as a bit overkill.

I only UnitTested one small view to show how you can go about testing bindings and test the controller separately. I use TypeMock for this, so you might need to unload that project. (I'm considering TypeMock, but it is pretty expensive for a one-man-shop).

What's in it

The real stuff is very small.

project ControllersAdapters, with only one file. It is a contentcontrol, which acts as an adapter to your controllers [8 kb dll]
project WorkflowCommunications, which has the service that we can use to translate in/out of the controller and 6 custom activities, that do specific things [27 kb dll]

That is all you need.
I have loosely implemented the BankTeller application from CAB, or rather the SmartClientContrib 1.1 WPF for CAB. I did not look too closely at their implementation details, just copied the xaml and the domain model and build a part of it myself. Just to discover what was needed to build a real application.

The sample consists of a Shell, Domain, Logic, Views and Test project. It demonstrates how one could go about building such an application. I will follow up with a more detailed look at it. Suffice it to say, implementing it was a breeze.

The thing with the BankTeller application is, that the logic is too simple. So it mostly demonstrates hooking up views and datacontexts.

Just to give you a quick glance at what logic in a workflow looks like:

(Here you see what will happen when a new customer is selected in the listview. It checks if the customer is not null, and then sets a customerinfo view and a customer summary view. If it was null, the views are removed from the visual tree.)

Go into more detail, please

Well, I will follow up with more posts, if there is an interest in it. This post has dragged on long enough, so I will keep it very short for now.

The concepts are:

Use WPF resources as an excellent container for objects. Resource lookups work hierarchically, so it's actually pretty powerful on it's own. There are two activities Inject- and RetrieveObjectFromResource that will put or retrieve an arbitrary object into the resource section of the adapter. This could be a service or something else.
Use WF as an event aggregator. All workflows are registered to the runtime, and all adapters subscribe (with weakevents) to the workflow. So it's easy to send messages around.
Use WPF Commands to communicate from the View to the Controller. Commands go upstream. I have made it easy for a controller to handle a command (just drag a HandleCommand to the screen). I've also made it possible to use rules to determine if the command 'CanExecute'. So you could do a command 'AcceptCustomer' and bind it to a button. The Controller will determine if the command can be executed. (When the customerqueue is empty in the sample, the button to accept a customer is disabled automatically).
Use WPF DataTemplates to inject UI by the Controller. The View can sprinkle ContentPresenters around (with ContentTemplates bound to DynamicResources). The controller will choose what piece of UI to inject as the resource. (cool stuff!)

The most important class is the GenericWorkflowAdapter that can be placed into the UI like this:

<c:GenericWorkflowAdapter WorkflowController="{x:Type l:ShellLogic}" />

Here we tell it to use the workflowcontroller: ShellLogic as it's 'boss'.
The adapter will hook into the RoutedUI commands coming from WPF and when a command comes that the workflow wants to react to, it will send it to the workflow. The workflow will react to it.

Than, there is the CommandService, which defines the communication between the workflow and the runtime. The adapters use it to send messages to their workflow. The workflow uses it to communicate to the adapters.

There are custom activities to do specific UI-things. Like setting a controller in the UI, or an object in the resources. Setting the datacontext of a view with your ViewModel and actually setting the Content of the adapter with it's View.

More details will follow.

Trixxxxxx

In order to pull this off, a few things were hacked:

I created a much easier way to register commands on a workflow. Just drag a HandleCommand to an Eventdriven activity, set it's CommandName (the string it will react to) and you're off. Normal WF paradigm says you have to create an interface and possibly even implement correlation. Not productive for what we are trying to achieve.
Getting the workflow to communicate back to the adapter causes a clone to be made of the message. But since we don't want that, I implement IClonable to return 'this'. Works well, but you have been warned.
At one point I use a delegate that is passed to the workflow, that let's it get data from the commandService on the fly.
In order to use the custom activities, I needed to let the user (you) select types (what view you wish to inject, what controller you want to instantiate). I've had to jump through hoops to get it working. See this blog post.

What is next

I've had great fun implementing this. After a few refactorings, it turned out to be extremely simple. I'm interested in seeing what you think. If there is some interest from the community, it could easily be taken to the next level. However, at this point it was just a nice experiment for me. Let me know what you think of the idea!!

WF (Workflow) | WPF (Avalon)

Monday, February 18, 2008 12:19:33 PM (Romance Standard Time, UTC+01:00)

Comments [0] | Trackback

Thursday, February 14, 2008

How to: use both workflow as wpf in one project (workaround)

Just ran into a little bug in Visual Studio/msbuild and could not find any answers in the forums, so I thought I'd put it up here for reference:

When you want to use both workflow classes and wpf classes in one project, you will run into some strange behaviour. Let's do it together.
If you want to skip the newbie stuff, jump to step 11 and see the bug.

create a WPF project.
unload the project and choose to edit the project file
somewhere in the beginning of the file, you will find the following line:
<ProjectTypeGuids>{60dc8134-eba5-43b8-bcc9-bb4bc16c2548};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
That is a way for visual studio to identify this as a WPF application project, and when you add an item, you will be able to choose a wpf item.
You wish to be able to compile WF items, so add to the bottom of the file the correct import for the WF tasks:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\Windows Workflow Foundation\v3.5\Workflow.Targets" />
Note that WPF in the past needed the import of winfx, but with framework 3.5 you don't need that anymore!
At this point you are able to copy a workflow or activity to your project and compile, but you want to be able to add WF items to your project, so scroll to the top of the file again.
Add the Guid that identifies a WF project ({14822709-B5A1-4724-98CA-57A101D1B079};) to your projecttypeguids tag. The complete tag should be on one line (!) and look like this:

<ProjectTypeGuids>{14822709-B5A1-4724-98CA-57A101D1B079};{60dc8134-eba5-43b8-bcc9-bb4bc16c2548};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
Save the file and reload the project.
Before adding a the first workflow to the project, first add references to System.Workflow.Runtime, Activities and Componentmodel.
Add your first glorious workflow to the project.
Be prepared to be disappointed: the project will not compile. Mine gave this error:

Error 1 Error reading resource file 'j:\Users\Ruurd\Documents\Visual Studio 2008\Projects\WF_and_WPF_combined\WpfApplication1\obj\Debug\WpfApplication1.obj.Debug.WpfApplication1.g.resources' -- 'The system cannot find the file specified. ' J:\Users\Ruurd\Documents\Visual Studio 2008\Projects\WF_and_WPF_combined\WpfApplication1
Notice the weird path of the resource file. It is looking for something with dots instead of path dividers. Strange.
In regular windows explorer, go to the obj/Debug folder, and create a copy of the .g.resources file and use that weird name. I wanted to automate it though, so go to the properties of your project and use this as your pre-build script:
IF EXIST "$(ProjectDir)obj\$(ConfigurationName)\$(TargetName).g.resources" (copy /-Y "$(ProjectDir)obj\$(ConfigurationName)\$(TargetName).g.resources" "$(ProjectDir)obj\$(ConfigurationName)\$(TargetName).obj.$(ConfigurationName).$(TargetName).g.resources") ELSE (echo "placeholder" > "$(ProjectDir)obj\$(ConfigurationName)\$(TargetName).obj.$(ConfigurationName).$(TargetName).g.resources")

This checks to see if you already have a g.resources file and if so, copies it. Otherwise it will generate a placeholder file with the correct name. Atleast the project will build without problems.

I have not tested it a lot yet. It seems to me that when the placeholder is created, there are resources that can not be found. During some quick and dirty tests, I've not had any problem yet and everything works just fine.

Hope this helps someone out there.

update: weird stuff. I have this running just fine in a couple of projects, but I have one project that gives an exception during a rebuild (not a build) in the compileworkflowtask. In other 'combined' projects, I can happily build and rebuild using the steps above.

This is probably caused by wpf renaming the file to tmp_proj and the compileworkflow task is validating it's parameters like so:

if ((string.Compare(this.ProjectExtension, ".csproj", StringComparison.OrdinalIgnoreCase) != 0) && (string.Compare</

Recap

The Compound aspect

PostSharp

Laos versus Core

Recap

Starting the application / Shell

The adapter

The Problem: baseclass needed

The suggested Solution: implement interfaces

EF-Contrib: Easing the implementation of these interfaces

Is this Persistence Ignorance?

How does it work?

The result

What it does not do at this moment

The Future

Table of contents

Inspiration

So, what does this mean

Show us the goods

What's in it

Go into more detail, please

Trixxxxxx

What is next