Home > SharePoint 2010, SharePoint Conference > SharePoint Conference Notes on SharePoint 2010

SharePoint Conference Notes on SharePoint 2010

I am currently at the 2009 SharePoint Conference where they are unveiling the details of SharePoint 2010. I’ve attended a lot of developer focused sessions today and wanted to list out some of the more intriguing functionality I’ve heard about.

Link to my blog postings for each day at the conference.

  • SharePoint can be installed on a local developer machine !!!!!!!!!
    • When I first heard you can develop SharePoint on your local machine I thought you had to point the solution at a site running on a server. But, that is not true. You can actually install SharePoint on your local machine and point your development at that or a site running on a server.
    • Machine must be Windows 7 or Vista – as long as they are x64
    • This means no more virtual machines for me (what will I do with all my external drives that hold my old VPCs)
    • The install for this version is a little different from installing on a server
      • This is just for developers and is not supported for production
      • This can only be a standalone version
      • The pre-requisites are not automatically installed like the server installation does. You have to go through the SDK and manually install the pre-requisites
      • This functionality can be disabled through a group policy if a company doesn’t want people installing SharePoint on their local machines
  • New names (of course, every new version of SharePoint means new names to remember). Here are the mappings to the 2007 names
    • MOSS = SharePoint 2010
    • WSS = SharePoint Foundation
    • 12 Hive = SharePoint root
  • The development experience is vastly improved. I thought Microsoft was just going to revamp Visual Studio Extensions. But, it looks like they built it from the ground up with all the features we have been asking for. So, no more WSPBuilder for me.
    • Visual Studio will retract the solution, deactivate the features and install the solution. But, that is just the default way it does it. You have complete control over the deployment process for the WSP it builds by changing a couple properties at the project level.
    • The deployment functionality has built in “extra” functionality for the type of element being deployed. For example:  WebParts will actually get removed from the WebPart gallery when the solution is removed. And, this is a default behavior that you can modify if you want. This new feature is called Deployment Conflicts.
    • Visual Studio has a SharePoint Explorer view. You can see your whole SharePoint structure, for a site, in this new view. And, you can dig all the way down to specific items to see their properties.
    • Deployment can be done directly to your site for development purposes. Or, it can just be exported to a WSP.
    • The whole process is customizable. I didn’t see anything that forces you to do it the “Microsoft way”. For example: They create the Manifest for the solution. But, they give you a way to “append” to their manifest (this kind of does a merge) or they allow you to completely replace their manifest.
    • The new development experience in Visual Studio 2010 is probably the most exciting thing that I’ve seen so far (other than the fact that we can deploy on our local machines). So, actually, the whole development experience is the most exciting thing I’ve seen so far.
  • Visual WebParts – these allow us to build user controls that get deployed as WebParts.
  • Elements from Designer can be exported to a WSP and imported into Visual Studio. Yeah…I can finally endorse SharePoint Designer.
    • You can export a site in SharePoint Designer by choosing an option to save it as a template. This creates a WSP file.
    • You can import that WSP file into Visual Studio. When you do this, Visual Studio gives you a UI to let you choose the elements from the WSP to import. For example: you can choose to import just a list.
    • The import functionality of the WSP creates a new project in your Visual Studio solution with features and everything
  • SharePoint Designer has site Workflows. These are Workflows that aren’t bound to a list. Why is this great… because we can finally export Workflows out of SharePoint Designer and into Visual Studio. Yes, we have deployable Workflows from SharePoint Designer – finally!
  • You can create Workflow Wireframes in Visio and import/export them from SharePoint Designer. This gives a development path from inception to delivery for Workflows. Design it in Visio, hook it into SharePoint and tweak it in SharePoint Designer, code against it in Visual Studio.
  • Developer Dashboard – this is a view, on the actual page, that is useful for Developers. Think of an output window from Visual Studio sitting on your WebPage (but with more information). 
    • Shows Database query times for everything going on in a page
    • Shows Call Stacks
    • Gives info about the page
    • Shows load times
    • This is turned off by default. You need to turn it on in stsadm or PowerShell
  • Around 500 commands were created for PowerShell
  • External Content Types – this allows us to hook up external data into a SharePoint list for read/write operations
    • We build Business Connectivity Services that have methods on them that allow us to work with external data. Kind of like a Data Layer.
    • We can bind the Business Connectivity Services to a list through the External Content type.
    • Now we can read and update data, from a SharePoint list, directly to anything (especially our database).
  • Linq to SharePoint
    • This allows us to access SharePoint list data through Linq.
    • This creates a proxy, just like Linq to Sql, to work with the data.
  • They’ve really improved lists and list performance
    • List can hold over a million items
    • Items in lists can be filtered by the metadata. Oh yeah, did I mention everything gets tagged now with Keywords. So, that is the metadata that you can filter your lists by easily.
    • You can configure list throttling to only show a certain amount of items at a time (because a webpage can’t show a million items at once).
    • Lists have cascading deletes and disabled deletes! Cascading deletes are great for Lookup lists. Finally, a little bit of integrity between our lists.
    • Lists also have Excel like validation. We can put validation on a lists through Excel like calculations.
  • The Wiki functionality is used heavily on pages now. While you can still have WebPart pages, they should become more sparsely used now.
    • Pages have content fields on them which are Wiki based.
    • You can add WebParts in these content fields. For example: I could have one line of content, a WebPart and then a paragraph. They said they dynamically add the WebPart zone now in these content fields.
  • Theres a bunch of Client OM functionality.
    • Context model to open a site client side – very useful for Silverlight and/or Ajax programming.
    • REST API – utilizing another one of my favorite Micrsoft products – ADO.Net Data Services. Yes, we can expose our SharePoint data over REST!
  • Sandbox solutions – this is a new deployment methodology for WSPs
    • First, to understand this, you have to understand that there are two models of SharePoint
      • Self Hosted – this is what we are use to. Having our servers in-house
      • Online – this is the new hosting (cloud) model for SharePoint
    • Sandbox solutions allow us to upload WSPs, inside our site, to deploy them. While this can be useful in Self Hosted or Online, it is the only way to deploy WSPs in an Online model.
    • When you create your Visual Studio solution you can pick “farm” or “sandbox” for the type of solution. This can be changed later, but they said there can be complications trying to change this after the solution is created (but it sounds like those complications are rare).
    • Sandbox solutions have less functionality (but they said it has most of the functionality we are use to).
    • Sandbox solutions rely heavily on CAS. So, if you are writing code that goes against the CAS policies, you can’t use Sandbox solutions. This seems to be a security measure so that you can deploy code in the Online model. This also seems to be the main reason to not use Sandbox solutions unless you need to.
    • Sandbox solutions also have internal controls to keep from deploying bad code. One they showed is an error message when code takes too long to execute (i.e.: trying to determine infinite loops)
    • Sandbox solutions are deployed differently than regular solutions. They were a little vague on this. But, it sounds like you upload the WSP to a solution’s gallery on the site. Then, when something in the solution gets used for the first time the solution gets deployed. I think it is intended to be a seamless deployment (i.e.: it shouldn’t affect the user’s experience – no downtime for deployment).
  • Upgrade Path – you have the choice to keep the SharePoint 2007 look or go right to the 2010 functionality and look. You can also preview what your site will look like if you choose to go to the 2010 look. Upgrades should be a lot easier now and less error prone.

So, lots of great stuff. I got a little overloaded with information today, they really revamped the product and I think it is for the better. I’ll write another blog if I learn some more new things while I am here.

Advertisements
  1. Woody
    October 25, 2009 at 2:05 am

    Cool! Thanks for the notes! I feel like I might know what’s going on in the future… but then again, managers aren’t suppose to know what’s going on 😉

  1. October 20, 2009 at 11:26 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: