Why I Stick With Visual Studio 2008 for SharePoint 2010 Development

People seem surprised when I start up my development environment to to SharePoint 2010 development. The surprise comes from seeing the Visual Studio 2008 logo flashes before their eyes.

“What you’re not using the latest and greatest? How come?”

I’ll tell you why, and I’ve already given you a slight hint. “The Visual Studio log flashes before their eyes”, indicating speed. Visual Studio 2008 is lightning fast.

I tried working on every edition of Visual Studio 2010 from the early betas. Compared to the earliest versions, the RTM version seems like a race car where the old versions were various species of snail.

Despite this, Visual Studio 2010 feels like a snail when compared to its old brother. I write a lot, not just code, so perhaps my typing speed is higher than average. I always feel the IntelliSense is sluggish and just a bit too slow to keep up. I try this on massive machines as well, sporting 16 GB of ram, so it’s not a hardware issue. Granted, I run this in a VM, but I’ve never had problems with this in 2008, so I blame 2010.

The thing I’m missing from 2010 is the smart IntelliSense that searches the entire words of methods and properties. I’ve grown so accustomed to the SharePoint object model, however, that the times when I need to search for methods and properties are few. It’s nice for exploration, but not enough to warrant the slower speed.

The next thing people ask is why I’m not using the fancy SP2010 tools. I’ll tell you why: They suck.

Yeah, there you go, I used the word again. I just don’t think the hype is worth the quality of the final product.

When I meet SP2010 developers who have previously worked with SP2007 development, they all say the same thing: the tools are bells and whistles, and takes away your feeling of control. Sure, for kids, it is nice to click around to give the impression of doing stuff. Compared to VSeWSS, I’m sure it’s great.

The two developers I’ve met that used the horrible VSeWSS tool previously are thrilled, and I can understand that. When what you’re coming from is your balls in a thumbscrew (ladies will just have to imagine something extremely painful, and no, giving birth isn’t as painful), then sitting on a bicycle with a missing seat must seem like heaven.

So what do I use? I stick with trusty old WSPBuilder. Heck, the experience is just as good as it always has been and the control is rivaled by no other tool.

Despite what seems to be a rumor, WSPBuilder is far from dead. I heard that Carsten Keutmann had decided to cancel the WSPBuilder project. I wrote him asking if this was true and he said that he was just pausing to see where the SP2010 tools and community headed.

I can tell you right now, Carsten, it’s headed for disaster, but because the lack of competition. With the SP2010 tools, you’re stuck in a maze trying to get control over your project, but ending up with nothing what you expect.

So the SP2010 fanclub says: “The tools are great once you learn how to use them!” to which I can reply that, you know, even if that were true, and I doubt it, I want to learn SharePoint, not how to use a particular tool. When there’s a learning curve for a tool beyond 5 minutes, the tool is faulty.

WSPBuilder FTW! Carsten, get yer behind in gear and get back to giving us the development experience we want.

.b

Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

SharePoint Workflow – What You Need to Know

The most powerful feature of SharePoint, at least the one most likely to cause a high return on investment (ROI), is the tight integration and high utilization of workflow.

In this short article, I will tell you what you need to know about SharePoint workflow in order to understand how to harness the power and potential economic benefit of business process management in SharePoint.

So, What Is a Workflow Anyway?

OK, you may have heard me use that exact phrase before, and you’d be right, as I explained this in a previous post on SharePoint Designer workflow. Rather than repeat what I wrote then, however, I’d like to offer a more descriptive… description.

A workflow is a formalized business process mapped to various executable activities on a computer. Think of a workflow as a highly adaptable and configurable program that performs a series of tasks. The program is adaptable in that it can be changed depending on business needs.

The ‘various’ part of the explanation is where you get the power of workflow. Compared to a traditional program, in which you often get a set of features and need to rewrite the program to extend that set of features, workflows allow you to pick and choose from activities.

Figure 55 

In short, you get a ‘pick and choose’ program that you can change as your needs change. Workflow is the Lego of programming, in a manner of speaking.

Wait, Programs? That Sounds Complicated and Unstable?

Yes, which is why I say ‘in a manner of speaking’.

You see, at least in the Windows Workflow Foundation that SharePoint uses, the framework handles most of the nitty-gritty details for you, and enables you, more or less, to just say what you want to happen when during a process. The stability and flexibility is also handled by the framework so you don’t need to worry as much about your workflows as you would normal programs. 

For example, if your server goes down, the framework will make sure that your workflow continues to run after the server comes back up. If you need to change your workflow, the framework and SharePoint will ensure that running workflows complete and that new instances of the workflow only use the new version of the workflow.

What Are Some Common SharePoint Workflow Examples?

Probably the most common example used is an approval workflow, in which some form of data requires approval from someone. The default SharePoint approval workflow is one such example, in which the author of the data requests approval for an item or document. This may be a request for expenses reimbursed, a vacation request, or any other request for which on user requires the approval of another user to complete some task.

Another common example is document management. Regardless of size, almost all organization have some form of document management, even if it’s as simple as telling a secretary to file a report in a certain file cabinet. Workflow can help automate document management, and the SharePoint document workflows offer some out-of-the-box functionality to cater to basic needs.

However, these are just two examples of scenarios in which workflow may help. The nature of workflow is that it can be customized to almost any business process, if nothing else than to track the progress of those processes or audit what happens during a process.

How Can I Create SharePoint Custom Workflows?

You have several options for creating and customizing workflow.

Out-of-the-box SharePoint Workflows

Granted, out-of-the-box doesn’t sound very customizable, but the truth is, many of these workflows are flexible enough to solve at least basic needs. For example, for the SharePoint approval workflow, you can customize who gets to approve an item or document, as well as deadlines for the approval tasks, and allow or disallow the approvers to reassign the workflow approval task.

If this still doesn’t meet your needs, you may want to take one step up.

SharePoint Designer Workflows

SharePoint Designer (SPD) offers a basic workflow authoring experience. With SharePoint Designer 2007, end users can create workflows without needing to learn complicated tools or adopt programming as a career.

Despite the perceived simplicity of SharePoint Designer workflows, however, you can accomplish fairly complex tasks using the built-in activities in SharePoint Designer. In addition, you can get or create additional activities to further customize your workflow and in essence create your own Lego pieces.

Figure 84 

SharePoint Designer is often scoffed at by developers as being a FrontPage bastard child. However, for designing one-off workflows with a very gentle learning curve, SharePoint Designer workflow is the way to go.

In addition, several of the limitations of SharePoint Designer 2007 are improved in SharePoint Designer 2010, as I have written previously in the first and second look at SharePoint Designer 2010 as well as the SharePoint Designer 2010 workflow features article.

You can learn all about SharePoint Designer workflows in issue 4 of Understanding SharePoint Journal.

Visual Studio SharePoint Workflows

The limitations of SharePoint Designer workflows become apparent when your needs become a bit more complex. That is when you may want to turn to Visual Studio.

Visual Studio offers the maximum amount of flexibility and power at the cost of a longer and more complex learning curve. If you want complete control and maximum power, however, that is the price to pay.

 Figure 84

However, while Visual Studio is traditionally considered a programmers tool, it is a myth that creating Visual Studio workflows require programming skills. You can get a lot more done if you do use some programming, but in essence, the same building-block paradigm is used in Visual Studio workflows as well.

You can get an introduction to Visual Studio workflows for SharePoint in issue 7 of Understanding SharePoint Journal.

Third-party Workflow Tools

If neither of these options are to your liking, you may want t
o turn to third-party workflow tools. Some well known tools are K2 BlackPoint and Nintex Workflow 2007.

Third-party tools offer both competing and complementary features to the already mentioned workflow tools. For example, Nintex Workflow 2007 offers a combination of the ease of SharePoint Designer workflows with some of the power of Visual Studio.

While a complete description of all the available tools is a bit beyond the scope of this article, you should know that these third-party alternatives exist.
You can also get the free Using Nintex Workflow 2007 issue of, you guess it, Understanding SharePoint Journal, if you want to explore that product more.

Anything Else?

Yeah, don’t forget to brush your teeth and floss. Seriously, everything I have said here is just my personal opinion, but brushing your teeth and using dental floss is recommended based on hard, scientific proof. Proper dental care leads to healthier teeth, prevents bad breath, and can improve the whiteness of your teeth without damaging chemicals.

.b

Pin It

SharePoint Visual Studio Workflows for Non-Developers?

UPDATE: The issue mentioned in this post is available at http://www.sharepointvisualstudioworkflows.com/

So, it’s time to do the second part of the USPJ Business Process Management series. This time, I’m going out on a limb, and I’m going to write a Visual Studio Workflow issue for non-developers.

You may wonder why I would write a non-developer issue based on one of the most hard-core developer tools there is. The idea here is to try to gently bridge the gap between advanced end-users and the power of Visual Studio workflow. I’m not going to try to make programmers out of you, but rather to introduce you, as gently as possible, to the world of real workflow power.

How, you say? Well, I’m staying away from the programming stuff as much as possible. I might end up with some short code snippets for illustration, but I’m going to do this using no-code approaches. That way, you will get an easy introduction to working with Visual Studio without having to learn C#, VB.NET, or any of that stuff.

I’ve received a lot of feedback from the readers of Issue 4 on SharePoint Designer Workflows that the content in the other issues is ‘over their heads’. I certainly understand that, the target for the other issues have been somewhat experienced programmers, and not everyone wants to take the leap into learning programming just to utilize more SharePoint features.

However, as I said, I’m going out on a limb here, because this may be a very wrong approach. Targeting non-developers may alienate experienced developers, and introducing developer tools to end users may still be a too big leap.

So, I’m asking you:

If you are an experienced developer (meaning you know the difference between a class and an object), would you be interested in a USPJ issue on no-code workflow development in Visual Studio?

OR

If you are an end user, would you be interested in learning to use Visual Studio to create even more powerful workflows than you can with SharePoint Designer?

Feel free to send your comments to furuknapgmail.com if you do not want to comment here.

.b

UPDATE: The issue mentioned in this post is available at http://www.sharepointvisualstudioworkflows.com/

Pin It