SharePoint Conference 2009 Day 1
On October 19th I had the pleasure of attending the SharePoint Conference 2009. This was the first time the SharePoint product team spoke publicly talk about what we are doing with SharePoint 2010. Nonetheless I was excited and looking forward to some of the cool features and capabilities of the conference, not to mention we are in Las Vegas! I have decided to share a daily review of my days at the conference and share with you what I saw and some of the cool things that are coming down the pike with this product. My track was mostly focused on development so my contribution here will be from the developers eyes and I will try to only share what’s new and improved.
The Keynote
The morning started with Tom Rizzo warming up the crowd for the keynote speaker Steve Ballmer. They then began by introducing SharePoint 2010 to the audience of 7400+. Tom started with a demonstration of some of the cool new development and integration capabilities in SharePoint 2010. He touched on the close integration with Visual Studio 2010 (which went to Beta 2 on this day and is available for download). One of the huge pain points with SharePoint 2007 was the development of Web Parts, Solutions, Features, and debugging SharePoint. With SharePoint 2010 these pain points have been addressed.
There was much discussion about SharePoint Online as well. Ballmer emphasized that SharePoint is currently being hosted in the cloud and SharePoint 2010 is extending our capabilities to provide SharePoint as a Service. Keeping in mind that on premise and cloud can integer mingle within and organization as there might be some areas of the business that it is okay to host in the cloud while other parts of the business should be kept in house.
The Developer Experience
Visual Studio 2010 now contains a Feature Editor and a Package Editor (MOSS 2007 Solutions are now Packages in 2010). These editors get you away from having to manage the various .xml files (elements, manifest, etc) that are required to create Features and Packages. The editors give you a UI to manage these items from within your solution and then generates the proper manifest files required for deployment. There is now a Visual Web Part Designer, which will allow developers to create web parts in a very similar way developers create ASP.Net User Controls today, allowing for dragging and dropping of controls and code behind along with a design view. In the past one would have to manually write all this code using your favorite language (VB, C#, etc.) and then hope you got the HTML correct etc. or use a third party solution like SmartPart, Son of SmartPart or a similar framework, now it is built in! Another major pain point with SharePoint 2007 are the manual steps that are required to deploy and activate a feature before you can run and debug your Solution/Feature. With the integration with Visual Studio 2010 this is automated for you out of the box using one of the project templates that are now available Out-Of-Box. This means once I have written my code and it is ready for testing/debugging all I have to do now is hit F5! This integration will save developers hours of dealing with the debug process. In debug mode the developer can now turn on the “Developer Dashboard” which is a report at the bottom of the SharePoint page which displays processing information, call stack details, and other relevant performance metrics about this page. Allowing the developer to get a quick snapshot at the performance of the current page and where bottlenecks might exist. Lastly, one of the biggest items that was received with great applause was the fact that SharePoint 2010 can now be run on Windows 7 and Windows Vista SP1 or greater in developer mode. This is a stand-alone mode for SharePoint where the SharePoint Services are running on the developers machine and cannot be connected to any other farm, etc and is not avail for production, the caveat here is your machine MUST be x64. This too has been major point of contention whenever I have to help setup a development environment for SharePoint 2007 as you previously needed a Windows 2003 Server to run SharePoint to perform development. This helps get away from having Virtual PCs for development sandboxes or some similar setup which can be clunky and slow.
Tom also showed the cool new integration with the new Office 2010 client integration. One of these highlights was leveraging Visio 2010 to design and create workflow processes which can then be imported into SharePoint Designer which will then generate the appropriate rules and actions for the workflow. Secondly, leveraging the new Business Connectivity Services (formally BDC) with External Lists. The demonstration involved connecting via SharePoint Designer to a SQL Server Database which had customer contact information. With a few clicks the contents of the DB was connected to a SharePoint List, which can be viewed and edited via the SharePoint List in the browser. He then continued to connect the contacts to Outlook 2010 Contacts and surfaced via Outlook. He then open one of the contacts in Outlook and edited some properties and saved. The data was then updated in both the SharePoint List and the SQL Database with a simple edit from Outlook, very powerful keeping users in the applications they know how to use while helping to manage business processes/data. Needless to say the team worked on making SharePoint Designer a great tool for building custom solutions for SharePoint with little to no code.
SharePoint Developer Platform Overview
The first breakout session of the day I attended was the Developer Platform Overview. In this session the speaker discussed the various platform features what make SharePoint 2010 a great platform for development. This session focused on 3 areas of development in SharePoint 2010, Developer Productivity, Platform Services and Deployment.
Developer Productivity
As mentioned earlier developer productivity will be enhanced significantly due to the tight integration with Visual Studio 2010. Developers will be able to build, debug, and deploy thier solutions right from within Visual Studio, no more jumping back and forth between the command line, Central Admin, and Visual Studio. Also, there has been major enhancements to SharePoint Designer to make it a first class citizen when it comes to designing and creating SharePoint Artifacts. IT becomes a kind of “No Code” tool for creating things such as workflows, Business Connectivity Service Entities, managing list schemas and other SharePoint artifacts. Visio also now comes into the fray as a way to visually create workflows which can then be imported into SharePoint designer to add rules. By leveraging the new Visio Services one can also get a visual view into the steps and the current status of a currently running workflow to see its status.
Platform Services
As for platform services some changes to note were the replacement of CAML with XSLT for List Views. Relational Lists which will allow for Transacted Cascade deletes or restricting a delete due to a relational dependency. Using Excel Formulas to validate the entry of list items. Also Business Connectivity Services are now a part of the SharePoint Foundation (formally WSS), this is big because in the past the BDC required the SharePoint Enterprise version to provide this capability, now it is a part of the core system. New Client Object Model (OM) to allow for building of Windows Applications and other applications to get at SharePoint data. A REST API to allow for strongly typed lists via the Client Side OM. Integrated LINQ to SharePoint API allowing strongly types server side lists. Lastly, but definitely not least is the tight integration of Silverlight 3. SharePoint 2010 has a Silverlight web part used as a media player which will allow for improved streaming of video via SharePoint. Also several web parts such as the Organization browser, List and Site Creation wizards are all built using Silverlight. and Finally a Silverlight Web part which allows the user to add any Silverlight application to the SharePoint page.
Deployment
As far as new deployment features go the Sandboxed Solutions Feature of SharePoint 2010 allows you to create and deploy custom code into a production farm with out affecting any other sites/site collections. The Sandbox provides a Site Collection for which this custom code is executed and via Code Access Security (CAS) policies the code is restricted to the capabilities of the CAS policy and the other policies set by the IT Admins such as throttling of resources available for the Sandboxed application. This along this the integration of the feature and package designers allow for a MUCH Easier deployment story and will allow developers to reduce the cycles between building and debugging their application.
Developer Tools Overview
The next session was to take a step deeper into the abyss of how development will be done with SharePoint 2010. The session was a little deeper dive into some of the features that Tom showed in the keynote session and the tools discussed in the Platform Overview. As many in the SharePoint development worlds knows SharePoint 2007 lacked virtually any integration with Visual Studio. Sure there was the templates for SharePoint but there really was no such thing as F5 debugging, as you’d need to know how to attach to an external process manually, not to mention the fact that you needed a server or a copy of the SharePoint.dll file manually added to do any SDK development. Well fans no more! Visual Studio 2010 has all the templates needed and with a little step by step instruction SharePoint 2010 can now be installed on your client machine (Windows 7 or Vista SP1). With the advent of SharePoint running in this developer mode and the integration with Visual Studio 2010 You project is now aware of what needs to be started when you hit F5 from Visual Studio to debug your project based on project settings that are configured when you create your project (or via project settings). When you run in debug mode for these projects Visual Studio will also now package and deploy your project to the SharePoint site so that you can debug/test your solution. Also tight integration with TFS and Team Build now allow you to seamlessly manage your application life cycle and source control without jumping through the many hoops we had to do in the past.
Visual Web Parts also meant that I no longer have to write my web part markup in my code behind. This feature uses the ASP.Net User Control foundation and builds on top of it. It should be noted here that WSS Web Parts are being phased out in SharePoint 2010 and developers are encouraged to use ONLY ASP.Net Web Parts going forward. However being able to drag and drop controls onto a Web Part designed for SharePoint is in itself a MAJOR step forward.
The Business Connectivity Services (BCS) designer is also integrated into Visual Studio. In SharePoint 2007 this tool was a separate application when designing entities for the BDC or you used a completely different 3rd party designer to design you Application Definition files. The tool will allow you to seamlessly create methods for your BCS application for (CRUD) and or other REST operations all while working inside your project.
As for improvements to the development of workflow, we now have the ability to design workflows from Visio import them to SharePoint Designer which can then eventually be imported to Visual Studio. The key here is to insure that your workflow is one of the “Reusable Workflow” type. This is a new workflow concept added to SharePoint 2010 that allows the developer to create a work flow that can truly be reused throughout the farm. Secondly, it should be good to note that Workflows can now be bound to items other than just a List. The import from SharePoint Designer to Visual Studio is a one way import as once code is added to the workflow SharePoint Designer will not be able to manage the workflow.
Event Receivers are now much easier to build and they can be run against the site as well as a list now. The tools integration to make this development task easier is done via a wizard with will give you context sensitive options based on the site you have connected to when you create your project. What this means is the tools will help to guide you in selecting the proper fields, receiver events, and any other related options needed to code your event receiver.
Lastly, an area of SharePoint development that has been a pain in the past is the building of packages (solutions) and features then deploying them throughout the development lifecycle. In the past this was done using batch files or some other scripting mechanism to build the .net code, build the solution, add the solution to SharePoint, Activate the solution, etc. and if you had new code to be deployed these steps had to be reversed. Well now with SharePoint 2010 and Visual Studio 2010 these tasks are now integrated! When you build or Deploy Visual Studio now knows what steps are required. The other nice thing about this is as a part of the project settings you now get a SharePoint Tab which will allow you to create custom actions and integrate them into your build/deploy process. The thing to note here however is that ONLY “Startup” projects in your solution will be build and deployed in this automated fashion. Good news is Visual Studio allows for multiple startup projects in a solution. So you can have all your packages in one big solution and still get the nice integration. The Feature and Package Designers are also integrated to help build the features and packages needed for your solution to be deployed. These tool help build the elements.xml and manifest.xml files required for the .wsp to be built. The goal of the SharePoint team is to keep you from having to manually build these files, also the designers will only give you those options/features available to you based on the project and the scope of the feature/package, so it is context sensitive as well helping to ease the burden of figuring out what is needed. You can add to these elements.xml and manifest.xml files as well as take full control and separate them from the designer if you wish to do so. Things to note however is that there is 1 package per Visual Studio project. When a new item is added to the project a feature is created to associate with the new item and the feature is automatically added to the package for deployment. If a feature or item is removed the feature and package are also updated to reflect the change.