-
xxx Approval and Approval Status in list
After a list is enabled "Content Approval", the list has approval status field shows up in the default view. This is system field just like modified, modified by. It has nothing to do with workflow.
-
WCF transport-level session
All bindings support configuring the contract on the endpoint with SessionMode.Allowed. The SessionMode property does not refer to the instancing mode, but rather to the presence of a transport-level session (or its emulation in the case of the WS bindings). As its name implies, when the SessionMode property is configured with SessionMode.Allowed, it merely allows transport sessions, but does not enforce it. The exact resulting behavior is a product of the service configuration and the binding used. If the service is configured for per-call, it still behaves as per-call service. When the service is configured for a per-session service, it will behave as a per-session service only if the binding used maintains a transport-level session. For example, the BasicHttpBinding can never have a transport-level session due to the connectionless nature of the HTTP protocol. The WSHttpBinding without security and without reliable messaging will also not maintain a transport-level session. In both of these cases, even though the service is configured with InstanceContextMode.PerSession and the contract with SessionMode.Allowed, the service will behave as a per-call service, and the calls to Dispose() are asynchronous; that is, the client is not blocked after the call while WCF disposes of the instance.
-
WF Dependency Property snippet is just three letters!
-
ManualWorkflowSchedulerService
By default, workflow runtime use DefaultWorkflowSchedulerService as scheduler, what this means is that the workflow instance run in a separate thread. So if you want to wait for the workflow to finished, you need AutoResetEvent object to synchronize the thread. But in asp.net you make want to use a single thread. Here is an article Using Workflows with ASP.NET.
-
WF runtime engine
The workflow runtime is just a class, you create a instance of the class in your application, make it a static or global, so the instance live through all the live of your application, in this case, your application is hosting the workflow runtime. In fact your application can create more than one runtime. However, you typically won't need to do that. A single instance of the workflow runtime is capable of managing the execution of multiple workflow instances. One possible reason to create multiple runtime instances in a single appDomain would be if each instance required a different set of conflicting runtime services or configuration settings. You can also extend the WorkflowRuntme class to initialize the runtime engine.