C# 3.0 Implicitly typed local variable

In c# 3.0 we got a new keyword var which enable you to declare implicit local variables.
(i) Let’s look into the statement I made, its ‘local’ variable, that means cannot be used as class variables (instance variable) and is declared only in methods, not even as method parameter.
Figure1
Execution of Code1 breaks at:
Figure2
(ii)Next thing about ‘Implicit variable’ is, it should be initialized, why? It’s very obvious how the compiler will know to what type it should declare the variable as. If you correct the above two errors we will get our next error at line 19.
Figure3
(iii) Implicit variable cannot be null, rather cannot be null when you declare them.
Figure4
OUTPUT:
You can see strE.getType() returns ‘System.String[]’
(iv) When you declare an implicit variable with multiple types you will get a compile time error.
Figure5
Figure6

LINQ and Implicit variable

Declaring implicit variable using ‘Var’ keyword should be restricted is one of the recommendations in the c# specification. The reason could be that many of the new features of c# 3.0 have direct relation with LINQ and these new feature suits LINQ rather than normal programming. Let’s explore the implicit variable and LINQ relation.

A very good example and a simple one is given at http://msdn.microsoft.com/en-us/library/bb384061.aspx. It explains using a simple string. For you convenience I will put the example here (figure 7), now if you replace 2 instances of var with string[] and string respectively, since string look like a more likely type for ‘var’ here, you will be tempted to think replacing var with string makes things easier then, why ‘var’. However, doing so will result in following error.

ERROR :Cannot implicitly convert type 'System.Collections.Generic.IEnumerable' to 'string[]'

class ImplicitlyTypedLocals2 { static void Main() { string[] words = { "aPPLE", "BlUeBeRrY", "cHeRry" }; // If a query produces a sequence of anonymous types, // then use var in the foreach statement to access the properties. var upperLowerWords = from w in words select new { Upper = w.ToUpper(), Lower = w.ToLower() }; // Execute the query foreach (var ul in upperLowerWords) { Console.WriteLine("Uppercase: {0}, Lowercase: {1}", ul.Upper, ul.Lower); } } } /* Outputs: Uppercase: APPLE, Lowercase: apple Uppercase: BLUEBERRY, Lowercase: blueberry Uppercase: CHERRY, Lowercase: cherry */ /td>

Figure 7

I know using string or build-in type is easy to relate, so let’s take a new example to understand the same scenario. Look at the code in figure8.Here instead of string we declare a class called SomeReturnClass and created a list< SomeReturnClass > with three values, to enable enumeration. Here use of ‘var’ cannot be replaced by SomeReturnClass for two reasons, SomeReturnClass does not have any constructor that take two int as parameters, the statement select new { x = w.updateValueI(), y = w.updateValueJ() }; therefore does not related to SomeReturnClass, therefore it’s more accurate to declare the output as ‘var’ and let compiler decide the type(Can call it anonymous type). Coming to the second use of ‘var’ at foreach (var v in objReturnClassX) , its very clear than objReturnClassX hold a type that better to be interpreted by compiler(anonymous type). Neither we have explicit convertion between ‘var’ and SomeReturnClass.

namespace CSharpFeatures { class ImplicitVariableLINQ { public static void GetImplicitVarLINQ() { List objReturnClassA = new List { new SomeReturnClass { i=0, j=2 }, new SomeReturnClass { i=2, j=2 }, new SomeReturnClass { i=2, j=0} }; var objReturnClassX = from w in objReturnClassA select new { x = w.updateValueI(), y = w.updateValueJ() }; foreach (var v in objReturnClassX) { Console.WriteLine("i:{0}, j:{1} ", v.x, v.y); } } static void Main(string[] args) { ImplicitVariableLINQ.GetImplicitVarLINQ(); Console.ReadLine(); } } class SomeReturnClass { public int i, j; public SomeReturnClass() { } public int updateValueI() { if (i <= 0) i = 100; else i = i + j; return i; } public int updateValueJ() { if (j <= 0) j = 200; else j = j + i; return j; } } }

Figure 8

OUTPUT

Workflow foundation (WF): Creating a Simple sequential workflow with ASP.NET.

Pre-requisite:This workflow example was created using following configuration

Visual studio 2008

.net Framework 3.5

Article assumes that the user understands the difference between sequential workflow and State machine workflow. For an overview please refer

Sequential Workflow:http://msdn.microsoft.com/en-us/library/ms735937.aspx

State Machine Workflow:http://msdn.microsoft.com/en-us/library/ms735945.aspx

Getting started

Whoever are old .net developer using Visual studio, can relate a WF development similar to the way you develop a webservice ie. You create a webservice and expect a application(usually a asp.net application) to host it,similarly WF service is created and expect a host application to call that service. However Webservice and WF are completely different and are nowhere interchangeable.I will divide this article into 3 parts,

1. Creating a WF, we will look into sequential Console application

2. Create a Host application (an asp.net application).

3. How Host and WF will communicate with each other.

Creating a Sequential Workflow

Steps

1. Open visual studio File > New project.

2. Select c# ->Workflow-> Sequential Workflow Console application.

3. Give appropriate project name (I gave it as CallAnalysis.WF)

Figure1

4. The project will create Workflow1.cs, Workflow1.designer.cs, and Program.cs. Selecting the design mode for Workflow1.cs will show you an empty sequential workflow.(figure1)

Business scenario

Now before we continue lets create our business scenario or objective or functionality that the WF will do. Let’s say you are working as a support analyst for an application where you get calls from application users. Calls can be divided as Incidents and Service request. Further incident can be divided into critical, high and medium and Service request is divided into severity1, severity2 and severity3.

Figure 3

Now let’s maps the scenario to our workflow application. To make things simple we will use the if-else activity and code activity only.

1. Open Tool box and drag the if-else between symbols as shown below.

To

Figure 4

2. Give appropriate names to the ifelseActivity1, ifelseBranchActivity1 and ifelseBranchActivity2. In the drop activity for ifelseBranchActivity1 add an if-else activity. Name the controls as shown below.

Figure 5

3. To explain figure5, workflow start at ifElseCallMain which we will configure later to check for the condition of call. If the call is an incident the control will go to IfIncident else to IfServiceRequest. If call is an incident, then control will go to the if-elsebranch IfElseIncident. Now for IfelseIncident, we need to configure to check for the condition whether it’s critical, high or medium. By default an if-else activity adds two conditions. If we need to add more conditions we need to add something called if-else-branch activity.

4. To add if-else-branch activity, right click anywhere with-in the boundary of ifelseIncident and click Add Branch.

Figure 6

5. Name the new branch as ‘ifMedium’.This will add a new branch called IfMedium for ifelseIncident

Adding condition: Code condition and Declarative rule condition

Now if you see the designer you will find exclamation in red, that says when clicked

Now select ‘IfCritical’ and on the property window select ‘condition’, you will see 3 options None, Code condition and Declarative rule condition.None is the default and we are required to select either of the other two.

Figure 7

Code Condition: When you want your condition to be evaluated based on your custom code. Drawback is the change in condition requires re-compilation.

Declarative Rule Condition: When an expression is evaluated to obtain the Boolean value for the condition. Here a .rules xml file is created that evaluate the condition.

We will explore both of these options. For Incident scenario we will write Code condition and for service request scenario we will use Declarative Rule condition.

CODE CONDITION IMPLEMENTATION:

1. Make the following changes for IfCritical, i.e. give the condition property to ‘code condition’.

Figure 8

2. This will give an additional property called condition. If you open the view-code for workflow1.cs, the name ‘CheckIncidentCritical’, will be the event names that visual studio automatically generates for you.

Figure 9

3. Make the changes for IfHigh and IfMedium, similar to IfCritical and name the events CheckIncidentHigh and CheckIncidentMedium respectively.

4. For IfIncident too select condition as ‘code condition’ and name the condition property as ‘CheckIncident’. Now do following changes to code

public sealed partial class Workflow1: SequentialWorkflowActivity { public Workflow1(){ InitializeComponent(); } private void CheckIncidentCritical(object sender, ConditionalEventArgs e){ Console.WriteLine("Incident-Critical Reached"); } private void CheckIncidentHigh(object sender, ConditionalEventArgs e){ Console.WriteLine("Incident-High Reached"); e.Result = true; } private void CheckIncidentMedium(object sender, ConditionalEventArgs e) { Console.WriteLine("Incident-Medium Reached"); } private void CheckIncident(object sender, ConditionalEventArgs e){ Console.WriteLine("Incident Main Reached"); e.Result = true; } }

5. Let’s have our first compilation. Right click the project and select build. Solution should compile without any error.

6. Now we are ready for our first run. Open the file ‘Program.cs’, it is the file that is currently helping us to be the Host application. Put a break-point on line ‘instance.start()’ as shown below.

Figure 10

7. Right click the solution and select “debug->start a new instance”. Press F10 until reach next line. Check the console window. Output looks like this

OUTPUT:

Figure 11

Explanation:

1. Ifincident will evaluate to true because of e.result=true in following line of code

private void CheckIncident(object sender, ConditionalEventArgs e){ Console.WriteLine("Incident Main Reached"); e.Result = true; }

2. Control goes to ‘ifcritical’ where e.result is not set and bool’s default value ‘false’ is taken. Print statement executed.

3. Control goes to ‘Ifhigh’, here e.result is set to true. Print statement executed.

4. Since no more statements follow it. Execution is stopped.

I know here you must be thinking, there seems no big difference since false and true both resulted in printing. So let’s get into little more coding with reading values from input window and seeing the difference. For that do the following changes to design.

1. Add a code activity (refer figure4 to add a control from toolbox to workflow) for each of the ifcritical, ifhigh and ifMedium activity and associate the code with it such that following changes happen in Design(figure12) and Code(figure13) respectively.

Figure 12

Figure 13

2. Two properties IntSeverity and IntCalltype are defined. GetSLACriticalI, GetSLAHighI and GetSLAMediumI are the excuteCode Property for the code-Activities codeCritical, codeHigh and codeMedium respectively.

3. Now let’s have a re-look of the if-else code condition methods. The value of the properties are used to set the e.result.

Figure 14

4. Now do the following changes to the program.cs. Compile the code.

Figure15

The changes that we did here is read the value of calltype and severity from console and create a dictionary object with following definition. Generic type Dictionary<> is the type the createWorkflow parameter expects.

Dictionary<string,object> callAnalysisParam = new Dictionary<string,object> (); callAnalysisParam.Add("IntCallType", callType); callAnalysisParam.Add("IntSeverity", CallSeverity); }

Another thing to be very careful is the “IntCallType” and “IntSeverity” name should be same name as the Properties that we defined in the Workflow1.cs class

5. Right click the solution and select “debug->start a new instance”. Press F10 until reach next line. Check the console window. Output looks like this

OUTPUT

To be continued ...