I’m a developer at heart. I think i will always be a developer at heart. For those folks who haven’t been in my presentations or know me personally I’ve been known to get a little giddy when I start talking geek. Yes I can play other roles – architect, team lead, tech lead, business analyst, manager (cough!) but development will always be my passion. When I am old and gray, probably sitting in a boring management\executive position because my mind has been turned into chum from years of keeping up with the technology grind i will probably still be cruising through the forums and developer blogs.

In the last several years, as a SharePoint developer and architect, you could measure that chum/burn rate on my brain in dog years - you know 1 human year = 7 dog years. This is mostly due to the fact that SharePoint development has historically been very painful, often involving lots of pounding of fists (and sometimes foreheads) on tables (I’ll leave the churn rate on broken peripherals and office furniture for another post lol).

Now to be fair the picture got a bit better in SharePoint 2007 but it still maybe turned that down to a 1/5 year ratio and that ratio was really more due to the communities awesome contributions to the SharePoint developer space then any particular effort from Microsoft. Now with SharePoint 2010 I would now lower that ratio even further to 1/2.5 and this time it’s in large part related to efforts by Microsoft in that area – finally! Now its not perfect but still a big jump in my opinion. Although you may not agree with me you can’t deny that Microsoft has FINALLY put more then just token resources on the developer experience.

So why is it that I am so excited about this release:

1. Visual Studio Experience – I think everyone recognizes (or should) that Microsoft isn’t going to develop the end-all-be-all toolset. Its just too cost prohibitive for even Microsoft. Saying that its still no reason that a baseline toolset shouldn’t be established. With a strong foundation, just like a framework, it can grow more powerful over time via contributions from not only Microsoft but the community and third party vendors as well. Microsoft has recognized that and as a result SharePoint 2010 is now finally a first class citizen in Visual Studio. With Visual Studio 2010 and SharePoint 2010 they have provided this base foundation for the Visual Studio experience that both provides a minimal subset of functionality and arguably just as important - a solid\extensible framework to build upon.

As part of this toolset you now have out of the box:

1. A SharePoint specific project format that supports the concepts of Packages (WSP), Features, and elements.
   
2. SharePoint specific project items such as webparts, visual webparts, workflows, content types, etc.
   
3. “F5” debugging support with pre-configured AND configurable deployments steps such as resetting worker processes (clearing GAC), creating solution packages, deploying solution packages, activating features, attaching to a debugger etc.
   
4. Visual designers for configuring both packages and features that allow for both designer based configuration and just as importantly the combining of configuration that the designer doesn’t support with custom configuration elements.
   
5. SharePoint Explorer for browsing through a SharePoint site’s artifacts' such as fields, content types, lists, etc.

Instead of having to make the difficult choice of what community toolset (or home grown) your organization standardizes on you can depend on the strong foundation that Visual Studio 2010 provides for SharePoint developers.

Lastly, a good tool understands that the common tasks should be made easy but the tool should still allow access to the complex stuff under the hood. Don’t make me have to beat the tool into submission just because the original creator hadn’t had time or thought of my scenerio. Make it easy for me to change my oil but still let me drop a new transmission in if I need to. This is where I believe that Visual Studio Extensions for WSS (VSeWSS) went wrong and was never really able to overcome. This is solidly not the case with Visual Studio 2010 and SharePoint 2010.

1. “Developer Continuum” – In SharePoint 2010 the developer continuum refers to the ability for all the tools in the SharePoint toolbox (Browser, SharePoint Designer, Visual Studio) to be able to work together in a cooperative way and “hand-off” artifacts from one tool to another regardless of the life-cycle.
   
   In 2007 this continuum didn’t exist. The toolset didn’t support the concept out of the box which meant once again relying on community solutions or forcing existing toolsets to be manipulated with often unexpected results. Several community projects built windows to this data through several tools (stsadm extension, windows apps) but the process was still fairly manual to get those artifacts into your project. One of the core issues, outside of developing a bruit force pure API extraction implementation, was that customizations (browser or SPD) were stored in a site template format and custom solutions were stored in a solution package format.
   
   With SharePoint 2010 Site Templates are now stored in the same format as solution packages (they actually share the same extension now – wsp). This allows for tools such as Visual Studio to provide a native and compatible format for identifying artifact in a package to be imported into a project. This will allow for many types of browser and SPD based customizations to be imported in as SharePoint artifacts\elements, associated with a feature and repackaged with enhancements back into a solution package. With the addition of the ability to upgrade Features a true lifecycle process is now available to the SharePoint development platform.
   
2. "Web Standards” – Now i don’t harp on MS for there lack of standards too much but I do battle it quite regularly. I don’t blame Microsoft (well at least not too much lol) for some of their lack of design standards when it came to their use of CSS and table based layouts. Others however may harp on SharePoint 2007 for its lack of “web 2.0 features” but you need to remember at the time of SharePoint 2007’s development (probably 2004-2006) Web 2.0 features and CSS design methodologies were not mainstream yet as many of the standards\techniques we come to accept today.
   
   With SharePoint 2010 Microsoft has taken a significant step forward and removed the table based layouts and updated much of their default implementations to CSS based layout standards and improved use of CSS and XHTML compliant rendered code. That's not to say old masterpages will break, you can still run in a compatibility mode but going forward as a developer you’ll be in much better shape.
   
3. Business Data Connections – This is not a new concept. Business Data Catalog (the original name) was introduced in SharePoint 2007. Whats important in SharePoint 2010 is that elements of it have been “demoted” (or promoted depending on your perspective) down to the core framework – SharePoint Foundation 2010 (Formerly WSS). In this case demotion is a good thing. This gives the underlying framework the out of the box ability to integrate with external systems and recognizes the importance of this functionality as a core tenant of SharePoint. External Lists and external data columns are now available. The server product adds value on top of this functionality as it should but SharePoint Foundation is now able to work more seamlessly with outside systems and just as importantly Visual Studio provides the project types to support this.
   
4. Developer Dashboard – Have you ever spent hours trying to diagnose performance issues on a SharePoint page? Trying to find out what component is misbehaving can be very time consuming. The new SharePoint Developer Dashboard is like asp.net tracing information on steroids and tweaked just for SharePoint. You can find out a lot of diagnostic information about different aspects of your page and your pages components such as:
   
   1. Request/Response cycle timings for every operations
   2. response time for database queries
   3. Load times for each webpart on this page

With this tool for example you could identify a misbehaving webpart and find out that it has an inefficient query against a list or that the list is missing an index it should have available. Absolutely priceless tool to have when the situation arises.

1. Developer Edition (Windows 7) – SharePoint 2010 now supports the ability for a workstation installation on Windows 7 or Windows Vista. This is for development purposes and isn’t supported for production environments. For many folks, especially new SharePoint developers, this is a big win and well overdue. Sometimes licensing for the server OS product can be prohibitive or the extra hardware required for virtual machines especially for small shops.
   
   Saying that I would argue that for serious SharePoint development you’re still going to be working on a virtual machine and you’re still going to be running a server OS. It’s always the best idea to develop as close to your target deployment platform as you can and that paired with the typically frequent need to refresh your environment - a workstation install could become a real headache.
   

The Grass isn’t always greener!

So there is always a “but” to everything and I have one for this seemingly SharePoint 2010 Fan boy post as well. The product is currently a beta product. i don’t want to completely judge it based on how well current aspects of the tool work but rather on how it would appear Microsoft is intending for them to work. But be that as it may I have a couple reservations with the current beta implementation and I’m hoping to see some improvements before release:

1. Import Solution Packages – The current UI for solution package import can be overwhelming. Visual Studio is able to pull read the artifacts but the presentation of those artifacts can be quite an enormous list even for the case of blank team sites. Additionally the import process rightfully can identify dependencies, a good thing, but does not make any determination to the source of those dependencies. You can very easily, and inadvertently, attempt to duplicate out of the box definitions for items such as site columns and content types. In short the UI is a bit over simplified for displaying a more complex structure and I think the tool needs to be a little more intelligent about how it identifies dependencies. Additionally I would like an out of the box method for importing artifact outside the need for a new Import Solution Package project, some more granularity.
   
2. Import Workflow – I recently did a presentation on SharePoint 2010 Workflow enhancements at SharePoint Saturday KC. One of the things I warn against is importing workflows developed through SPD into Visual Studio. The concept is a great one, the implementation not so much, even the most simple of workflows can turn into a hundreds of actions on the workflow design surface with not so descriptive names as R1, R2. I would argue you would spend more time cleaning up the mess that it would negate the use of the tool. You may be more inclined to expert it into Visio and use the Visio diagram to rebuild the workflow.
   
3. Server Explorer Improvements – Right now the SharePoint server explorer is completely read-only and with the ability to import artifacts limited to new SharePoint projects it would be great if server explorer would also allow you to export artifacts at a granular level. This would arguably be more powerful then the solution package import itself. I don’t see this happening but maybe it will become a project of mine in the future – hell the SharePoint integration with Visual studio is VERY extensible.

This post hasn’t even touched on some of the SharePoint 2010 server goodness but all in all though the developer experience in SharePoint 2010 is full of solid improvements and developers should find a much more pleasant experience and you just may not become an old dog before your time!