Friday, November 28, 2008

Auto-incrementing version numbers with Visual Studio

There are lots of web sites describing how to achieve this. Surprisingly most of them are "roll your own" solutions including custom add-ins, MSBuild-tasks or even custom tools.
But there is an obviously little-known feature in Visual Studio that allready provides this functionality. All you have to do is to edit the AssemblyInfo.cs file in project. Just replace the line [assembly: AssemblyVersion( "1.0.0.0" )]; with [assembly: AssemblyVersion( "1.0.*" )]; and remove the line [assembly: AssemblyFileVersion( "1.0.0.0" )];. You still have the possibility to manually set the major and minor version numbers (first two numbers). The build and the revision number (the last two) will be incremented automatically after each build. Thanks to Marc Charbonneau for telling the world ;) about this feature in his blog.
Edit: It seem like the auto-incrementing the assembly version has an annoying side-effect when applied to an assembly with custom ui controls or WF activities: https://connect.microsoft.com/VisualStudio/feedback/details/568672. The Visual Studio fails to release the handle to that dll during the build.

Sunday, October 26, 2008

Synchronizing Workflow Instances

In a multi threaded program, where different threads use a shared resource, the access to this shared resource needs to be synchronized. Most if not all programming languages or parallel programming systems provide some kind of synchronization mechanisms which help the programmer to protect shared resources and avoid race conditions. Unfortunately the Workflow Foundation (a system that is inherently multi threaded) does not provide a way to synchronize activities across workflow instances out of the box. Of course there is the SynchronizationScopeActivity, but it's only usefull when you need to synchronize parallel activities running in the same workflow instance.
One good reason for the absence of this kind of feature is the fact that if you have a shared resource then you usually access it through a runtime service. Synchronizing the access to the resource is the responsibility of the runtime service and not the responsibility of the workflow.
But nevertheless if you need to synchronize workflow activities across multiple instances or even different workflows you may find this usefull. It's an activity similar to the SynchronizationScopeActivity provided by WF except it synchronizes its child activities between different instances of a workflow.
To use this activity in you workflows you need to add an instance of a runtime service (CustomWorkflowActivities.SynchronizationService) provided with the activity to the workflow runtime first:
WorkflowRuntime workflowRuntime = new WorkflowRuntime();
workflowRuntime.AddService(
  new CustomWorkflowActivities.SynchronizationService(
    workflowRuntime));
Then just insert a RealSynchronizationScope activity into your workflow, set its SharingName property to some unique-within-the-workflow-engine string, and drag activities you wish to synchronize onto the RealSynchronizationScope activity. That's it! The workflow runtime will now serialize the execution of any activities inside your RealSynchronizationScope activity across workflow instances.

Saturday, September 13, 2008

Hello World

Hi there and welcome to my first blog. It seems to be common to start a new blog with a short opening post where the blogger tells the world who he are and what his blog is about. So I'm a software developer and this blog will be about my (main) hobbies: computer programming, music and maybe some other things which are worthwhile to mention. This should be enough for now but I promise, to make my future posts more substantial ;)