wf Wiki Rss Feed

New Comment on "Install Clean Project"

MikeHoney — Thu, 07 Feb 2013 23:27:38 GMT

On a Windows Server 2008 R2 machine this did not work. The installer completed but the VS External Tools entry was not added. On a hunch I reinstalled it starting from an Administrator Command Prompt. It then worked. Perhaps the installer could request Administrator elevation to avoid this?

New Comment on "HttpWorkflowServiceHost"

schleicherx — Fri, 23 Nov 2012 14:51:31 GMT

Please go ahead with this HttpWorkflowServiceHost it would be very great to have finally the possibility to invoke a WorkflowService via HTTP GET. This would really enhance WorkflowServices.

New Comment on "How do I install Microsoft.Activities?"

mtod — Tue, 20 Nov 2012 19:36:47 GMT

When will this be updated top support WF 4.5?

New Comment on "Install Clean Project"

BClayShannon — Wed, 14 Nov 2012 15:33:07 GMT

Thanks; you may not want to hear this (I know this is anathema to many coders) but I'm going to use this as a "poor man's backup utility"; create a zip of the pertinent files and store it on a usb stick; when I need to compare this file with that, I'll use WinMerge to do so.

New Comment on "WebApiWorkflow"

oatkins — Fri, 28 Sep 2012 01:41:25 GMT

Any news on when we might see this?

New Comment on "Microsoft.Activities.StateMachine"

YoYoRnd — Mon, 27 Aug 2012 10:26:02 GMT

Hi Ron, I would like to use WF for test automation. Is there any progress in the coded statemachine thread? Thank you. Roi

New Comment on "Which release should I install?"

Suncat2000 — Thu, 23 Aug 2012 16:53:24 GMT

Warning. If you compile against the 4.5 release in your project, and you don't have the .NET 4.5 Framework installed at runtime, your program will eventually fail with the following exception: System.TypeLoadException: Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. This is because .NET 4.5 makes subtle breaking changes to the framework. If you're going to run on a machine with .NET 4.0 - save yourself a couple days of frustration - DO NOT compile against version 4.5 of this (or any other) library. Ouch!

Updated Wiki: Documentation

ronjacobs — Thu, 19 Jul 2012 15:46:10 GMT

Microsoft.Activities.* Documentation

Clean Project Tool

Clean Project is a utility that cleans Visual Studio project directories so you can quickly upload or email a zip file with your solution.

Clean Project Overview

Microsoft.Activities.StateMachine Prototype Project

Microsoft.Activities.StateMachine

Learning WF

Beginner - Authoring XAML workflows and workflow services with Visual Studio
Intermediate - Authoring CodeActivity, Bookmarks and WorkflowApplication, UnitTesting
Advanced - Native Activities, Extensions, Designers

Versioning

How projects are versioned

WF Migration Kit Documentation

User Guide Samples and Tutorials are included in the release WF Migration Kit CTP 2

New Comment on "Tracking states with WorkflowApplication"

Norritt — Mon, 16 Jul 2012 11:35:45 GMT

How can I access variables declared in state machine (or workflow)& Thanx in advance.

Updated Wiki: What are some tips for unit testing with a database?

ronjacobs — Thu, 12 Jul 2012 17:29:57 GMT

What are some tips for testing with a SQL database?

Don't do it

You probably shouldn't use a SQL database when doing unit tests if you don't have to. We provide MemoryStore which is an in-memory instance store that works for most things.
However, there are cases where MemoryStore is not sufficient. For example, if you want to use LoadRunnableInstance, MemoryStore does not support this command. Or, you may want to test a PersistenceParticipant, PersistenceIOParticipant or Promoted Properties with SqlWorkflowInstanceStore.

Always start your test with a clean database.

This means you should create a new database prior to running each test. Yes this will make it slower but you need to start the test from a known state.

Drop the database after the test is over

You may want to keep the database if the test failed for some reason, but over time your build servers will likely fill up with unwanted databases.

Use a unique name for the database.

Your test may be running concurrently with other tests. Using a unique name ensures that the tests won't interfere with each other. Use a prefix for the name so you can tell what your test databases are and you can write a script to remove all test databases that start with the prefix.

In this script I drop all the databases that start with TestDatabase
Download Script

use master
go
declare @dbnames nvarchar(max) = ''
declare @statement nvarchar(max) = ''
select @dbnames = @dbnames + ',[' + name + ']' from sys.databases where name like 'TestDatabase%'
if @dbnames IS NULL
    begin
		RAISERROR (N'No database to drop', 1, 1) WITH NOWAIT
    end
else
    begin
		set @statement = 'drop database ' + substring(@dbnames, 2, len(@dbnames))
		print @statement
		exec sp_executesql @statement
    end

Do not use connection pooling

Connection pooling may result in connections hanging on to the database when you don't want them to.

Use SqlConnectionStringBuilder to control user supplied connection strings.

Remove things you don't want and add things you do want.

Updated Wiki: What are some tips for unit testing with a database?

ronjacobs — Thu, 12 Jul 2012 17:29:38 GMT

What are some tips for testing with a SQL database?

Don't do it

Always start your test with a clean database.

This means you should create a new database prior to running each test. Yes this will make it slower but you need to start the test from a known state.

Drop the database after the test is over

You may want to keep the database if the test failed for some reason, but over time your build servers will likely fill up with unwanted databases.

Use a unique name for the database.

use master
go
declare @dbnames nvarchar(max) = ''
declare @statement nvarchar(max) = ''
select @dbnames = @dbnames + ',[' + name + ']' from sys.databases where name like 'TestDatabase%'
if @dbnames IS NULL
    begin
		RAISERROR (N'No database to drop', 1, 1) WITH NOWAIT
    end
else
    begin
		set @statement = 'drop database ' + substring(@dbnames, 2, len(@dbnames))
		print @statement
		exec sp_executesql @statement
    end

Do not use connection pooling

Connection pooling may result in connections hanging on to the database when you don't want them to.

Use SqlConnectionStringBuilder to control user supplied connection strings.

Remove things you don't want and add things you do want.

Updated Wiki: What are some tips for unit testing with a database?

ronjacobs — Thu, 12 Jul 2012 17:27:14 GMT

What are some tips for testing with a SQL database?

Don't do it

Always start your test with a clean database.

This means you should create a new database prior to running each test. Yes this will make it slower but you need to start the test from a known state.

Drop the database after the test is over

You may want to keep the database if the test failed for some reason, but over time your build servers will likely fill up with unwanted databases.

Use a unique name for the database.

use master
go
declare @dbnames nvarchar(max) = ''
declare @statement nvarchar(max) = ''
select @dbnames = @dbnames + ',[' + name + ']' from sys.databases where name like 'TestDatabase%'
if @dbnames IS NULL
    begin
		RAISERROR (N'No database to drop', 1, 1) WITH NOWAIT
    end
else
    begin
		set @statement = 'drop database ' + substring(@dbnames, 2, len(@dbnames))
		print @statement
		exec sp_executesql @statement
    end

Do not use connection pooling

Connection pooling may result in connections hanging on to the database when you don't want them to.

Use SqlConnectionStringBuilder to control user supplied connection strings.

Remove things you don't want and add things you do want.

Updated Wiki: What are some tips for unit testing with a database?

ronjacobs — Thu, 12 Jul 2012 17:26:45 GMT

What are some tips for testing with a SQL database?

Don't do it

Always start your test with a clean database.

This means you should create a new database prior to running each test. Yes this will make it slower but you need to start the test from a known state.

Drop the database after the test is over

You may want to keep the database if the test failed for some reason, but over time your build servers will likely fill up with unwanted databases.

Use a unique name for the database.

use master
go
declare @dbnames nvarchar(max) = ''
declare @statement nvarchar(max) = ''
select @dbnames = @dbnames + ',[' + name + ']' from sys.databases where name like 'TestDatabase%'
if @dbnames IS NULL
    begin
		RAISERROR (N'No database to drop', 1, 1) WITH NOWAIT
    end
else
    begin
		set @statement = 'drop database ' + substring(@dbnames, 2, len(@dbnames))
		print @statement
		exec sp_executesql @statement
    end

Do not use connection pooling

Connection pooling may result in connections hanging on to the database when you don't want them to.

Use SqlConnectionStringBuilder to control user supplied connection strings.

Remove things you don't want and add things you do want.

Updated Wiki: What are some tips for unit testing with a database?

ronjacobs — Thu, 12 Jul 2012 17:26:24 GMT

What are some tips for testing with a SQL database?

Don't do it

Always start your test with a clean database.

This means you should create a new database prior to running each test. Yes this will make it slower but you need to start the test from a known state.

Drop the database after the test is over

You may want to keep the database if the test failed for some reason, but over time your build servers will likely fill up with unwanted databases.

Use a unique name for the database.

use master
go
declare @dbnames nvarchar(max) = ''
declare @statement nvarchar(max) = ''
select @dbnames = @dbnames + ',[' + name + ']' from sys.databases where name like 'TestDatabase%'
if @dbnames IS NULL
    begin
		RAISERROR (N'No database to drop', 1, 1) WITH NOWAIT
    end
else
    begin
		set @statement = 'drop database ' + substring(@dbnames, 2, len(@dbnames))
		print @statement
		exec sp_executesql @statement
    end

Do not use connection pooling

Connection pooling may result in connections hanging on to the database when you don't want them to.

Use SqlConnectionStringBuilder to control user supplied connection strings.

Remove things you don't want and add things you do want.

Updated Wiki: How do I test with WorkflowServiceTestHost?

ronjacobs — Sat, 30 Jun 2012 20:39:33 GMT

How do I test with WorkflowServiceTestHost?

Notes:

In this test you will be self hosting a WCF Service using named pipes
This test code requires Microsoft.Activities and Microsoft.Activities.UnitTesting >= v2.0.2
Download the sample code for this walkthrough from MSDN Code Gallery

Task 1 - Create the Workflow Service Library

Create a new Project using the Workflow / WCF Workflow Service Application project template named MathServiceLibrary
Open Service1.xamlx in the Workflow Designer
In the ReceiveRequest activity change the operation name to Increment
Drop an Assign activity below the ReceiveRequest and set the properties - we will intentionally cause a bug by adding 2 to the data

To	result
Value	data + 2

In the SendResponse activity open the message content and set it to data
Rename Service1.xamlx to IncrementService.xamlx
Set the WorkflowService properties

ConfigurationName	IncrementService
Name	IncrementService

Task 2 - Create the Test Project

Right click on the solution and select Add New Project...
Select Test / Test Project
Name the project MathServiceLibrary.Tests
Rename UnitTest1 (class and file) to IncrementServiceTest
Add a Service Reference to IncrementService.xamlx with the namespace IncrementService
Use NuGet to Install Microsoft.Activities.UnitTesting to MathServiceLibrary.Tests
Open Solution Items / Local.testsettings
In the Deployment tab select Enable Deployment
Click Apply and Close
Open IncrementServiceTest.cs and add the following namespace directives

using System.ServiceModel;
using Microsoft.Activities.UnitTesting;

Implement the unit test

/// <summary>
/// The increment service should increment data.
/// </summary>
/// <remarks>// You must deploy the XAMLX file to the test directory</remarks>
[TestMethod]
[DeploymentItem(@"%LABDIR%\Microsoft.Activities.UnitTesting\Examples\MathServiceLibrary\MathServiceLibrary\IncrementService.xamlx")]
public void IncrementServiceShouldIncrementData()
{
    // Arrange
    const int InitialData = 1;
    const int ExpectedData = 2;

    WorkflowServiceTestHost host = null;
    try
    {
        using (host = WorkflowServiceTestHost.Open("IncrementService.xamlx", ServiceAddress))
        {
            var proxy = new ServiceClient(Binding, ServiceAddress);
            int? value = InitialData;
            proxy.Increment(ref value);
            Assert.AreEqual(ExpectedData, value, "Increment did not correctly increment the value");
        }

        // The host must be closed before asserting tracking
        // Explicitly call host.Close or exit the using block to do this.

        // Assert that the Assign activity was executed with an argument named "Value" which contains the value 2
        host.Tracking.Assert.ExistsArgValue("Assign", ActivityInstanceState.Closed, "Value", 2);
    }
    finally
    {
        if (host != null)
        {
            host.Tracking.Trace();
        }
    }
}

Task 3 - Run the Test and Diagnose Failure

Run the test, it will fail

Assert.AreEqual failed. Expected:<2>. Actual:<3>. Increment did not correctly increment the value

Open the test results and look at the tracking data

Did the service receive the correct initial value?

Tracking record 11 shows the message that was received and the value 1 is in the message body

11: Activity [14.6] "InternalReceiveMessage" is Closed at 01:42:03.5879
{
    Arguments
        CorrelatesWith: 
        Message: <s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope">
  <s:Header>
    <a:Action s:mustUnderstand="1">http://tempuri.org/IService/Increment</a:Action>
    <a:MessageID>urn:uuid:bd4d84b7-0677-446e-885c-40e689088e8a</a:MessageID>
    <a:ReplyTo>
      <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
    </a:ReplyTo>
    <a:To s:mustUnderstand="1">net.pipe://localhost/IncrementService</a:To>
  </s:Header>
  <s:Body>
    <int xmlns="http://schemas.microsoft.com/2003/10/Serialization/">1</int>
  </s:Body>
</s:Envelope>
        noPersistHandle: System.Activities.NoPersistHandle
        Parameter0: System.ServiceModel.Activities.CorrelationHandle
}

Did the Assign activity assign the correct value?

Tracking record 18 shows that the assign activity received the value 3 from the expression which is incorrect.

18: Activity [9] "Assign" is Executing at 01:42:03.5879
{
    Arguments
        Value: 3
}

Task 4 - Correct the Workflow Service

Open IncrementService.xamlx and set the correct the expression on the assign activity data + 1
Run the test again, it will pass

Updated Wiki: What are some tips for unit testing with a database?

ronjacobs — Sat, 30 Jun 2012 17:24:10 GMT

What are some tips for testing with a SQL database?

Don't do it

Always start your test with a clean database.

This means you should create a new database prior to running each test. Yes this will make it slower but you need to start the test from a known state.

Drop the database after the test is over

You may want to keep the database if the test failed for some reason, but over time your build servers will likely fill up with unwanted databases.

Use a unique name for the database.

use master
go
declare @dbnames nvarchar(max)
declare @statement nvarchar(max)
select @dbnames = @dbnames + ',[' + name + ']' from sys.databases where name like 'TestInstanceStore%'
if len(@dbnames) = 1
    begin
		print 'no databases to drop'
    end
else
    begin
		set @statement = 'drop database ' + substring(@dbnames, 2, len(@dbnames))
		print @statement
		exec sp_executesql @statement
    end

Do not use connection pooling

Connection pooling may result in connections hanging on to the database when you don't want them to.

Use SqlConnectionStringBuilder to control user supplied connection strings.

Remove things you don't want and add things you do want.

Updated Wiki: What are some tips for unit testing with a database?

ronjacobs — Sat, 30 Jun 2012 17:23:50 GMT

What are some tips for testing with a SQL database?

Don't do it

Always start your test with a clean database.

This means you should create a new database prior to running each test. Yes this will make it slower but you need to start the test from a known state.

Drop the database after the test is over

You may want to keep the database if the test failed for some reason, but over time your build servers will likely fill up with unwanted databases.

Use a unique name for the database.

use master
go
declare @dbnames nvarchar(max)
declare @statement nvarchar(max)
select @dbnames = @dbnames + ',[' + name + ']' from sys.databases where name like 'TestInstanceStore%'
if len(@dbnames) = 1
    begin
		print 'no databases to drop'
    end
else
    begin
		set @statement = 'drop database ' + substring(@dbnames, 2, len(@dbnames))
		print @statement
		exec sp_executesql @statement
    end

Do not use connection pooling

Connection pooling may result in connections hanging on to the database when you don't want them to.

Use SqlConnectionStringBuilder to control user supplied connection strings.

Remove things you don't want and add things you do want.

Updated Wiki: What are some tips for unit testing with a database?

ronjacobs — Sat, 30 Jun 2012 17:23:35 GMT

What are some tips for testing with a SQL database?

Don't do it

Always start your test with a clean database.

This means you should create a new database prior to running each test. Yes this will make it slower but you need to start the test from a known state.

Drop the database after the test is over

You may want to keep the database if the test failed for some reason, but over time your build servers will likely fill up with unwanted databases.

Use a unique name for the database.

use master
go
declare @dbnames nvarchar(max)
declare @statement nvarchar(max)
select @dbnames = @dbnames + ',[' + name + ']' from sys.databases where name like 'TestInstanceStore%'
if len(@dbnames) = 1
    begin
		print 'no databases to drop'
    end
else
    begin
		set @statement = 'drop database ' + substring(@dbnames, 2, len(@dbnames))
		print @statement
		exec sp_executesql @statement
    end

Do not use connection pooling

Connection pooling may result in connections hanging on to the database when you don't want them to.

Use SqlConnectionStringBuilder to control user supplied connection strings.

Remove things you don't want and add things you do want.

Updated Wiki: What are some tips for unit testing with a database?

ronjacobs — Sat, 30 Jun 2012 17:22:47 GMT

What are some tips for testing with a SQL database?

Don't do it

Always start your test with a clean database.

This means you should create a new database prior to running each test. Yes this will make it slower but you need to start the test from a known state.

Drop the database after the test is over

You may want to keep the database if the test failed for some reason, but over time your build servers will likely fill up with unwanted databases.

Use a unique name for the database.

use master
go
declare @dbnames nvarchar(max)
declare @statement nvarchar(max)
select @dbnames = @dbnames + ',[' + name + ']' from sys.databases where name like 'TestInstanceStore%'
if len(@dbnames) = 1
    begin
		print 'no databases to drop'
    end
else
    begin
		set @statement = 'drop database ' + substring(@dbnames, 2, len(@dbnames))
		print @statement
		exec sp_executesql @statement
    end

Do not use connection pooling

Connection pooling may result in connections hanging on to the database when you don't want them to.

Use SqlConnectionStringBuilder to control user supplied connection strings.

Remove things you don't want and add things you do want.

Updated Wiki: What are some tips for unit testing with a database?

ronjacobs — Sat, 30 Jun 2012 17:21:44 GMT

What are some tips for testing with a SQL database?

Don't do it

Always start your test with a clean database.

This means you should create a new database prior to running each test. Yes this will make it slower but you need to start the test from a known state.

Drop the database after the test is over

You may want to keep the database if the test failed for some reason, but over time your build servers will likely fill up with unwanted databases.

Use a unique name for the database.

use master
go
declare @dbnames nvarchar(max)
declare @statement nvarchar(max)
select @dbnames = @dbnames + ',[' + name + ']' from sys.databases where name like 'TestInstanceStore%'
if len(@dbnames) = 1
    begin
		print 'no databases to drop'
    end
else
    begin
		set @statement = 'drop database ' + substring(@dbnames, 2, len(@dbnames))
		print @statement
		exec sp_executesql @statement
    end

Do not use connection pooling

Connection pooling may result in connections hanging on to the database when you don't want them to.

Use SqlConnectionStringBuilder to control user supplied connection strings.

Remove things you don't want and add things you do want.