What SharePoint development concepts are the hardest for ASP.Net developers to understand?

Question

I'm trying to put together SharePoint 2007 (and, eventually, 2010) training materials for experienced ASP.Net developers, and having done SharePoint for years, I don't really remember where the worst sticking points were at the beginning - not to mention the amount of Googlable SharePoint content is greater by an order of magnitude than two years ago.

That said, what SharePoint concepts are the hardest to grasp, and/or what parts of SharePoint are esoteric enough to be non-obvious to a newbie SharePoint developer just diving in?

Answer 1

Greg,

In my experience, issuing relating to proper object disposal (SPWeb and SPSite objects that, in turn, reference SPRequest wrappers around unmanaged COM objects) are a common gotcha and the source of many scalability, performance, and other coding issues. Once Microsoft realized the scale of the issue and the degree of developer confusion in this area, they wrote a large guidance article (http://msdn.microsoft.com/en-us/library/aa973248.aspx) and developed the SPDisposeCheck tool (http://code.msdn.microsoft.com/SPDisposeCheck).

That's my vote for "non-obvious to a newbie SharePoint developer just diving in" :-)

For what it's worth!

Answer 2

Hi Greg

My list of things hardest to grasp are:

• Code access security and all the other security features
• Difference between site/application pages and Customized/Uncustomized pages
• CAML in both queries and all the definitions
• What's already in SharePoint so you don't reinvent the wheel

• Giving up control.

  You don't control which web parts are on a page and how they are connected. You should just make them possible to reuse

  You don't control which list are on a site or which fields they contain

• Lack of support for multiple languages
• Don't dispose SPWeb and SPSite if you get them from SPContext.Current
• delegate controls

Other things which are new but seems to be easier to understand are:

• Solutions/features
• All the placeholders in masterpages

Answer 3

*Lack of control*

This is the key issue as Per Jakobsen mentions. Moving along...

1. It's not possible to just go in and edit .aspx and .master files wherever you feel like. There are consequences such as unghosting, support, and that it often just doesn't work as would be expected. A good understanding of how SharePoint composes pages is critical.

2. There's no (supported and reliable) way to query the database directly. This is extremely frustrating for ASP.NET developers that are used to designing/working with purpose-built and well-designed databases. CAML queries are no substitute for the power of well-optimised SQL queries.

3. (More of a 2b): Poor support for relational data between lists. Odd for an enterprise application.

4. A little off topic but HTML markup and CSS was a nightmare in 2003 and not much better in 2007. It's painful to work with and not pretty either. You have to go to great lengths to produce a site fully compliant with web standards and best practices.

To summarise, things usually need to be done "the SharePoint way". This often isn't the most efficient or elegant way that a straight ASP.NET dev prefers. Developers like elegance and they don't like giving up control.

There are also gotchas right across the product (Sean mentioned a key one) lurking like little tripwires for the unsuspecting. The only way to know and understand them is to know SharePoint - and it's a big product.

See more discussion about this at Why don't ASP.NET developers use WSS? on SharePointDevWiki.

Answer 4

Per has covered has covered off most off the points for me however I will add a couple more:

1. SPContext - The concept of conecptual code execution e.g. SPContext.Current or Properties object in an event reciever.

2. Following on from the context it is also important to understand who the code is running as and therfore what actions it can complete - Elevating (elevate priviliges), Impersonating (tokens) and execution (web services / event recievers).

3. Error Handling - Everyone screams when the only error surfaced is "an error has occured", so understanding SP Logs and error codes is critical. This is important for reducing wasted time chasing a infuriating XML error.

4. Visual Studio Tools - WSPBuilder, VS Tools for Sharepoint etc. Reduce the pain of deployment and debuging by shortening the integration cycle.

Answer 5

What's already in SharePoint so you don't reinvent the wheel. I vote for this.

Answer 6

Create report/dashboard using reporting services of SQL Server for real world problems and show it in sharepoint site. Number of examples/tutorial found online no this matter is still insufficiente (I guess).