Corey Roth [MVP]

As you have already probably heard, a bunch of things have been added to Visual Studio to make the development effort less painful.  After working with the new version for a little while, I have got to say it will definitely change the way you think about SharePoint development.  Things like deployment and debugging that you used to waste tons of time on are simply a non-issue now.  Believe it or not, you now truly can set a breakpoint in a web part and hit Ctrl+F5 and start debugging your code (assuming you put the web part on a page of course)

Before we start, the first thing you need to know is that SharePoint 2010 is built with .NET 3.5 SP1 and not .NET 4.0.  All of the project types I have worked with were based on 3.5 although I have no reason to think they wouldn’t work if targeted to 4.0.  Hopefully, we can confirm if that works or not soon.  When you bring up the New Project dialog and click on SharePoint –> 2010, you will see quite a few project templates that you can start with.  Also of note is that these new project templates only work with SharePoint 2010.  Here is what was in my version, when I looked at it (subject to change of course).

• Import SharePoint Solution Package
• State Machine Workflow
• Event Receiver
• Empty SharePoint Project
• Module
• Business Data Connectivity Model
• Content Type
• Sequential Workflow
• List Definition
• Import Reusable Workflow
• Site Definition
• Visual Web Part

Many of these project types actually just correspond to one of the new SharePoint Project Items (SPI) that I will cover here in a bit.  The thing to point out is that you are not just limited to whatever you pick when you start.  For example, if you create a Content Type project, you can later add a List Definition to it.  With that being said, you typically just end up starting with Empty Project.  The Import WSS Solution Package project type is what you will use to start out migrating your existing solution packages with.  If will import your features and configure a new solution package.  You can then bring your source code in as needed.  We’ll talk more about some of this later.  The Import Reusable Workflow is used to bring over a workflow built in SharePoint Designer.

Now let’s take a look at what kind of SharePoint Project Items (SPI) we can create.

• Empty Element
• User Control
• Sequential Workflow
• List Instance
• Content Type
• Module
• Business Data Connectivity Model
• Web Part
• List Definition from Content Type
• Application Page
• Workflow Association Form
• Workflow Initiation Form
• State Machine Workflow
• Visual Web Part
• Event Receiver
• List Definition
• Global Resource File

Like I said earlier, a lot of those items map up to the project types.  Did you notice anything missing in the workflow forms?  Yes, they’ve create a great interface for us to deploy association and initiation forms but didn't bother to create anything for Task Forms.  That’s a little big of #FAIL if you ask me.  I encourage you to submit feedback asking for task forms.

When you create one of these projects, the first thing it is going to ask you is a URL to use for debugging and what type of solution you want to make.  As for the URL, you can specify it here and you can actually change it later.  I’ll say right now that they have improved things a ton and there are not any hard coded URLs or Ids in any thing I have seen yet.  For the solution type, you have two choices: Sandboxed and Farm.  I’ll have an entire post on what these are to give them justice, but for now I’ll just say that Farm will deploy the solution in a similar manner as you did in WSS3.  Sandboxes solutions are a new type of solution that deploys at the site collection level and runs with a lower trust level.  You are typically going to go with the Farm solution.

The next thing you really need to know about developing for Visual Studio is that a lot of things happen behind the scenes.  Visual Studio manages everything logically and there is no need to replicate the 14 Hive project structure in your project.  The point is that the structure of the hive is abstracted and you really don’t need to keep track of where things go any more.  If you create a web part, it groups all of the related files together, the code file itself, the .webpart file and the elements.xml file.  This goes the same for anything else you might create such as content types, list definitions, workflows, whatever.  Features show up separately and they have a new designer interface.  You can only change some of the basic feature properties such as scope, title, and description, and activation dependencies, but it does give you a separate XML file that you can put your own customization in as well.  Your changes get merged in with what the designer has at build time.  You can also right click on your feature and select add event receiver and you will get a nice wizard which creates a class for you with the overrides you selected.  I’ll talk more about the new changes in event receivers in another post.

I mentioned above that you can really just hit Ctrl+F5 and start debugging your SharePoint application.  In your project properties page, there is a new tab called Deploy (probably later to be named SharePoint).  This tab configures what exactly happens when you use the Build / Deploy options in Visual Studio.  Here you can configure Visual Studio to build your solution package, add / retract it, recycle IIS, etc.  You can specify the order and I imagine you will be able to add your own custom steps here as well.  Out of the box there are two deployment options.  One to deploy and one that deploys but doesn’t activate any features.  Here are the build steps available.

• Run Pre-Deployment Command
• Package wsp
• Recycle IIS Application Pool
• Retract Solution
• Add Solution
• Activate Features
• Run Post-Deploment Command

As you can see, all of the basic steps for deployment something to SharePoint are covered.  I’ll point out that there is still not any direct support for remote development, but since SharePoint will now run on Windows 7 x64 and Windows Vista x64, the need to develop remotely is largely gone.  You can do all of your development locally now.

That last thing I’ll mention is that they added something called the SharePoint explorer to the toolbox.  This allows you to browse your SharePoint site and view various properties on objects like you have probably seen with other tools in the past with MOSS.  There is obviously far more about the improvements in Visual Studio 2010 that I can cover here, but hopefully this is a good start for those of you that are curious about what’s new.