Transactional Workflows: Suspend-Enqueue-Unload-Resume Done Correctly on Second-Phase Commit

May 21, 2010

More than two years ago I visited the subject of transactionally delivering a message to a workflow, making sure that the transaction did not commit until the message has been delivered and the workflow persisted under the same transaction. This subject has also been covered fairly well in this MSDN Forums thread. As a quick reminder, if you want to transactionally deliver a message to a workflow, you need to follow these steps: Suspend the workflow instance Enqueue the message to the workflow’s queue Unload the...
no comments

Transaction Flows Across Reentrant AppDomain Calls

A few of weeks ago I blogged about flowing a transaction across AppDomain boundaries. Apparently, there’s a little gotcha that you need to be aware of: Even if you don’t flow the transaction to the other AppDomain, and the thread in the other AppDomain executes a method that calls back into the original AppDomain, the transaction will flow across the reentrant call. In other words, if you have two objects, A and B, where A lives in one AppDomain and B lives in another AppDomain, then the following can happen: A calls a method of B within a...
no comments

Using NetModules for Reducing Compilation Costs

May 8, 2010

A relatively obscure feature of .NET deployment is the concept of a netmodule. An assembly can contain multiple netmodules, which can be compiled separately and relinked into the assembly without recompiling other netmodules that constitute the assembly. Effectively, netmodules form a linkage boundary for managed assemblies. The Web is full of old samples from the pre-Whidbey era that show how to use netmodules, and I got an email with a question on the subject a couple of days ago, so here’s a trivial example that shows how you can use netmodules to reduce compilation costs. First of all,...
one comment

Assembly Private Bin Path Pitfall

May 6, 2010

When you configure a .NET AppDomain, one of the things you can set is the private probing path (relative to that AppDomain’s base directory) that will be used by the CLR loader when trying to load an assembly in that AppDomain. With that in mind, the following code is allegedly supposed to work, provided that the SecondAssembly assembly is indeed located in the PrivatePath subdirectory: class InOtherAppDomain : MarshalByRefObject { public void SomeMethod() { AppDomain thisAD...
one comment