One common complaint about BizTalk Server is that it’s not particular lightweight (many moving parts) and isn’t easy for an expert .NET developer to pick up immediately. I suspect this is one reason why we’ve seen multiple other .NET service buses (e.g. nServiceBus) pop up as viable alternatives. So, when it was announced that WCF […]
I hope you’ve all been well over the break and enjoying the ’thinking time’ – I’ve
been keeping one ear to the ground and just on the lookout for new bits. Here’s one.
The BizTalk team have been busily working hard over the break and produced another
issue of BizTalk at it’s best – BizTalk Hotrod.
http://biztalkhotrod.com/Documents/BizTalkHotrod11_Q4_2010.pdf
Specifically this issues talks about:
Guys – the biztalk hotrod mag set is some of the best technical biztalk discussions
around, grab the previous issues and add them to your internal networks. A must.
Enjoy and talk to you soon.
Mick.
In my last post I showed you how the _XamlStaticHelper class uses different semantics when loading assemblies referenced by XAML files.
Today I’m going to show you a solution I’ve built into the Microsoft.Activities library that can help you apply standard CLR behavior when loading referenced assemblies.
Download the latest version
In my example project, I have a compiled workflow named WorkflowCompiled.xaml. I have added a partial class with the same name and .cs extension
Add the FullName of any assemblies that you are referencing from your XAML
/// <summary> /// Gets the referenced assemblies. /// </summary> /// <remarks> /// The XamlAppDef build task generates a list of referenced assemblies automatically in the (XamlName).g.cs file /// You can find the list of assemblies and version that need to be referenced there. /// This property returns a simple string list of the assemblies that will cause them to be loaded using the /// standard Assembly.Load method /// </remarks> public static IList<string> ReferencedAssemblies { get { // Create a list of activities you want to reference here var list = new List<string> { "ActivityLibrary1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c18b97d2d48a43ab", }; // Add the standard list of references list.AddRange(StrictXamlHelper.StandardReferencedAssemblies); return list; } }
The default constructor in your partial class will use the loose assembly loading behavior. You must supply an alternate constructor to get the strict behavior
/// <summary> /// Initializes a new instance of the <see cref="WorkflowCompiled"/> class. /// </summary> /// <param name="assemblyResolutionOption"> /// The assembly Resolution Option. /// </param> public WorkflowCompiled(XamlAssemblyResolutionOption assemblyResolutionOption) { switch (assemblyResolutionOption) { case XamlAssemblyResolutionOption.Loose: this.InitializeComponent(); break; case XamlAssemblyResolutionOption.Strict: StrictXamlHelper.InitializeComponent(this, this.FindResource(), ReferencedAssemblies); break; default: throw new ArgumentOutOfRangeException("assemblyResolutionOption"); } }
WorkflowInvoker.Invoke(new WorkflowCompiled(XamlAssemblyResolutionOption.Strict));
Your compiled workflow will now behave like any other CLR object and construct successfully if and only if it can resolve the specific version of all referenced assemblies. If it cannot locate the assembly file it will throw a FileNotFoundException and if it can locate the file but it is not the correct version or public key token it will throw a FileLoadException.
Loose XAML is an activity loaded from a XAML file using ActivityXamlServices.Load(). Unless the XAML file has FullName references (which it does not by default) ActivityXamlServices.Load will load with a partial name. This means it could load any assembly it finds with a matching name without regard to the version or public key token.
There are two ways to fix this.
Download the latest version
public static IList<string> GetWorkflowLooseReferencedAssemblies() { // Create a list of activities you want to reference here var list = new List<string> { "ActivityLibrary1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c18b97d2d48a43ab", }; // Add the standard list of references list.AddRange(StrictXamlHelper.StandardReferencedAssemblies); return list; }
// This will ensure the correct assemblies are loaded prior to loading loose XAML var activity = StrictXamlHelper.ActivityLoad( "WorkflowLoose.xaml", GetWorkflowLooseReferencedAssemblies()); WorkflowInvoker.Invoke(activity);
Loading the correct version of a referenced assembly is vital. The default behavior of both compiled workflows and loading loose XAML may result in unexpected behavior due to loading a newer version of the referenced assembly.
I recommend that you use StrictXamlHelper to ensure that you load the expected version of referenced assemblies.
A spike is a short project where you investigate how something works and report back to the team with your results.
For this spike I want to answer the following questions
I will run through a number of scenarios with various options. For each scenario the format is Activity (version), Host (version), Deploy (option), XAML option (which one runs first)
| Application Base | Deploy the activity assembly to the same directory as the workflow application |
| GAC | Deploy the activity assembly in the GAC |
| Compiled XAML | A .XAML file that has a XamlAppDef build task in Visual Studio and is deployed in the assembly – this is the default setting for XAML |
| Loose XAML | .XAML file that is deployed as a file and loaded by ActivityXamlServices.Load |
| Host | XamlAssemblyResolution.exe | Workflow Console Application with WorkflowCompiled.xaml and WorkflowLoose.xaml |
| Activity | AcvitityLibrary1.dll | Contains a custom activity named GetTypeInfo |
Expected: Both Compiled and Loose should use V1
Expected: Both Compiled and Loose should use V1 from the GAC even though the Activity DLL is in the Application Base
Actual: The activity was loaded from the GAC. For more info see How the Runtime Locates Assemblies.
Expected: Activity V1 from the GAC will be used for both loose and compiled
Actual: Not Expected! When you run the Loose XAML first, it will load V2 from the file and the Compiled XAML will load V1.
Why does Loose XAML load a different activity version when run before compiled XAML?
Expected: Activity V1 from the GAC will be used for both loose and compiled
Actual: Behaves as expected
Expected: Activity V1 from the GAC will be used for both loose and compiled because the host was built for V1
Actual: Not Expected! When you run the Loose XAML first, it will load V2 from the GAC and the Compiled XAML will load V1.
Why does Loose XAML load a different activity version when run before compiled XAML?
Expected: Activity V1 from the GAC will be used for both loose and compiled because the host was built for V1
Actual: Behaves as expected
Expected: Compiled and Loose will fail because V1 is not available
Actual: Not Expected! Both Compiled and Loose loaded V2 from the GAC even though they were not built for V2 of the activity
Why do both Compiled and Loose XAML load versions of the activity than what they were built with?
Expected: Compiled and Loose will fail because V1 is not available
Actual: Not Expected! Both Compiled and Loose loaded V2 from the application base
Why do both Compiled and Loose XAML load versions of the activity than what they were built with?
Expected: Compiled and Loose will fail because V2 is not available
Actual: Not Expected! Both Compiled and Loose loaded V1 from the application base
Why do both Compiled and Loose XAML load versions of the activity than what they were built with?
Expected: Compiled and Loose will fail because V2 is not available
Actual: Not Expected! Both Compiled and Loose loaded V1 from the GAC
Why do both Compiled and Loose XAML load versions of the activity than what they were built with?
Expected: Workflow will run V2 from GAC
Actual: Compiled and Loose loaded V2 from the GAC as expected when Compiled ran first
Expected: Workflow will run V2 from GAC
Actual: Not Expected! Loose loaded V1 from Application Base and Compiled loaded V2 from the GAC
Why do both Compiled and Loose XAML load versions of the activity than what they were built with?
A: Because the generated class _XamlStaticHelper specifically tried to load the version that was referenced at compile time.
When you look at the activity assembly reference in XAML you will see that it does not include the version or public key token
xmlns:a="clr-namespace:ActivityLibrary1;assembly=ActivityLibrary1"
How does the version get referenced in compiled XAML?
The XamlAppDef build task will generate a file that creates a class which represents the compiled workflow. My workflow is WorkflowCompiled.xaml so the generated file (located under obj\x86) is WorkflowCompiled.g.cs. Contained in that file is a line of code that reveals where the XAML comes from
System.IO.Stream initializeXaml = typeof(WorkflowCompiled).Assembly.GetManifestResourceStream(resourceName);
When this class reads the XAML it uses a XamlSchemaContext to help it interpret the XAML and it gets the context from a generated class called _XamlStaticHelper. Here is the line of code.
System.Xaml.XamlSchemaContext schemaContext = XamlStaticHelperNamespace._XamlStaticHelper.SchemaContext;
So what? Well if we open the host assembly with Reflector and look at the _XamlStaticHelper.SchemaContext property we can see what is going on
if (AssemblyList.Count > 0)
{
target = new XamlSchemaContext(AssemblyList);
}
There is an AssemblyList property! And what does it contain? We see from the LoadAssemblies method that the XamlAppDef build task has generated a fully qualified reference to ActivityLibrary1 (version 1)
private static IList LoadAssemblies()
{
IList list = new List();
list.Add(Load("ActivityLibrary1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c18b97d2d48a43ab"));
// (a bunch of other assemblies here)
list.Add(Assembly.GetExecutingAssembly());
return list;
}
Because this code is generated at build time, the Compiled XAML will first try to load the specific version of the activity it was created with.
In spite of the fact that the compiled host assembly specifies a version of the activity library should be loaded; our testing shows that a compiled will load older or newer versions of the activity if the specific version is not available, and loose XAML will load any assembly with a matching name (even one that does not have a strong name).
The _XamlStaticHelper.Load() method is the reason why this happens
private static Assembly Load(string assemblyNameVal)
{
AssemblyName name = new AssemblyName(assemblyNameVal);
byte[] publicKeyToken = name.GetPublicKeyToken();
try
{
return Assembly.Load(name.FullName);
}
catch (Exception)
{
AssemblyName assemblyRef = new AssemblyName(name.Name);
if (publicKeyToken != null)
{
assemblyRef.SetPublicKeyToken(publicKeyToken);
}
return Assembly.Load(assemblyRef);
}
}
It first tries to load the assembly using the full name and if that fails it catches the exception and tries to load it with the name and public key token but no version. This is different than the typical CLR behavior which requires a specific version match.
To wrap this up I have to say be careful. WF4 workflows do not follow the same rules for assembly versioning that you might expect.
This article focuses on one aspect of the recommendations I made for a client, which saw its way into the final Design Recommendations document I left with them at the end: how the use or misuse of color affects user interfaces.
As many may already know, Scrum is an approach to software development that, rather than being a full process or methodology, is a framework that utilizes the Agile scheme to develop software. Instead of providing a complete, detailed description of how everything is to be done in a project from the beginning, much is left […]
In the healthcare business today, a problem exists in integrating various information systems. The issue can be partially attributed to the fact that these systems onlyserve one specific department within a healthcare business. Having such an issue can lead to inefficient patient care. For example, if patient’s health information is spread out over a […]
The WorkflowApplication is a great way to execute your workflows in process. Usually the fact that the WorkflowApplication is asynchronous is a great thing but there are cases when a little more synchronous execution is nice. For example executing a workflow and updating the state of the user interface is much simpler when the WorkflowApplication.Run() doesn’t finish until all work is done.
The key to creating a synchronous WorkflowApplication is using its SynchronizationContext. Normally you set this to SynchronizationContext.Current so everything executes on the current UI thread. However this is still an asynchronous call and the Run doesn’t block.
Take this very simple workflow and its execution output.
var workflow = new Sequence()
{
Activities = {
new WriteLine(){ Text="Workflow is running"}
}
};
var app = new WorkflowApplication(workflow);
Console.WriteLine("Before WorkflowApplication.Run()");
app.Run();
Console.WriteLine("After WorkflowApplication.Run()");
As you can see the Run() didn’t block and the message after the Run() was printed before the message from the workflow.
Executing the workflow synchronously
Making this workflow execute in a synchronous fashion is easy and requires only a very small change by setting the SynchronizationContext to a custom implementation.
var workflow = new Sequence()
{
Activities = {
new WriteLine(){ Text="Workflow is running"}
}
};
var app = new WorkflowApplication(workflow);
app.SynchronizationContext = new SynchronousSynchronizationContext();
Console.WriteLine("Before WorkflowApplication.Run()");
app.Run();
Console.WriteLine("After WorkflowApplication.Run()");
The SynchronousSynchronizationContext used is real simple. The workflow internals always call the Post() method to execute work, so all we need to do is just execute the delegate passed with the state passed.
class SynchronousSynchronizationContext : SynchronizationContext
{
public override void Post(SendOrPostCallback d, object state)
{
d(state);
}
}
Executing an asynchronous workflow
Using this same SynchronousSynchronizationContext with an asynchronous workflow works just fine. If I add the following simple bookmarked activity to the workflow and execute it I get the following result:
The code to execute the workflow is as follows
var workflow = new Sequence()
{
Activities = {
new WriteLine(){ Text="Workflow has started"},
new MyBookmarkedActivity(),
new WriteLine(){ Text="Workflow is done"}
}
};
var app = new WorkflowApplication(workflow);
app.SynchronizationContext = new SynchronousSynchronizationContext();
app.Idle = e => Console.WriteLine("WorkflowApplication.Idle called");
Console.WriteLine("Before WorkflowApplication.Run()");
app.Run();
Console.WriteLine("After WorkflowApplication.Run()");
Console.WriteLine();
Console.WriteLine("Before WorkflowApplication.ResumeBookmark()");
Console.WriteLine("ResumeBookmark: {0}", app.ResumeBookmark("MyBookmark", null));
Console.WriteLine("After WorkflowApplication.ResumeBookmark()");
And the bookmarked activity is as follows:
class MyBookmarkedActivity : NativeActivity
{
protected override bool CanInduceIdle
{
get { return true; }
}
protected override void Execute(NativeActivityContext context)
{
Console.WriteLine("Creating bookmark");
context.CreateBookmark("MyBookmark", BookmarkResumed);
}
private void BookmarkResumed(NativeActivityContext context, Bookmark bookmark, object value)
{
Console.WriteLine("Bookmark resumed");
}
}
Conclusion
A simple yet effective addition to the workflow runtime for that special case where the asynchronous behavior is not quite what you want but the WorkflowInvoker is not flexible enough
Enjoy!
www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu
If you have not yet registered for CloudCamp LA next week, sorry, but it’s sold out.
I’ll be there doing a lightening talk. I’m trying something new, File|New|PowerPoint, and pretty radical and hip given it is, after all, Los Angeles. I’m pushing my creative limits to come up with a compelling yet non-commercial rapid-fire presentation. This could go either way, but I’m pretty sure you’ll be entertained!
Registration for the San Diego CloudCamp is open, at http://cloudcamp.org/sandiego/2011-02-09. It will be Feb 9, and I’ll be posting more details as the time gets closer. I’ll be doing a lightening talk there as well.
San Diego will also likely sell out, so don’t procrastinate, sign up NOW to ensure your spot.
