Kushal Shah - Workflows

VisualWorkflowTracking aka WorkflowSimulator

kushals — Tue, 22 Dec 2009 21:17:59 GMT

In the Beta2 SDK, we shipped a sample called WorkflowSimulator. Essentially, the sample is using the tracking APIs to have a visual understanding of the Workflow execution logic.

Thus, as we hit “Run Workflow”, we get the debug kind of adornments on each activity that executed.

Let’s actually dwell deeper and understand how we used the Designer and the Debugger APIs to achieve the same.

To understand that, let’s take a step back and take a look at the debugging architecture:

The most important piece in the slide above are:

We have a 1:1 mapping between the activity objects on the designer surface and their corresponding line numbers

Similarly, we can also have a 1:1 mapping between the Activity Object that is executed at the Runtime and the unique Instance Id corresponding to the activity at the Runtime.

Thus from the above two bullets, we essentially have a mapping between the Activity Object <-> Xaml Line No <-> Activity Instance Id

This is achieved by the following lines of code:

//Mapping between the Object and Line No.
Dictionary<object, SourceLocation> wfElementToSourceLocationMap = 
                                            UpdateSourceLocationMappingInDebuggerService();
            
//Mapping between the Object and the Instance Id
Dictionary<string, Activity> activityIdToWfElementMap = 
                            BuildActivityIdToWfElementMap(wfElementToSourceLocationMap);

With this mappings now in place, we essentially plug in our custom tracking participant and as the TrackingRecords are received, we map them back to the Activity Objects and thus to their specific Xaml Line Nos.

Something like:

These Xaml Line No (also called as SourceLocation) are now provided to the DebuggerService – which then provides us with the adornment on the activity corresponding to which the tracking record was just received.

//Show the Debug like adornment
this.WorkflowDesigner.DebugManagerView.CurrentLocation = srcLoc;

where srcLoc is the XamlLineNo. mapping to the activity that was just executed.

You can find the sample by downloading the SDK here. You want to browse to WF\Application\WorkflowSimulator sample.

Finally, a note about the title.

Though the sample itself is called as Workflow Simulator; we are not in any way simulating the Workflow runtime. The Workflow runtime is executing as is. It is about the applications that can leverage the functionality/APIs which we are trying to showcase through the sample. For example, developers can leverage it as a Workflow Replay sample by archiving all the tracking records in a database and then channeling it to this application one at a time so that you can specifically know how the runtime executed a specific Workflow sometime in the past.

To showcase, this functionality in a primitive manner, I printed out all the tracking records on the right side of the application as they are emitted one at a time. If you double click on any specific record, it will take you(in terms of debug adornment) to the activity in the workflow to whom the tracking data corresponds to.

Similarly, you can think about applications like a Workflow Simulator as well as Visual Workflow Monitoring for a better understanding of the Workflow behavior with various inputs to your domain specific Workflow.

Thanks,

Kushal.

Differentiating between Cut-Copy-Paste/Undo-Redo/Drag-Drop/Move

kushals — Fri, 04 Dec 2009 20:18:00 GMT

A couple of customers have asked this one, as they work with the Programming Model, how do I know if an activity has been drag-dropped vs Copy-Pasted vs an Undo-Redo happened.

How do the customers use it? Well, for one of them they wanted to change the name of the activity if it is a Copy-Paste as against a Undo_Redo. For example. In case of a Copy-Pasted activity, the new name should be Sequence2. While for a Undo-Redo, the name should still be Sequence1.

The bad news is there is no simple way to recognize the differenced. However, with certain bit of work, we can certainly differentiate between them.

Undo-Redo: Through the UndoEngine.IsUndoRedoInProgress

Copy-Paste vs a Move: This is the tricky one. There is no easy way to recognize this one. Hence we need to use the ModelService.ItemAdded and ModelService.ItemRemoved events. So in case a copy-paste happens we would only get the ModelService.ItemAdded event. However if a move happens we will get the ModelService.ItemRemoved and then the ModelService.ItemAdded events. Just ensure both the items are the same one and you have differentiated between the two.

Finally for a drag drop from the toolbox, simply have a property within the activity where its value is null and once instantiated, have the property value to be non-null. That way you would know for sure that it is not a drag-drop in the subsequent times.

Thanks,

Kushal.

Using the Sequence Styling

kushals — Mon, 23 Nov 2009 06:55:06 GMT

One of the most commonly used designers and generally the root is the Sequence activity. Of course, we spent some amount of time adding the animation and styling to the the Sequence Activity Designer.

However, due to a number of reasons(costs mainly), the activity designer is internal. However, the good news is customers can take advantage of the styling and animation that of the sequence designer so all the composite designers can avail to it and have a consistent experience throughout their workflow authoring.

This is through:

where sacdt is for System.Activities.Core.Presentation.Themes namespace in System.Core.Presentation assembly.

Thanks,

Kushal.

IActivityTemplateFactory

kushals — Fri, 13 Nov 2009 03:11:00 GMT

As part of workflow authoring, it is always the case where the customer says, I like your out of box activity, however it has too many arguments/properties. I don't want to ask my user to set all these properties. And hence, now I would need to write a custom activity which has some of these properties and arguments already configured and maybe hidden as well from the user.

We faced the same dilemma as we were working on our Messaging activities. We wanted the user to know about the Receive and SendReply activities. However we knew that giving them separately would be not an easy configuration task for every user. To solve this problem and the customer asks we talked above, we came up with IActivityTemplateFactory.

In a nutshell, it is like pre-configuring your existing out of box activities as and when they are dropped on the the designer surface. And to check a simple example of it, look at ReceiveAndSendReply activity under the Messaging category in VS toolbox. If you lookup, we do not have any activity called ReceiveAndSendReply in the System.Activities assembly. It is the IActivityTemplate that is being termed as ReceiveAndSendReply.

The interface IActivityTemplateFactory is something like:

public interface IActivityTemplateFactory
  {
      Activity Create(DependencyObject target);
  }

Now as part of the implementation, in the Create method, you can create the instances of the objects/activities you want to be dropped on the workflow designer along with their pre-configured properties/arguments.

Internally, as part of drag drop from toolbox, generally an Activator.CreateInstance(type of activity) happens. However if we recognize the type is derived form IActivityTemplateFactory, then we do all the ‘typeobject’.Create.

Example:

public sealed class MyDelayActivity : IActivityTemplateFactory
    {
        public Activity Create(DependencyObject target)
        {
            return new System.Activities.Statements.Delay
            {
                DisplayName = "DelayActivityTemplate",
                Duration = new TimeSpan(0,0,10)

            };
        }
    }

Add this activity to the toolbox, drag drop it on the workflow, immediately you would see the Delay activity with its properties/arguments configured with ‘DisplayName’ as “DelayActivityTemplate” and the ‘Duration’ set to 10 seconds.

Thanks,

Kushal.

Morphing

kushals — Thu, 12 Nov 2009 04:38:14 GMT

Lets talk about a couple of common customer scenarios/questions that I have encountered till date.

1. Workflow authors want to use the generic activities such that they can start with Activity<Object> and then dynamically without having to replace the activity on the canvas want it to be changed to Activity<string>. Specifically, this should happen without having the user to remove the activity from the canvas and then replacing it with the right generic definition, there is no simple way.

2. Depending on some property value or some activity added/removed from the workflow, the author would want to see that a specific activity A is replaced by activity B. How do we go about doing that?

3. Refactoring of Workflows into simpler custom activities. Currently out of the product, we do not provide a refactoring mechanism where a activity composition can be refactored into a custom activity type and then replace the workflow with this type instead of the complete definition.

4. The workflow author would want to surround his activity with other composite activity. And instead of deleting/cut-pasting his activity – the author would want to just wrap his leaf activity as soon as the composite activity is hovered over the leaf activity during drag drop.

5. Workflow authors sometimes start with a simple activity and as they configure the activity he would want that additional activities be added on to the workflow. And this should happen dynamically based on property configurations without having the user to drag drop each activity separately.

All these scenarios can be accomplished using a concept we call Morphing of the Model Items. Example, say we have a Workflow wiht a root Sequence and its children being as follows:

Sequence

Activity1

PlaceHolderActivity

Activity2

This Workflow needs to be replaced as:

Sequence

Activity1

MyNewActivity

Activity2

Couple of things need to happen to accomplish this

1. Of course the model item representing the PlaceHolderActivity on the workflow designer surface needs to be replaced by the model item representing MyNewActivity.

2. Also, the Sequence activity’s Children collection needs to be updated so that the index with PlaceHolderActivity is replaced to the MyNewActivity.

3. Finally, we also need to ensure that all the incoming and outgoing links in Sequence towards and pointing out of the PlaceHolderActivity needs to now reference the MyNewActivity.

How do we achieve this:

 private void Morph(ModelItem oldModelItem, ModelItem newModelitem)
        {
            try
            {
                MorphHelper.MorphObject(oldModelItem, newModelitem);
            }
            catch(Exception ex)
            {
                //MessageBox.Show(ex.Message);
            }
           
        }

Please note that this will also have the properties’ values form the old PlaceHolderActivity would also be copied over to the new activity if there is a common subset between the two activities’ property collection.

Thanks,

Kushal.

Toolbox and Custom Activities

kushals — Wed, 28 Oct 2009 17:54:00 GMT

Couple of customers have complained that I have my assembly with all the custom activities referenced in the Workflow project and still I don't see them even on a Re-build in my toolbox.

Hence, I wanted to clarify the functionality we have in place for having custom activities show up in the toolbox:

1. If your custom activity is part of the same project, once you build the project and if the build succeeds, the activity would appear in the Toolbox under the current activity’s namespace name category.

2. If your custom activity is part of the different project in the same solution though as your workflow, it would appear still appear in the toolbox on a build, again under the activity’ namespace name category. Please specifically note that you would not need to add the project or assembly references to your custom activity projects into your workflow project. The assembly reference would be added automatically as part of the drag drop of the activity into the workflow.

3. Finally, if you have an assembly with custom activities which is not part of the solution, then, the user would have to use the “Choose Toolbox Items” dialog launched through the “Choose Items…” context menu in toolbox. In this dialog the user would need to click on the “System.Activities” tab and through the Browse, select the custom activity assembly and click OK.

This should get the custom activities in the list and clicking on “OK” on this dialog should add the custom activities from this assembly in the toolbox. They would then be added to the category under/from which the Choose toolbox Items was launched. Again, in this case the assembly reference wouldn't be immediately added to the workflow project. Only on the drag-drop of any activity from this assembly, would the assembly reference would be added.

Thanks,

Kushal.

Adding Activities on the designer programmatically

kushals — Tue, 27 Oct 2009 14:57:09 GMT

One of the common asks that customers have is how to add/remove activities from the workflow designer during its authoring – automatically though.

Example, If a specific property for a certain activity is changed, we would want that certain activities are added or removed from the workflow in its designer.

How do we go about doing that?

Well, we need to use model item infrastructure to go about it. If you have a custom designer for your custom composite activity, you can override the OnModelItemChanged event. Check the condition you want to base the addition or deletion of the activity and then:

ModelItem myItem = this.ModelItem;
do
{
    myItem = myItem.Parent;
}
while (myItem.Parent.ItemType != typeof(Sequence));

myItem.Parent.Properties["Activities"].Collection.Add(new Sequence());

where ‘this’ corresponds to the Activity Designer where you have overridden the OnModelItemChaged event.

In the code above, essentially I am getting hold of the model item representing the specific activity and then walking up the tree till I find the root activity. To the root I am saying, can you add another Sequence activity at the last activity in the workflow.

You would notice that immediately a Sequence activity would be added onto your workflow as the specific Model item has changed triggering the event.

Another variation of the above customer ask is, we do not want only one specific activity to be added. We want multiple changes including a few activities added or deleted. Or having a few properties configured specifically when a specific model change happens in the workflow.

We can do that as follows:

using (ModelEditingScope editingScope = this.ModelItem.Root.BeginEdit("Activities"))
 {
  this.ModelItem.Root.Properties["Activities"].Collection.Add(new Sequence());
  this.ModelItem.Root.Properties["Activities"].Collection.Add(new Sequence());
  this.ModelItem.Root.Properties["Activities"].Collection.Add(new Sequence());
  this.ModelItem.Root.Properties["Activities"].Collection.Add(new Sequence());

 editingScope.Complete();

 }

In the code above the important thing is that all activities are being added or removed as a single unit of work. Meaning, you can Undo once and all the four Sequence activities added would be removed. Redo once and all of them would be added in a single go. Something like Transaction in the Fx. Our designer equivalent for the same is ModelEditingScope.

Thanks,

Kushal.

Adding Variables, Expressions and Bindings Programmatically

kushals — Mon, 26 Oct 2009 19:29:35 GMT

I am assuming we already know how to add activities on to the designer surface dynamically using the designer programmatic APIs. If not please take a look here.

Another variation of the ask is we want to add variables and arguments to our activities/workflows at design time dynamically. Example scenario: If a specific activity is drag dropped and its input type is same as the output of the previous activity on the workflow, bind the input of this newly added activity to the output of the other activity.

Yes, we would need a variable here so that we can bind it to the InArgument and the OutArgument of the activities to link them for data flow.

How do we go about doing it:

const string myStrName = "myStrName";
Variable<string> mySimpleVar= new Variable<string> { Name = myStrName };
myItem.Parent.Properties["Variables"].Collection.Add(mySimpleVar);

This was just about adding a variable. How about providing a default value to the variable. Lets see how we go about doing that:

mySimpleVar.Default = new VisualBasicValue<string>
{
      ExpressionText = "\"Kushal\"",
};

Next step/hurdle – What if the variable is of some user defined type? We would then need to add a namespace declaration as part of the Imports section in the Workflow

Example: If you want to create a variable of type fooClass defined in assembly – fooAssembly.dll and namespace - foo, we would go about as follows:

static string requiredAssemblyName = 
                    typeof(foo.fooClass).Assembly.GetName().Name;

static string requiredNamespace = typeof(foo.fooClass).Namespace;

VisualBasicSettings vbSettings = new VisualBasicSettings();
vbSettings.ImportReferences.Add(new VisualBasicImportReference
{
        Assembly = requiredAssemblyName,
        Import = requiredNamespace
});


mySimpleVar.Default = new VisualBasicValue<foo.fooClass>
{
       ExpressionText = "new foo.fooClass()",
         Settings = vbSettings

};

Now the rest is about the binding of the outArgument of one activity to the inArgument of the other activity. For example:

Argument myArg = 
          Argument.Create(typeof(foo.fooClass),ArgumentDirection.In);

myArg.Expression =   new VisualBasicValue<foo.fooClass>
{
                        ExpressionText = myStrName
};

this.ModelItem.Properties["Response"].SetValue(myArg);

where “Response” is an InArgument for my activity and myStrName is the variable we just created above.

We follow the similar model for the outArgument and you have programmatically completed binding the output of one activity to the input of another activity. One change though is that for the outArgument expression assignment you need to use a VisualBasicReference instead of a VisualBasicValue.

Thanks,

Kushal.

WF 4.0 Templates - Beta2

kushals — Mon, 21 Sep 2009 21:48:00 GMT

During Beta1, I had talked about the templates we are shipping in depth and our rationale around here.

However, we got a lot of feedback around them as this is one where which has the first visibility and more or less is taken as some form of guidance from us(product team) around how to start the development with Workflows/WCF.

Based on this feedback, couple of things have been updated with respect to templates for Beta2. Please let us know what you think as we get ready for RTM and need to make some final changes in time before shipping VS 2010.

The Project Templates under the Workflow Node:

Yes, we have removed the Flowchart Console and the Sequential Console Project Templates. The biggest reasoning being we didn't want to portray(mis-guide) Sequence and Flowchart as being the only root activities possible. It is possible to have any composite or a leaf activity to have your root activity for the workflow.

Also, going down that route, we wouldn't know which ones to promote as first class root activities. We have Sequence and Flowchart. What happens when StateMachine comes? Or why not Parallel?

Hence the best approach going forward, was to have a single Activity Library and a single Workflow Console Application. They are both with the root being the ActivitySchema(Activity x:Class)

We also have the ActivityDesigner as a separate Project template, as we do expect users to consistently separate their activities and designers into separate assemblies so that onl the activities assemblies are deployed onto the production machines.

Finally, we also have the WCF Workflow Service Application. This is where we have the integration between the Workflow and WCF. This is the consolidation of the Declarative Sequential Service Library and the Declarative Flowchart Service Library. In Beta2, the Xamlx file only contains the Sequence template wrapping the ReceiveAndSendReply activities.

This specific Project Template is also part of the WCF node under Visual C# and VB as well as part of the root Visual C# and VB nodes.

Please note that it is a Web Application project type. So even though Xamlx is deployed standalone, the project can have other activities and designer items added to wrap them as a dll. Using the Web Application project type gave us a couple of advantages including the single click deploy and the the F5 on Cassini experience.

The Item Templates under the Workflow Node:

Continuing on the same principle followed in the Project templates, we have removed the Sequence and the Flowchart templates. We now have just the Activity template which is same as the Workflow authoring in Workflow 4.

The declarative Sequence and Flowchart item templates have been replaced by a single WCF Workflow Service item template with the the same Service.Xamlx file as the Project templates. Again following on the project template principle, the item template appears now in the Workflow node instead of the Web node in Beta1.

The ActivityDesigner template remains the same.

Finally, the Code Activity item template also has been updated to make it clear(through the comments) on how to use a code activity to return a value.

IActivityToolboxService

kushals — Wed, 16 Sep 2009 16:01:00 GMT

During Workflow authoring, customers generally want their Toolbox to be context sensitive. For example, if a specific activity is added to the workflow, then they want to ensure that the Toolbox shows a few additional activities. Or if the activities are removed from the workflow, the toolbox should react appropriately based on the domain requirements.

Of course, in the re-hosted workflow designer world, this is simple as you control the Toolbox control and can ensure that based on the Model changes in the workflow, the host triggers appropriate changes in the Toolbox control.

However, in VS since Toolbox is a VS specific control, we needed something additional. That something additional is the IActivityToolboxService. The API provides the following 4 methods:

public interface IActivityToolboxService 
    { 
        void AddCategory(string categoryName); 
        void RemoveCategory(string categoryName); 
        void AddItem(string qualifiedTypeName, string categoryName); 
        void RemoveItem(string qualifiedTypeName, string categoryName); 
        IList<string> EnumCategories(); 
        IList<string> EnumItems(string categoryName); 
    }

Hopefully, they are pretty self explanatory.

I have also attached a very basic sample where if the specific activity designer has its OnModelItemChanged event triggered, we use the IActivityToolboxService to edit the Toolbox items in VS. And the OnModelItemChanged would be triggered when the CustomActivity is drag dropped on the workflow.

Please also note that, to remove an item from a specific workflow tab, you should have added it through the IActivityToolboxService there in the first place. Meaning, you would not be able to remove any out of box activities for Workflow1.xaml. The way it works is you add custom activities in the first place and then delete them as needed, depending on the context you are in.

Thanks,

Kushal.

Re-hosting the Workflow Desinger in Read-Only Mode

kushals — Tue, 15 Sep 2009 02:53:00 GMT

One of the questions, we get fomr customers is how can we re-host the designer in a Read-Only mode. Well, here you go:

For Re-hosting a Flowchart, we have:

this.wd = new WorkflowDesigner();

this.wd.Load(new Flowchart());

Going further, to make this Flowchart ReadOnly, add:

ReadOnlyState state = this.wd.Context.Items.GetValue<ReadOnlyState>();

state.IsReadOnly = true;

This should get the designer in the read-only mode so that no other activities can be added or none of the activity properties changed.

Debugging in Workflow 4.0

kushals — Tue, 02 Jun 2009 01:27:56 GMT

Visual Studio 2010 Beta1 is out and includes the new Windows Workflow Foundation (WF 4). This is something we have been working on for last 18 months and specifically I have been responsible for the Debugging experience of Workflows.

As in Workflow 3.0, we continue to provide the debugging experience for workflows through the designer surface. In addition, we continue to make improvements over the existing 3.0 workflow debugging experience. Some of the enhancements include:

The underlying representation of the graphical form of the Workflows we see on the designer surface is Xaml. This Xaml representation can be viewed by right-clicking on the workflow file (.xaml) in the solution explorer and selecting ‘View Code’. Though users can author the workflows entirely through the designer, it is possible that developers would like to view the Xaml representation and directly edit the workflow through this view. For such purposes, we now allow the users to seamlessly debug workflows through the designer and the Xaml view.

Below is a workflow which has a breakpoint set through F9 or through the activity's context menu on the root activity. If we F5 this project, workflow execution will break on the root activity as follows:

At this point, the developer may decide to move to the Xaml view of the workflow through the ‘View Code’ option.

This will open the Xaml view and you can see that the root Sequence activity still has the debug adornment in the Xaml view.

You can remove/set the breakpoints on the Xaml view, and debug through the Xaml view. Or you can switch back to the designer view by double clicking on the workflow file in the solution explorer and debug on the designer surface. Pretty seamless!

On switching to the designer surface, you will notice that we have the bread crumb view of the parent composite activity.

In addition to the seamless debugging, the other features like Locals, Call Stack, Watch, Immediate and some breakpoint window support are provided as well. The traditional F5/F10/F11 mechanism work as expected providing step over and step into functionality. If the activities are implemented in code, the user can debug into the code by setting a breakpoint on the Execute method defined for the activity in C#/VB.

We also support ‘Attach to Process’ workflow debugging which can be leverage when debugging workflow services hosted in IIS.

Last but not least, we have made DebugService public in WF 4 so that users can extend the behavior for creating custom applications like Monitoring, Simulation and provide debugging even in the case of the re-hosted workflow designer. I will cover this aspect in my next blog post.

Thanks,

Kushal.

Workflow 4.0 Templates - Beta1

kushals — Mon, 01 Jun 2009 22:32:48 GMT

As Visual Studio 2010 Beta1 is released, let’s take a quick walkthrough of the Workflow templates we are providing for the new Windows Workflow Foundation (WF) model provided in the System.Actvities.* namespace (for brevity, I'll use WF 4 to refer to workflows to refer to WF workflows from this namespace).

Opening Visual Studio and the New Project Dialog, click on the Workflow tab under Visual C# or Visual Basic. You would notice the following Project Templates for Workflow.

Lets take a quick look at each of them,

The Activity Designer Library provides a way for the user to create a custom activity designer. It is essentially a WPF User Control with the base class being WorkflowElementDesigner which is the base class for the activity designers. As you would see below, the designer shows the root/default activity designer provided through the WorkflowElementDesigner. Users creating the custom activity designer can start with this base template designer to create designers as needed.

Next, the Activity Library template provides a way for the users to create custom activities. It contains the root activity Xaml file where the users can drag drop existing activities on the canvas and compose them to create new custom activities – purely declaratively. Alternately the user can choose to create custom activities by providing its execution logic through imperative code. We provide a pre-built Item template ‘Workflow Element’ for creating a code based activity. The two Project and item Templates are as follows:

Moving on, the next two Project Templates are the Sequential Workflow Console Application and the Flowchart Workflow Console Application. As the name suggests they provide different workflow authoring styles wrapped within the root activity which can then run through the host provided in the Program.cs file.

In essence, there is no difference between the activities we created through the Activity Library and the Workflows we author through the Console Application. The root for both of them is <Activity>. So it is possible that you can take the Activity Library created activities and run them directly through the host provided in any of the console applications. The only reason we have provided the Sequential and Flowchart templates is because we think of them as the common modeling/authoring styles that users would adopt while creating their workflow applications. They have been created as Console applications so that we can provide users with a quick F5 experience for unit testing purposes. As any other project, Library and Console Applications can be switched to the other one through their Project Properties pages.

Now, lets talk a bit about the Item Templates. The users can add pre-existing templates as items to their projects through the Add new Item option available in the context menu for the project. The Item Templates under the Workflow node for Visual C# or Visual basic are:

Flowchart, Sequence and Activity and Activity Designer are self-explanatory. In addition, we also provide a few item templates for Workflow Services. They are the Declarative Flowchart Service and the Declarative Sequential Service. As the name suggests, they are the workflow services containing the messaging activities wrapped within the Sequence or a Flowchart. You would also notice that the extensions with these workflow service files is Xamlx. This is because when the services are deployed onto IIS, the right workflow specific httpHandlers can be invoked (WPF already registers Xaml as the extension, so we needed a new extension to invoke our HttpHandlers)

As you would notice below, the Xamlx file here contains the Receive and a SendReply activity configured for a simple message receive and reply back. Like the ASP.NET model, these files don’t need to be compiled and can be directly deployed onto the IIS/web server. For a seamless deploy/publish experience, we have also provided the equivalent Declarative Sequential Service Library and the Declarative Flowchart Service Library Project Templates. These templates are the Web templates with options to Package and Publish available for deploying the services. These options are exactly similar to the ASP.NET web services available.

One question that must be coming to your mind is what happened to the WF 3 workflows (workflows created using the System.Workflow.* namespace)? Can we still create workflows using them? The answer is Yes! To start your workflow applications using WF 3, in the New Project Dialog, change the Target Framework to 3.0/3.5 to see the Workflow 3.0/3.5 templates.

Selecting these templates would get you started with ~~the~~ WF 3 workflows.

The Item Template in this case would now be for WF 3 as well.

You can also create WF 3 projects with .NET Framework 4 using the Project Properties pages and changing the Target Framework Version.

That was a quick walkthrough of the project and item templates we’ve provided to you in Visual Studio 2010 Beta1. We’re very interested in hearing your feedback. Specifically, would you like more/less templates? Did the names of the templates make intuitive sense and helped you pick the right now? Were they discoverable on the New Project dialog?

.NET Source Code Debugging

kushals — Mon, 29 Oct 2007 05:11:00 GMT

Recently I came across this blog from ScottGu and was thrilled to see this initiative from the .NET team. Imagine now being able to debug seamlessely into the .NET framework code. Gone are the days where you have to downaload the Reflector to look at the .NET code to understand its workings.

The steps are pretty straightforward as listed in the blog above. One thing I was disappointed was Workflow code is still not public but as it seems they plan to release it very soon. That would be great. I am so excited to use this feature and my first task is to leverage it in my attempt nowadays to understand VSIP(though with so much of COM code in there, I am not sure how useful this tool would be),

Anyways, a great step by the .NET team. So much for open source....

Thanks,

Kushal.

Recruiting Trip

kushals — Mon, 29 Oct 2007 04:54:00 GMT

It was a very hectic week for me. I had been on one of the recruiting trips to a school on east coast. Other than the rough schedule, I learnt a lot of how things work and also made me remember where I came from and how I used to think just 3 years ago.

To start with I would like to encourage students - both graduate and under-graduate to start following the technology industry and this is where I think I missed out. No one explained to me the importance of understanding the trends in here and how important it is to be opinionated since early age. A simple question like name your favourite S/W product made students think hard is not a good sign. If I had to advice the students, it is OK if you get grades a notch below in your course work, but make sure you start understanding this industry and knowing where your niche lies.

Other thing is, students apply for the PM position looking at its cool title 'Program Manager', but the title is far away from the truth. PM at Microsoft is a unique position where you are responsible for a feature, but in the end none of the feature Devs or Test is answerable to you. There is no coolness of the manager name in it. If anything it is one of the most hated and misconstrued positions in Microsoft. This blog from Steven Sinofsky I think is a great one which goes lengths to explain the position and its responsibilities. So if you think you have it in you, we are hiring!!!

Thanks,

Kushal.