/// <summary>

        /// ScriptManager1 control.

        /// </summary>

        /// <remarks>

        /// Auto-generated field.

        /// To modify move field declaration from designer file to code-behind file.

        /// </remarks>

        protected global::System.Web.UI.WebControls.ScriptManager ScriptManager1;

        /// <summary>

        /// UpdatePanel1 control.

        /// </summary>

        /// <remarks>

        /// Auto-generated field.

        /// To modify move field declaration from designer file to code-behind file.

        /// </remarks>

        protected global::System.Web.UI.WebControls.UpdatePanel UpdatePanel1;

But I have to change it to :

/// <summary>

        /// ScriptManager1 control.

        /// </summary>

        /// <remarks>

        /// Auto-generated field.

        /// To modify move field declaration from designer file to code-behind file.

        /// </remarks>

        protected global::System.Web.UI.ScriptManager ScriptManager1;

        /// <summary>

        /// UpdatePanel1 control.

        /// </summary>

        /// <remarks>

        /// Auto-generated field.

        /// To modify move field declaration from designer file to code-behind file.

        /// </remarks>

        protected global::System.Web.UI.UpdatePanel UpdatePanel1;

Fix:

1) Either reset the System.Web.UI.WebControls.WebParts.UpdatePanel back to System.Web.UI.UpdatePanel (same for ScriptManager) every time the ascx file is modified...[recommended] but tedious

2) I found that using a Register command at the top of the ASCX file seemed to properly override the default behavior of the designer to pick the 4.0 location for the 3.5 control (I think that is the underlying issue, it is a 4.0 designer backwards compatible with 3.5). [Recommended] but be careful while adding controls with <asp: 

<%@ Register TagPrefix="asp" Namespace="System.Web.UI" Assembly="System.Web"%>

...

 <asp:ScriptManager runat="server" ID="smLocationsMap" />

3) You can include system.web.dll, and system.web.design. dll in your bin folder (Security/ Other issues) [Not recommended]

I hope this is helpful :)

 There are several ways to do that. I like the way using cancellation token the most.

 Here we are calling GetResult() method which might take longer than 5000ms.Code snippet:

 int QueryTimeOut = 5000; //in ms
 var tokenSource = new CancellationTokenSource();
 CancellationToken token = tokenSource.Token;
 var task = Task.Factory.StartNew(() => queryRun.GetResult(), token);
 timedOut = false;
 
 if (!task.Wait(QueryTimeOut, token))
 {
 timedOut = true;
 message = String.Format(" Method Timed out");
 tokenSource.Cancel();
 return -1;
 }
 Int32 result = Convert.ToInt32(task.Result);
 task.Dispose();
 return result;
 

NOTE: Above code does not kill the GetResult() which still runs in background. To Abort processing of GetResult/ long running method, please see below snippet:

 using System;
 using System.Threading;
 using System.Collections.Generic;
 using System.IO;
 using System.Threading.Tasks;
 
 namespace n
 {
 public class MonitorSample
 {
 
 private static int GetResult()
 {
 int result = 0;
 while (++result < 500)
 {
 Console.WriteLine(result);
 Thread.Sleep(5);
 }
 return result;
 }
 public static void Main(String[] args)
 {
 int QueryTimeOut = 50; //in ms
 int result = 0;
 Boolean timeOut = false;
 ManualResetEvent wait = new ManualResetEvent(false);
 Thread work = new Thread(new ThreadStart(() =>
 {
 //some long running method requiring synchronization
 result = GetResult();
 wait.Set();
 }));
 work.Start();
 Boolean signal = wait.WaitOne(QueryTimeOut);
 if (!signal) {
 work.Abort();
 timeOut = true; 
 }
 Console.WriteLine(String.Format("Result = {0}, timedout = {1}", result, timeOut));
 Console.ReadKey();
 }
 }
 }
 

Think of any online task you do in your day to day life, it should have a workflow backing up. e.g. you buy movie tickets online (Its a client side workflow, you go to ticketing site -> chose tickets -> confirm -> pay).  Other workflow is server-side workflow which is a background task. E.g. when you buy a product on Amazon. Steps, Chose a product -> pay -> A server side workflow should kick off which contacts actual seller, calculates estimated delivery time, add order details in your account, send confirmation email to buyer and other individual tasks.

Today I want to write about Windows workflow foundation 4.0 (WF). There are other workflow frameworks like Oracle offers, Sharepoint workflow etc.

But I personally liked this workflow framework. WF a framework used to perform work intensive sequence of tasks (known as activities). Always remember, workflows are used to "Just Do Work".
E.g. do X -> Check Y-> See P -> Send A and for 1 million users. Your workflow in workflow designer might look like:

I have been working on WF since couple of months and I am amazed with the power of this framework. With this you can:-
1. Run independent tasks/Activities in parallel
2. If you have created a share point farm your workflow can run on multiple machines in parallel.
3. It can be triggered by a workflow or a timer job
4. Create custom activities to implement business logic.
5. Set up concurrency of workflows
6. Call external methods and use those results in workflow
7. Automate a sequential set of tasks.

I would like to talk about performance of Windows workflow. Since it runs on the application server. Doing things wrong/inefficient can slow down the entire server and eat up the processor and clog the database.

I want to talk about few things which you should keep in mind while programming or designing Windows workflow:
1. Performance: It’s an important aspect of every piece of code. But it becomes very important in case of workflows. E.g. you have to give discount to user on your product based on the sales, page hits and other parameters in 1 million products on your website. Calculating discount for individual product should be very efficient, it should take less than a second by your workflow. Workflows should not run more than couple of hour.  Keep batching in mind. If you are reading an item from database, processing it and writing into database try batching stuffs. Divide 1 million item in batches, read a batch of 10000 items -> process them -> save 10000 items together. Batch size is critical can be best explained by:

2. Logging: Log every failure, successes, high importance in proper category for telemetry and support purpose.
3. Scalability: What if you start dealing with 100 million products after supporting 1 million products. Keep this in mind. In that case, divide your products with category, run workflow for individual category. Don't do any unnecessary operation in your workflow. Which can slow down your workflow by many folds.
4. Modularization: Try to break your methods as small as you can. So that it can be used by some other activity, help you in unit testing and improves the maintenance of the code.
5. Memory: Keep memory leakages in mind. For egg. C# has a built in garbage collection, but always Dispose objects which are derived from Disposable interface. When your workflow is running keep track of memory used by the workflow process in the task manager. It should increase and become constant. If the memory should keep increasing during the life of the workflow, it’s an alarming situation.
6. Activity flooding: Decomposition of every tasks to an activity might look fascinating. But creating every activity has a cost (creating activity and deleting activity) by the workflow. We should not create 3 activities for a million object. That means if the cost of Create + Delete of an activity is 0.01 sec then you can save 20K seconds = 5 hour by creating 1 activity to do all 3 things together.

Remember workflows are made to "Do work”. If you have some base cases, which will exit the workflow in between, check that condition before the workflow is kicked off.

Let me know if you have more pointers to improve programming in WF.
Disclaimer: Ideas/Views mentioned above are purely personal and learnt with Experience/reading. Feel free to correct me.