Nikhil's Blog

I recently learnt a new shortcut to get to the task manager: Ctrl + shift + Esc. It's especially useful on Vista and Windows Server 2008. On these OSs, ctrl+alt+del maps to another screen where you can select the task manager. One screen lesser to get to the task manager is totally awesome!

Also, my colleague loved another shortcut key combination (ctrl + alt + end) that I have been using for a while. Ctrl + alt + end shows the task manager on the remote machine when using Remote Desktop.

I'm just putting it out there - in case, someone will find this useful!

(I have to admit that I was inspired to blog about this by Sara Ford's amazing VS tip of the day series (she's at #193 right now) . She'd recently shared her blogging experiences with some of us and how people love shortcuts!)

We announced the release of VSTO power tools at Office Developer Conference (ODC). Of the many tools that we released, I will discuss the SharePoint Workflow Package Generator. Workflow package generator is a tool that creates a WSP file from a VS 2008 SharePoint workflow project.

The package generator uses the feature.xml file to generate a WSP file. In the WSP file, it will also include any <ElementFile> that have been referenced. Hence, any referenced InfoPath forms and resource files will also be packaged in the WSP file.

To use the package generator just type:

“c:\Program Files\Microsoft VSTO Power Tools 1.0\workflowpackagegen.exe" /featureManifest:feature.xml

An example of incorporating the tool into the project as an MSBuild post-build task is shown below. You can add this to the end of your csproj/vbproj file to get a wsp file after every build:

<Target Name="AfterBuild">
<Exec Command="&quot;c:\Program Files\Microsoft VSTO Power Tools 1.0\workflowpackagegen.exe&quot; /featureManifest:feature.xml" ContinueOnError="true">
</Exec>
</Target>

Drop me a line if you find the tool useful. We're always looking for feedback on our tools.

A number of developers who have tried the SharePoint workflow features in VS 2008 wanted to know more about our support for InfoPath forms deployment. So I'm blogging it here for everyone's reference.

Before diving into details of InfoPath forms deployment here's a little bit of background on workflow and InfoPath forms integration. Typical SharePoint workflows goes through different stages - association, initiation, task completion. Also, workflows might be modified after being initiated. SharePoint supports ASP.NET and InfoPath forms to enable developers to capture user inputs at these different stages. For example, on initiation of a simple document approval workflow you might want to capture the approvers for the document.

To develop InfoPath forms you can either use the VSTO template for InfoPath that also ships with Visual Studio 2008 or InfoPath (with VSTA) itself. Once you have designed the InfoPath form it can be published as an XSN file. There is some great documentation on MSDN regarding this. In general, if you need code (custom event handlers/validation) behind your InfoPath forms you should use the VSTO InfoPath template and create a project alongside your workflow project.

Coming back to SharePoint workflow integration with InfoPath forms - It is very easy to deploy InfoPath forms along with your workflow. All you have to do is to add a relative reference to the form in the feature.xml with the <ElementFile/> element eg:

<ElementFile Location="InfoPathForm.xsn" />

When you press F5 you will see that VS will copy the form alongside your feature.xml files in the 12\TEMPLATE\FEATURES\<featname>\ directory. It must be noted that this is a relative reference to the form and VS will look in the path specified relative to the source location of feature.xml.

You can use the above feature to also install resx files or any other accompanying files. Also, the feature.xml file is processed by SharePoint on feature installation and absolute paths or relative references with ellipsis are not supported (for obvious security reasons). However, you can add references that need to be deployed as subdirectories and we will replicate the hierarchy eg:

<ElementFile Location="InfoPathForms\InfoPathForm1.xsn" />
<ElementFile Location="Resources\Resources.en-us.resx" />

On F5, a subdirectory named InfoPathForms and Resources will be created in the 12\TEMPLATE\Features\<featname>\ directory.

And yeah, don't forget to reference them also in the workflow.xml as an initiation, association, modification or task form, to see them show up at runtime.

Now go ahead and have fun with InfoPath forms!

I will continue from my last post on authoring SharePoint workflows in VS 2008 by providing a walkthrough.

In order to work with SharePoint workflows in VS you will have to setup your development machine as follows:

1)    Install Windows Server 2003.
2)    Install Internet Information Services (IIS). (In Control Panel, Add/Remove Windows Components, Application Server, Details, Internet Information Services (IIS).)
3)    Install .NET Framework 2.0 and.NET Framework 3.0.
4)    Enable ASP.NET 2.0.5727 in IIS Manager.
5)    Install Microsoft Office SharePoint Server 2007 (MOSS). Make sure to run the configuration wizard. [Edit: May 29: WSS is not supported]
6)    Install Visual Studio 2008. Use the default installation, or make sure that Visual Studio Tools for Office is selected on the Custom installation page of the Setup wizard.

Some questions that come to mind -  Firstly, why only Windows Server 2003 (no Windows Xp)? Well MOSS/WSS can only be installed on a Windows Server machine. And secondly, why does MOSS/WSS need to be installed on the development machine? It's just required to do any (not just workflow) practical SharePoint development since you have to do an iisreset, access the GAC etc.

Is the above installation order important? Yes and no. If you install SharePoint before Visual Studio, your toolbox for Workflow development comes initialized with all SharePoint related activities. So it is a good idea to install in that order. If you do not do so - you will have to reset your toolbox (Right click on the toolbox and select 'Reset toolbox') once you start developing SharePoint workflows.

Project Creation - Select the 'SharePoint 2007 Sequential Workflow'

New SharePoint Workflow wizard: A wizard shows up that allows you to specify the parameters for debugging - the name of the worklfow, the local SharePoint site (no support for remote SharePoint sites) on which to deploy the workflows, the list to associate it with, the task and history list to work with. Also you can specify, how you intend to start your workflow on F5. 

Select the parameters for workflow association on F5:

Workflow designer:On pressing 'Finish' in the wizard, the workflow designer shows up.

Property Window:A few additions to note include a property window that allows you to view/change the selections you made in the wizard. The property window is visible when you have the project node selected in the Solution Explorer.

Breakpoint: You can go ahead an now put a breakpoint in the workflow activity in the designer, by right clicking the activity and selecting 'Insert breakpoint' from the context menu.

Press F5 now to start debugging  and you will notice the output window shows all the deployment details - Install the assembly to the GAC, restart IIS, copy workflow.xml, feature.xml, and any other resource files/InfoPath forms you may have, install and activate the workflow template as a feature in SharePoint, associate the workflow with the list you specified in the wizard.

In the browser window that launches you will see the deployed workflow.

After you manually start the instance of the workflow, you will see the breakpoint being hit:

Btw. my technorati profile is getting started here: Technorati Profile.

As mentioned in earlier posts, I was one of the developers on the SharePoint Workflow feature in VS 2008. (shipped as one of the VSTO components - available in Professional SKU upwards)

The feature include a set of VS project templates, wizard, and VS project package that integrates creating, deploying, and debugging of SharePoint workflows into a streamlined, simplified experience.

Those who have used WSS SDK or MOSS SDK would realize that creating and debugging workflows in SharePoint is not an easy task. The main pillars of this feature were to significantly lower the learning curve for SharePoint workflow development, and make developers more productive. To achieve this, we knew that we had to optimize - what I like to call the code-build-debug cycle. That's where you are bound to spend most of your time while developing workflows, and any improvements there would be of great value.

Before VS 2008, typical code-build-debug cycle would be:

1. Write the code
2. Build the workflow project.
3. Copy the latest feature.xml and workflow.xml files to the FEATURE directory.
4. Remove any existing copies of the workflow assembly from the GAC.
5. Add the latest version of the workflow assembly to the GAC.
6. Re-start IIS.
7. Install the feature with SharePoint using stsadm.
8. Activate the feature at a SharePoint site where you intend to perform the debugging.
9. Launch the web browser and go to the list that you want to associate the workflow with.
10. Associate the workflow with  the list.
11. Attach the debugger to the correct IIS worker process. (W3WP)
12. Manually start the workflow.
13. Debug the workflow.

The steps in red are scriptable, and WSS and MOSS SDK include batch files to enable that. However, batch files are difficult to maintain (source control, hard coding etc.?), error-prone (when something fails - what do you do?), and slow (more on this in another post). Rest of the steps are manual, tedious, and time consuming.

Using VSTO SharePoint workflow project templates, your code-build-debug cycle will be so simple:

1. Write the code.
2. Press F5 (builds, deploys files, associates the workflow feature in SharePoint, attaches the debugger to the correct W3WP process, launches the browser).
3. Manually start the workflow.
4. Debug the workflow.

Imagine this being repeated every time you make a change to your workflow. This is how VS 2008 already gives you a great productivity edge - you just need to now focus on designing your solution.

Get your copy of VS 2008 and give the feature a try, and drop me a line about how you find the feature.

With a lot of fanfare, VS 2008 and .NET 3.5 released on Nov. 19th. Talking to customers and early adopters, I have received a lot of positive feedback on the product. Check out the excitement in the blogsphere:

• With more than 400 comments (and counting), customers seem to be certainly excited about the announcement of the release by ScottGu.
• Another great post is from a former MVP (Daniel Moth): Top 10 things to know about VS 2008 and .NET Framework 3.5.
• More link love and information of VS 2008 features can be found on this post.

Check out the spike in Technorati's visual studio blog topic chart:

Download your trial copy now from MSDN. In case you had installed any pre-release bits of the product, please make sure you uninstall it first.

Watch out this space for more posts with details of new VSTO features in the release.

This is a good article on performance tips of the .NET Framework Base Class Library - http://msdn.microsoft.com/msdnmag/issues/06/01/CLRInsideOut/default.aspx. I learned something new about lock-free tracing and DateTime comparisons.

The great numerical comparisons of generic Vs non-generic collections, for reference and value types, is a good read. Generics (as expected) perform better than their non-generic counterparts.

The "Orcas" release train has been keeping me busy. For a long time I have been thinking of blogging about the feature that I worked on in Orcas. As the title of this entry suggests it is a VSTO feature that has to do something with SharePoint Workflow.

Firstly, lets look at SharePoint (also referred to as Microsoft Office SharePoint Server (MOSS) - yet another long product name!). In the MOSS 2007 release, the SharePoint team has done a great job of integrating with the Workflow Foundation (WF) to provide a means to create workflows.

A workflow is a reliably repeatable pattern of activity enabled by a systematic organization of resources, and information flows (from Wikipedia). A typical workflow in MOSS would be that of document approval. An employee writes a document that needs to be approved by the manager before sending it out externally. When the employee checks in the document in a SharePoint library, the manager is assigned a task to approve the document. On approval, the employee gets a notification and sends out the document to the customer. This is a simple example, but a workflow can define a more sophisticated and complex series of human or automated activities in an enterprise.

As you may have guessed, that building workflows from ground up is a lot of work. The SharePoint team has done a great job by integrating WF and creating a great runtime story - taking care of difficult problems pertaining to persistence, serialization, permissions, user model etc., However, there is a necessity to make the development of SharePoint workflows much easier.  As John Durant in his blog post quotes Robert Bogue:

SharePoint and Workflow may be the most powerful combination since chocolate and peanut butter, but the trick is harnessing their combined power. That isn't as easy as it first seems, but in this article you'll learn how create a SharePoint workflow in Visual Studio from start to finish. 

That's where the VSTO SharePoint workflow tools come in. We have made it extremely easy for you to develop, deploy, and debug SharePoint workflows. We have brought the "simple F5 experience" (as we internally refer to it) that you are familiar with for Windows application development, to SharePoint Workflow development.

No more hunting for the right w3wp processes in the task manager, looking for stsadm errors, or running of some batch scripts to deploy your workflows. (as documented here) VSTO SharePoint workflow tools take care of all this for you.

Check this feature out in the VS 2008 Beta 2 release. Now you can focus on your business logic right away - without caring about setting up your environment for development.

Some people have been running into this issue with VS2008 Beta 2 as posted on the MSDN forum.

I am posting a workaround here for everyone's reference. When you change the default program for the .vsto file extension, VSTO solutions cannot be deployed again. You will have to reset the default handler for .vsto file back to VSTO Execution Engine.

For Windows XP:

Right-click a .vsto file and select "Open With...". In the list of the programs you should be able to see "Visual Studio Tools for Office Execution Engine Component (VSTOEE)". Please select it and make sure you select the checkbox that says "Always use the selected program to open this kind of file". In case you do not find the VSTOEE component in the list of the available programs follow the steps below:

For Windows Vista (and sometimes Windows XP):

You will need to add a registry entry to show the VSTOEE component in the Open With.. dialog box.

Copy and paste this into notepad and name the file vsto.reg:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\bootstrap.vsto.1\shell]

[HKEY_CLASSES_ROOT\bootstrap.vsto.1\shell\open]
@=""

[HKEY_CLASSES_ROOT\bootstrap.vsto.1\shell\open\command]
@="rundll32.exe \"C:\\Program Files\\Common Files\\Microsoft Shared\\VSTO\\vstoee.dll\",InstallVstoSolution %1"

[HKEY_CLASSES_ROOT\.vsto]
"Content Type"="application/x-ms-vsto"
@="bootstrap.vsto.1"

[HKEY_CLASSES_ROOT\.vsto\bootstrap]
@="bootstrap.vsto.1"

Now double-click the registry file to add it into the registry.

Once it has been added you might need to restart explorer.exe so that it picks up the changes. Now you should see the VSTOEE component being listed in the Open With... dialog box. Use it as the default program for the .vsto extension. Everything should work as expected now.

Hope this helps!

This is a significant milestone in the VS 2008 development cycle. Almost all our features have completed in this broadly available public release and you can expect a significant upgrade in features when compared to Beta 1. If you haven't already got a copy, download one from here.

Are you a little intimidated with the size of the download? With VS 2008 beta 2 we are for the first time on a large scale trying Microsoft Secure Content Distribution (MSCD) system that uses peer-to-peer technology developed at MSR to allow faster and easier downloads. More details on MSCD can be found at the Microsoft Research web site.

Let us know how you find the Beta 2. Give feedback through Microsoft Connect.

Today I attended an interesting talk on Performance Signatures by Rico Mariani. According to his experience, a high proportion of performance related problems are due to:

1. Bad choice of algorithm
2. Dependencies we take on other frameworks or platforms.

He talked about the second problem in detail. He proposed a mechanism of using performance signatures to evaluate performance of external dependencies we take. Performance signatures are a qualitative measure that can help us to understand the performance characteristics of a method eg. synchronization, memory allocation complexity etc.

He gave an interesting analogy from the architectural world. A structural engineer can evaluate materials on the basis of their tensile strength to build a robust structure. In the same way, a software engineer can use performance signatures to chose the dependencies he can afford to take.

Rico also mentioned how they have done the groundwork to enable this (through static analysis) and create performance signature for the .NET framework. They are expected to be published on MSDN in due time. A link to the cost metrics is here.

It would be great if these could be integrated into the VS IDE using Intellisense to use different colors - red, yellow, green to indicate the cost involved for a certain method. This will help people understand and detect performance issues early in the cycle. Another cool idea, as suggested by Krzysztof Cwalina, is to enable this using FxCop.

One might ask why does one need performance signatures? I think performance signatures will be most relevant when you are working against a library that has a high level of abstraction. Take for example - the .NET framework XmlDocument class. I have seen it being used all too often in cases, when it was not necessarily required. The same XML operation could be done without loading the complete DOM tree of the document into memory.

In general, .NET framework offers a high level of abstraction to make the life of a developer simple by creating very easy-to-use friendly APIs. But like any abstraction, it is bound to be leaky (See Joel's original post on leaky abstractions). Developers become care-free, thinking that the framework will do everything to manage memory and do the heavy-lifting, and they do not need to care about it. They do not give so much thought to dependencies they are taking during the design and development phase. Only after 6 months of investment in the project when the end-to-end scenario is working, they realize that the performance just sucks and the software is quite unusable. In this case, performance signatures can help get a better understanding of the performance implications of taking a dependency on a particular method.

A good read for developers: How to be a Programmer: A Short, Comprehensive, and Personal Summary. Check it out here: http://samizdat.mines.edu/howto/HowToBeAProgrammer.html#id2794476.

Other books that I think every developer should read:

	As the name suggests, this book provides some great pragmatic advice on programming. It is a very easy read and is helpful resource whenever I feel I'm not sure how to deal with an issue.
	This book is a comprehensive guide to how to become a great programmer. It is extensively well researched with great references and wisdom from other books of the same genre. It's thicker than pragmatic programmer, but it is still an easy read. Most of the concepts are explained through powerful metaphors and examples.

These books have a good deal of time tested wisdom. I refer to them every now and then. Every time I pick up these books, I begin to reflect on the way I work, and how to make it better. It reinvigorates me, and increases my productivity - I feel a renewed zeal and passion for my work - improving day-by-day. Go grab a copy, if you don't have one.

I'll take an exception form the technical tone of this blog and comment on a a great speech by Bill Gates at the Harvard commencement ceremony. It touches on a very important subject - all of us in our small, little way, can make a huge difference to a complex problem - let's do what we can - donate our time and money to benefit the underprivileged.

And I hope you will come back here to Harvard 30 years from now and reflect on what you have done with your talent and your energy. I hope you will judge yourselves not on your professional accomplishments alone, but also on how well you have addressed the world’s deepest inequities … on how well you treated people a world away who have nothing in common with you but their humanity.

Remarks of Bill Gates — The Harvard University Gazette

I do not remember how many times I have tried to connect to a remote desktop using terminal services, only to realize that Terminal Services are not enabled on the machine. I found this article recently on how to remotely enable remote desktop.

This trick worked just great for me even without restarting the remote computer. I'm just putting it down on this blog for later reference.

In the last few years, blogs have been largely instrumental in increasing transparency into Microsoft. From celebrity ex-Microsoft blogger, Scoble to the over 3000 bloggers now on MSDN blogs, we have been sharing more and more details of our development processes and technology bits through our blogs.

Why is this important? Generally, at Microsoft, development cycles are over 2 years long, and in some cases, even much longer. With increased transparency we can disclose a lot of our product features even before it is released. This provides us the essential customer connection and opens the feedback channel. Moreover, many times I have read a program manager's blog explaining the internal details of our product so that customers can troubleshoot and have a better understanding of the product.

Recently, we started a great initiative to share the product feature specifications of "Orcas" here: http://msdn2.microsoft.com/en-us/vstudio/aa948851.aspx. During the development cycle, we make some assumptions of how the customer will use the product and prioritize the most important use cases. We are (hopefully) mostly close to correct, but sometimes we might have missed the mark and we want you to tell us. I feel this is a great leap forward in increasing transparency and involving the community in the development process. Give us your feedback today. 

I worked on the Office Workflow Tools feature and would welcome any feedback you have on it. We will surely take it into consideration in planning for future releases.