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?

Potion

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!

Pharmacy

+1 As well as the details of which patterns to use when for which there is still confusion #1238362 – Which

Answer 2

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

Misrule

+1 for CAML in queries AND definitions, knowing what's already in SharePoint, and giving up control. – Which

+1 for customized/uncustomized pages and Features + solution (things developers simply must understand for proper code deployment). – Pharmacy

and a big +1 for What's already in SharePoint so you don't reinvent the wheel, the plateform is so huge (even more in the 2010 edition) that is so hard to know all the little jewels that are hidden (or not)) – Dramatist

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.

Which

+1, particularly for the "what do you mean I can't touch the database?!?!" point. SharePoint is interwoven with such a complex web of interdependencies that it could probably have it's own daily soap opera on national television :-) – Pharmacy

Answer 4

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

Corettacorette

Answer 5

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.

Cattery

+1 for 3 (finding errors can be too hard initially) and 4 (a good tool saves so much trouble) – Which

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).

Dialectology

Answer 7

Everything related to real world architecture and implementations. I'm a developer but I have to get my hand dirty if I want to have as close as possible client environment on my virtual environments without waiting for an official IT support. Try to create a small farm with an intranet, internet, extranet, mixed authentication mechanism, Alternate Access Mappings, Host header configuration and so on. That's a whole dedicated job but one you'll have to dive into if you want to develop some medium to large scale implementations.

Dramatist