If you've attempted to host the workflow designer in .net <= 3.5 you'll remember it's not such an easy achievement.

However doing so in wpf .net 4.0 is quite trivial.

Have a look at the Visual Studio 2010 .NET 4 training kit and you'll see for your self.

Here's my first appempt this evening that took all of 10 minutes.

 Make sure to download the training kit even if you are an experienced developer, it's got some gems in it.

Here's an easy one to get caught out on.

Say you remove a constraint on a table to do some maintainance ect.

e.g.

ALTER TABLE BANDWIDTH NOCHECK CONSTRAINT FKUserLimits;

When you wish to bring the constraint back on stream you may be surprised to find the following does not quite work...

ALTER TABLE BANDWIDTH CHECK CONSTRAINT FKUserLimits;

You may be be able to see this in the execution plan on SSMS if the constraint was used in query optimization.

but you can check for sure by executing the following

select name, is_not_trusted FROM sys.foreign_keys where name = 'FKUserLimits';

you'll find that is_not_trusted is 1, indicating that the constraint is not trusted, this is because someone could have modified the table while the constaint was turned off, the sql to reenable the constraint needs to be told to check it while doing so..

here's how

ALTER TABLE BANDWIDTH
WITH CHECK
CHECK CONSTRAINT FKUserLimits;

This option tells SQL server to verify that all rows in the table comply with the constraint prior to turning it back on. If any rows do not comply with the constraint, an error message is returned and the alter table statement is rolled back.

If you wish to test specific writelines on a console application: you can do so by adding a StringWriter object to the workflow extensions.
The writeline activity will use the textwriter if it exists as opposed to the console.

[TestMethod]
public void CheckWorkflowWriteLine()
{   
 var wi = new WorkflowInvoker(new HelloWorld());

        //Add string writer to extensions  
 var writer = new StringWriter();    
 wi.Extensions.Add(writer);    
 wi.Invoke();    
 Assert.AreEqual("Hello Workflow", writer.ToString());
}

Hi all.

I've discovered this is not as simple as it would appear to be.
Infact it's worse; in "order" to do this you will need to jump through a few hoops...; in a particular order!

1. Add an activity library project
2. Add a reference to this new project from your WF4 app (any app with workflows.. silverlight/mvc etc)
    ENSURE: this is done before step 3 or visual studio 2010 will give you a circular reference error!
3. In the activity library add the service reference to your webservice
4. Modify your webconfig file to contain the abc information for the connection (servicemodel stuff)
5. Now use the activities (from the toolbox)

I gather from crawling through google that the above sequence is already well defined as a workaround for the vs2010 bug.

We've all created API libraries, and libraries by their nature encourage resuse.
However what happens if you want to be selective in who else uses your assembly?
One simplistic approach would be to ensure that the calling assembly has the same public key


private void CheckCallerAllowed()
{
var myPubKeyToken = Assembly.GetExecutingAssembly().GetName().GetPublicKeyToken();
var entryPubKeyToken = Assembly.GetEntryAssembly().GetName().GetPublicKeyToken();

if (myPubKeyToken.Length != entryPubKeyToken.Length)
    throw new ApplicationException("Assembly not licensed");

for (int idx = 0; idx < myPubKeyToken.Count(); ++idx)
    if (myPubKeyToken[idx] != entryPubKeyToken[idx])
        throw new ApplicationException("Assembly not licensed");
}

Place a call to the function above in your public interface.