In Visual Studio Debugger for Windows Workflow Foundation you MUST set the workflow DLL project as the Visual Studio solution startup project to debug the workflow using F5
Documented in http://msdn.microsoft.com/en-us/library/bb483186.aspx
It is not intuitive restriction.
I’ve posted to MS Feedback that it will be good to support workflow Debugging from any startup project.
Recently I’ve noticed, that if workflow DLL project is a startup project, it doesn’t support Edit&Continue in a code dlls. Another thing that MS should improve. It’s similar to ASP.Net Web Site limitation of Edit&Continue.
I also not able to open activity from call-stack- see my post Windows Workflow: Concatenate all parents QualifiedNames- instead of call stack
When ASP.NET page converted to WAP, it changed autoeventwireup to True- see autoeventwireup Changed to True in C# Conversion to WAP discussion.
Autoeventwireup is easier for coding, but there are disadvantages(according to MSDN):
One disadvantage of the AutoEventWireup attribute is that it requires that the page event handlers have specific, predictable names. This limits your flexibility in how you name event handlers. Another disadvantage is that performance is adversely affected, because ASP.NET searches for methods at run-time. For a Web site with high traffic volumes, the impact on performance could be significant.
After conversion you should check the code for consistency:
If autoeventwireup=”true”, ensure that event wiring from the code behind pages has been removed as well.
If you include explicit binding for page events, be sure that the AutoEventWireup property is set to false so that the method is not called twice.
MSDN recommends that you always set AutoEventWireup to FALSE while working in Visual Studio .NET (from article it is not obvious, is recommendation applicable for VS 2008).
More explanations why AutoEventWireup should be set to false:
K Scott Allen’s “Inside AutoEventWireup” blog and http://hocke.blogspot.com/2007/07/autoeventwireuptrue.html
However ScottGu comment in http://aspnetresources.com/blog/wap_resets_autoeventwireup.aspx :
From a performance measurement perspective, there is no difference between autoeventwireup=true/false.
ConditionedActivityGroup is a kind do of loop
, but it should not be used instead of the WhileActivity.
There are a few reasons for this:
1.Use the simplest tool that satisfy your requirement
2.workflow designer doesn’t expand body of ConditionedActivityGroup, and you need to click it to Preview
3. If you have many activities in the workflow, the designer becomes terribly slow(VS 2008)
The huge workflows should be considered for refactoring by converting parts of workflow into custom composite activity or as separate worklow (with InvokeWorkflow activity)
I have a question, should I use Code Conditions vs Rule Conditions?
- Rule conditions are included in the declarative model and can be dynamically updated at run-time
- The .rules file provides code separation and enables external analysis /tools to be built on top of the .rules file.
Also to set the conditions declaravely via Rules simpler for new Activity.
However if you are using code-behind for the workflow, specify code conditions is more consistent and easy to maintain/investigate.
Editing declarative conditions in Workflow Designer is too slow.
Also VS “find references” could NOT see the references from rule conditions, which make development harder.
I want to do .Net Remoting asyncronous call with “fire and forget” approach.
MSDN statement in OneWayAttribute Class documentation is not clear “The method can execute synchronously or asynchronously with respect to the caller.”
Thanks to manish godse’s blog : OneWay messages in remoting
post: invoking a method with [OneWay] attribute the client will not wait for a response and the call will return immediately. In essence the call gets converted to an async call and the client doesnt wait for a server response. The async behaviour for [OneWay] messages is true, when you are invoking a method on a remoting proxy. Invoking the same method on a regular object will be called synchronously like any other method.
Similar explanation is in Using OneWayAttribute for Remote Calls
In a summury, to call a Remoting method asyncronously to “fire and forget”, you need to mark a method on your remote INTERFACE with OneWayAttribute.